4 ms·

This definitely makes Erlang more approachable for me - I've managed to develop a strong dislike for the syntaxes in a lot of functional languages including Lis

by Ezku 16y ago

This definitely makes Erlang more approachable for me - I've managed to develop a strong dislike for the syntaxes in a lot of functional languages including Lisp and Haskell. From my perspective, the syntactic choices documented in https://github.com/josevalim/elixir https://github.com/josevalim/elixir seem rather reasonable on the whole, but functions are a tad odd. Is there any specific reason why it's "-> (x, y) x + y"? I always thought the motive for the arrow notation in the form "(x, y) -> x + y" was an obvious cognitive mapping into "x and y becomes x + y". Seems a bit bass ackwards as it is. I also have a minor issue with the atom prefix (to me : would have been more distinctive), but that's admittedly more of a personal thing.

josevalim 16y ago
I'm glad that you found the syntax reasonable as a whole. :D Regarding to functions and atoms, their syntax choices are a trade-off. If I have "(x, y) -> x + y" for functions, I need explicit parens when invoking a method (otherwise we will have ambiguity), so I prefer to have this flexibility on method invocations. A similar choice happened to atoms. As I preferred to save ":" for dicts, as in { x: y }, the syntax would get very confusing if I allowed: { :x: :y }. That said, I have chosen 'atom, which is common in some Lisp dialects.
- Ezku 16y ago
  Having now read the entirety of the readme, I'm left a bit unclear on the object model's semantics. If I declare a mixin in an object, those become class methods? Whereas declaring a prototype results in instance methods? Also, "set_ivar" seems like a needlessly complex and obscure statement.
  - josevalim 16y ago
    1) About mixins and prototypes, exactly. 2) Yes, adding a syntax to easily change instance variable values is one of the most asked features. The tricky part is, we cannot do the following: @foo = "bar" Because that is pattern matching and in Erlang/Elixir, we cannot modify objects in place. The expression above needs to return a new object. I was thinking about something like @{'foo : "bar"}, but I haven't decided yet. Suggestions are welcome. :D

by Ezku 16y ago

josevalim 16y ago

I'm glad that you found the syntax reasonable as a whole. :D Regarding to functions and atoms, their syntax choices are a trade-off. If I have "(x, y) -> x + y" for functions, I need explicit parens when invoking a method (otherwise we will have ambiguity), so I prefer to have this flexibility on method invocations. A similar choice happened to atoms. As I preferred to save ":" for dicts, as in { x: y }, the syntax would get very confusing if I allowed: { :x: :y }. That said, I have chosen 'atom, which is common in some Lisp dialects.

Ezku 16y ago
Having now read the entirety of the readme, I'm left a bit unclear on the object model's semantics. If I declare a mixin in an object, those become class methods? Whereas declaring a prototype results in instance methods? Also, "set_ivar" seems like a needlessly complex and obscure statement.
- josevalim 16y ago
  1) About mixins and prototypes, exactly. 2) Yes, adding a syntax to easily change instance variable values is one of the most asked features. The tricky part is, we cannot do the following: @foo = "bar" Because that is pattern matching and in Erlang/Elixir, we cannot modify objects in place. The expression above needs to return a new object. I was thinking about something like @{'foo : "bar"}, but I haven't decided yet. Suggestions are welcome. :D