|
Post by Markel Kaj on May 1, 2018 22:36:10 GMT
I didn't come to the forum for nothing. As much as I am impressed with the stated features and goals of lux, the one thing is missed out of the feature list that I am particularly concerned with is what's lux's take on null/nil/none/nan-safety? Yeah, not the concurrency model but that thing. I don't know why but nulls drive me insane. I know, some languages have it (clojure, go, python) but the pain is somewhat mitigated by certain conventions dictated by the user community of the language and language itself to the degree. Statically typed languages and particularly new ones have super nifty feature to handle nulls (Kotlin, Swift, Ceylon?): nullable types, others claim they don't have nulls at all (Julia, Pony, certain Beam-languages as Erlang?). I know, functional statically-typed languages do not usually suffer from the null problem: scala has option type (but it had or even still has an overhead), haskell has maybe (but it also has "Nothing" that came from god knows where in the past, don't know how it is now). What does Lux have? Since we are speaking about functional languages. Is Lux by chance pure in the sense haskell is? It will be very interesting if it is since lisps usually are not  , but they aren't usually statically typed either XD, so it wouldn't be that surprising. Regards,
|
|
|
Post by Eduardo Julian on May 2, 2018 0:55:56 GMT
Hello, Markel Kaj. Lux does not have a notion of null. Because Lux is a hosted language that compiles to other platforms/languages, it does have to deal with null, but it does so in a way that does not propagate null throughout the program. How so? For starters, you cannot create nulls in pure Lux code. Then, when it comes to interacting with the host platform, it may be the case that a null can be produced when invoking a method on some object. But Lux checks for that at run-time, and if a null appears somewhere, it throws a run-time exception notifying you of that. In order to safely avoid that, you can annotate methods (when importing JVM classes), with information about the "nullability" of the return values of methods. Doing so makes the methods return (Maybe X), instead of X, thereby rendering the result both safer, and more in-line with Lux's style. Yes, it is. There is an IO type for operations with side-effects. The only ways to execute IO operations is to use the lux/codata/io;run (which is similar to Haskell's unsafePerformIO), or to run the I/O operation concurrently, and get back a Promise out of it.
|
|
|
Post by Markel Kaj on May 2, 2018 2:11:42 GMT
Wow! That was a fast reply, not to mention very detailed. Thank freaking God Lux does not have the notion of Null. Or should I thank the BDFL for that? Did you implement it yesterday  ? Or it isn't the time to ask such rhetoric questions yet because the time machine is not at your disposal? Jokes aside, thanks for the answer. I still have a few questions but it will be better to create separate threads for them and I will ask the questions a bit later just not to be annoying. Paying close attention to the development of lux,
|
|