I was tempted to add the [satire] tag due to the somewhat surreal nature of the “tutorials”, but the feature list looks solid and there is actual code behind the download link
Bound lexical identifiers, otherwise known as variables, are often used to store information. In other languages Bindings are generally monomorphic, meaning that they permit only one interpretation. Luck, by comparison, prefers ambiguity and permits any number of competing interpretations to coexist.
let x: bool = true;;
let x: string = "7";;
print(x)
will depend entirely on context to determine meaning. The reference to identifier x may resolve to the boolean or string value or other depending on
The argument preference of print
The observed compatibility of print with its potential arguments
The observed compatibility of the resulting expression with further context
So, what you’re saying is that I can shadow all names indefinitely with no regard for type information, and that the value any given name will resolve to if it has been shadowed is almost completely unpredictable?
Can someone please clarify, because this seems like an incredibly bad idea. This seems like overloading (a generally bad idea anyway) taken to its extreme—to the point where the programmer doesn’t even actually have a guarantee about what the name they use even refers to.
They move on to say that it is a wonder that anyone can understand anyone else. It is true that language is pretty incredible; but I think porting over such uncertainty is a bug, not a feature.
In a language with type inference, that feature may break a key property of a type system called “context strengthening.” Context strengthening says that if a program type checks under a context C, it also type checks under C with new variables added to it. If context strengthening fails then you can’t, say, add new identifiers to a module without breaking backwards compatibility.
I’m having a hard time finding specifics about how Luck does type inference, all I see is
Luck aggressively uses inference to reduce the amount of type-level code that needs to be written.
Like zem said in the description, the tutorials are really weird, and didn’t leave me feeling like I actually knew what the language was or even how to use it to do anything.
Also, the documentation is entirely unreadable, because for some reason it changes the main body font to something ridiculous for body text.
So, what you’re saying is that I can shadow all names indefinitely with no regard for type information, and that the value any given name will resolve to if it has been shadowed is almost completely unpredictable?
Can someone please clarify, because this seems like an incredibly bad idea. This seems like overloading (a generally bad idea anyway) taken to its extreme—to the point where the programmer doesn’t even actually have a guarantee about what the name they use even refers to.
They move on to say that it is a wonder that anyone can understand anyone else. It is true that language is pretty incredible; but I think porting over such uncertainty is a bug, not a feature.
In a language with type inference, that feature may break a key property of a type system called “context strengthening.” Context strengthening says that if a program type checks under a context C, it also type checks under C with new variables added to it. If context strengthening fails then you can’t, say, add new identifiers to a module without breaking backwards compatibility.
I’m having a hard time finding specifics about how Luck does type inference, all I see is
is it normal that doing a make launch sudo something ?
that took me aback too. i edited the makefile to add
$PREFIXand removesudobefore running itLike zem said in the description, the tutorials are really weird, and didn’t leave me feeling like I actually knew what the language was or even how to use it to do anything.
Also, the documentation is entirely unreadable, because for some reason it changes the main body font to something ridiculous for body text.