I believe why we want static typing is more because of compile time guarantee that our code will work as expected, better performance is a bonus.
1 Like
I guess I will have to add read-macros to make you happy. Would it be enough to have them prefixed with # and followed by an sexpr? Otherwise it would entail rewriting the io and it would not be that easy to use for those who want to write their own read-macros. The io system is not really oriented towards reading characters from input. It can be done but the result could be āinterestingā if you have concurrent input.
Another interesting question is whether we have one set of read-macros for a whole node, which feels unnaturally single threaded, or have one set per process?
2 Likes
Why did you write the word optionally in parenthesis?
Again, for backward compatibility. We canāt enforce to break current syntax unless you want to make many people mad and rant about elixir 
I donāt think itās even wise to have major breaking syntax change in Elixir 2.0, I know itās a major version bump, but stillā¦
1 Like
Remember how it went with Python 2 and 3. 
3 Likes
Could you explain better? Read macros are a compile time construction. Why would you want the same source code to be compiled to different things in different nodes?
1 Like
Iām not asking what you meant. Iām asking why was the word optional wrapped in parenthesis? Whatās the difference between:
I hope one day elixir can (optionally) be one
and
I hope one day elixir can optionally be one
?
iām unsure whether it will be optional or not in the future
Well, he let it open that Elixir becomes a fully statically typed language at all, without any opt-out.
This is of course unrealistic, what let him probably choose the parentheses.
I agree that they are semantically superfluous, considering this.
Lol, only if wanted. As long as it letās one do something like a prefix (like say #{) then any arbitrary characters up until it considers itself done, then it should handle most cases just fine sans āexecutingā custom formats. 
/me still needs to get around to making an Elixir compat layer for lfeā¦
Well in my version I had to explictly import a module that defined a given read macro and even then the read macroās were only valid in the scope it was defined in. I know itās not quite āpureā but I like the scopeness of it (and I could always import another code file inlline for the read-macros to run over).
Because lispāy languages can read in more code and run it later, or maybe even run a new data structure that it generates at runtime via requests or so āasā code.
Though you can limit that in your own lispāy language for the sake of speed.
Indeed, this is super interesting. It might be what I need to finally get to reading Type Driven Development with Idris. I already started the cycle of āTry to learn, back off because itās not clickingā¦ā with Idris a little over a year ago and I reckon Iāll feel the same way about it in a couple of years as I do about Haskell now.
2 Likes
Very interesting. Iāll definitely give it a shot.
1 Like
Idris 2 currently works by emitting Scheme code. Would be interesting if someone tried adding an LFE backendā¦
LFE may be lispāy syntax, but itās primitives are too different to work well as a backend like that, it would have to be something new Iād wager. Porting typed racket would probably be easiest to be a typed lfe.
