Re: undefined vs. nil

[José Valim]

I was wondering why Elixir chose to go with nil instead of keeping Erlang's undefined atom as the default no-value atom. Surely this raises an incompatibility that needs to be addressed whenever Elixir code calls Erlang code or vice-versa. This issue has been raised in the context of defaults for record fields, but it is more general - e.g., Erlang uses undefined to report missing keys in dictionaries. As a result we see things like defining "nillify" functions mapping undefined to nil (and "undefine" functions mapping nil back to undefined) - neither of which seem to be in the public API of the standard library (they are defined as private functions though).

I would have chosen undefined instead of nil if it was actually a recurrent pattern in Erlang APIs but the truth is that it is isn't. You mention records and dictionaries but I guess you mean the process dictionary? The dict/orddict APIs don't return "undefined" afaik as well as with many other APIs (in lists for example) return a false or a tuple.

Someone already asked me why not make the `||` operator work on tuples like `{ :error, _ }` so we can easily wrap Erlang code without nil. It is basically the same idea of using something else Erlang already returns instead of nil.

That said, I believe the undefined cases to be few so I chose to go with a terminology which is shorter and more known by developers (nil or null) instead of undefined. 

[Oren Ben-Kiki]

Yes, I was referring to the process dictionary - and records, of course. An Erlang/Elixir newbie here, so I guess I was assuming consistency that isn't actually there. I guess Elixir sets a standard here, and if Erlang doesn't, than each case needs to be translated separately. Sigh.

At any rate, I'm now giving Elixir a try, there is a lot to like! I am a bit worried about stability though - I'm doing a "real world project" that Erlang VM is a good fit for. Obviously I'd like to use Elixir's infinitely superior syntax (syntax matters!), but I need to be reasonably certain I wouldn't need to do "non-trivial" refactorings due to language changes down the road ("trivial" refactorings I can handle :-).

Thanks,

Oren Ben-Kiki

[José Valim]

At any rate, I'm now giving Elixir a try, there is a lot to like! I am a bit worried about stability though - I'm doing a "real world project" that Erlang VM is a good fit for. Obviously I'd like to use Elixir's infinitely superior syntax (syntax matters!), but I need to be reasonably certain I wouldn't need to do "non-trivial" refactorings due to language changes down the road ("trivial" refactorings I can handle :-).

As Elixir gets more stable, it is very unlikely you will have to do "non-trivial" refactorings. The huge majority of our changes are first deprecated and just then removed which gives you some time and warnings on how to proceed. We keep backwards incompatible changes to a minimum.

However, the deprecations warnings usually last one release. So if you are on v0.7.0, you may get some warnings when you move to v0.7.1 and those warnings will be gone on v0.7.2. Releases are meant to have a 2 to 4 weeks time interval in between them.

Enjoy!

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer