Also, just checked the official LFE website:
Utterly Terrifying
- Fault-tolerant
- Massively scalable
- Concurrent
- Soft real-time
- Open. Telecom. Platform.
LOOOOOOOOOOOOOOL
tmbb
OvermindDL1
OvermindDL1
I’m like 95% certain it would require certain it would require changing the language in a backwards incompatible way even without looking at its compiler yet. ^.^
You could always implement it ‘inside’ the language via lisp’y macro’s though.
0
tmbb
What about a strict version of dialyzer that works on Elixir AST, uses HM type inference and reject all code it CAN’T prove correct? With the possibility for “dirty” type coercions, of course, otherwise you’d get the problem of typing receive. Is this possible? Doesn’t seem too hard…
I’m by no means a fan of Elixir syntax, but at least being able to reuse Mix an the existing macros is pretty cool, so something that works on vanilla elixir files is pretty cool.
2
OvermindDL1
I already have a project that started as something like that along with code specialization based on types (which is the real nice thing about typing). It is always just an issue of ‘time’ for me. ^.^;
0
ShalokShalom
OvermindDL1
As long as you don’t use mutation then yes memory safety (and if linear types get added to OCaml then even those would be safe), but that could be enforced be a non-mutable message type too, and let-it-crash easily so as each micro-thread can be wrapped in an exception handler (which is consequently how effects work as well, so it’s the same code).
1
ShalokShalom
That sounds like source to source converters count as superfluous to me now.
At least when it comes from an ML language to Elixir.
I am still concerned, that F-Sharp provides the saner syntax, even when I see it currently not so drastically anymore as before. It provides an ML compability mode, with which I can produce OCaml code, so far as I understand. The syntax changes of ReasonML do I consider still as helpful, so long as all the changes regarding to make it more JS like get reversed…
0
OvermindDL1
They tend to be made for some reason, usually to, say, shorten and ease syntax. That is why the caml4p PP exists for OCaml, it has a slightly different syntax, but essentially adds Elixir’y macro’s to OCaml, and been included with it for well over a decade (recently pulled out to a separate source project even). Though there are modern PPX’s that add more pure Elixir style macro’s now via different pass levels (which is how Elixir works too).
I don’t? F# lacks higher modules, it is slower due to compiling to virtual-filled .NET, etc…
Hmm, I’ve not run across that, that’d be interesting to look at. Links? As far as I know it can ‘consume’ simple (non-module’y) OCaml code, but not produce it?
Yeah, a lot of it’s syntax is making it have larger syntax actually, with no greater benefit in readability in my opinion (though perhaps to JS users…).
1