Arc Forumnew | comments | leaders | submit | ndanger's commentslogin

It sounds like Python's abstract base classes (http://www.python.org/dev/peps/pep-3119/) & mix-ins (which is, INMHO a good idea for Python, I haven't used Arc enough to judge).

-----

1 point by almkglor 6098 days ago | link

"Abstract Base Class" also happens to be the term preferred in C++ for Haskell's "type class" and Java's "interface". So it probably is-a python abstract base class ^^.

That said the problem with using a "base" class with an inheritance model is that it's deucedly difficult to think in terms of multiple inheritance (multiple inheritance is so hard most languages don't use it). Mix-ins help ameliorate this by being a has-a relationship.

-----

6 points by ndanger 6136 days ago | link | parent | on: Multi-var function literal shorthand

What about combing it with nex3's idea?

[+ _1 _2 _3 ...]

_1 could be an alias for _

[+ _ _2]

-----

2 points by greatness 6136 days ago | link

I was thinking that _ would be merely _0, ie _1 would be the second argument. But at this point that's not really the question, the question is how will the interpreter know how many arguments the function takes?

Maybe something like:

  [[[+ _ _1 _2]]]
Could be shorthand for:

  (fn (_ _1 _2) (+ _ _1 _2))
But, then, what if you want to use square bracket notation inside of that? For example, what if you want to create a two paramater function that creates a one paramater function?

  (fn (x y) [+ x y _])
would be impossible. Unless you use currying or something on these special ones. Incidentally, a curry function:

  (def curry (f . args)
    (fn args2 (apply f (join args args2))))
Then you could simply do:

  (curry + var1 var2)
Assuming you already have the variables. For smarter currying it'll need to be done by the interpreter.

-----

1 point by are 6135 days ago | link

In this expression:

[+ _1 _2 _3]

... the interpreter already knows that _2 is the second anonymous parameter to the function literal, without parsing the "2" token.

So you could instead have:

[+ _ _ _]

... and specify the index only if you actually want to use the parameter outside of the function literal (and there, _ would still be shorthand for _1).

And BTW, this whole thing should work with rest parameters, so that in:

[+ _ . _]

... _2 will denote a list.

-----

1 point by robbie 6135 days ago | link

"... the interpreter already knows that _2 is the second anonymous parameter to the function literal, without parsing the "2" token."

it could be the third parameter.

-----

1 point by are 6135 days ago | link

We may be talking past each other.

I'm just saying that if you have several anonymous parameters in the parameter list of the function literal, it is just as well that you represent them with the same token _within the parameter list_. The parameter list is ordered, so the interpreter knows which is which anyway. If you then want to refer to one of the anonymous parameters _outside of the parameter list_, you use a token WITH an index, to identify the position of the particular anonymous parameter in the parameter list.

-----

1 point by Xichekolas 6135 days ago | link

I thought the whole point of the bracketed function literal syntax was that you don't have a parameter list...

-----

1 point by nex3 6136 days ago | link

I thought about suggesting this as one of the prefix characters, but underscores just don't feel very prefixy.

-----

1 point by Xichekolas 6135 days ago | link

One thing about underscores is that they kind of stand out... but I agree, they are a bit weird. Other options could be (@, $, %, *, ?)

-----


Strings aren't just lists of characters:

    arc> (map [coerce _ 'int] '(#\f #\o #\o))
    (102 111 111)
    arc> (map [coerce _ 'int] (coerce "foo" 'cons))
    (102 111 111)
    arc> (map [coerce _ 'char] '(102 111 111))
    (#\f #\o #\o)
    arc> (string (map [coerce _ 'char] '(102 111 111)))
    "foo"
To unify strings and lists of chars I think you'd need a way to specify encodings (well, once Arc is worried about that sort of thing).

-----