3 ms·

I find it definitely a nice language proposal, but there are a few issues, I guess. A first one is that many of the distinctions introduced (such as proc,fun,g

I find it definitely a nice language proposal, but there are a few issues, I guess. A first one is that many of the distinctions introduced (such as proc,fun,gen) are all optimization issues. I would appreciate if it were possible to do that long after you're done with just making the program work. The language may force the developer way too early in the process to think of things that do not matter at that point. In the best case, it will matter later on, when the program truly works. Another issue I have is that the "simplifications" introduced initially lead to introducing lots and lots of additional symbols such $ and #, just because the simplification was apparently not leading to something simple. So, the language suffers from enforcing a premature optimization mindframe as well as from overly complex administrative simplification.

Yttrill 14y ago
The proc/gen/fun distinction isn't entirely an optimisation issue, its a semantic one, heavily related to the implementation model. In principle fun and gen use the machine stack for return addresses whilst proc uses a heap allocated list which allows cooperative multi-tasking using channels for communication: such so-called spaghetti stacks are easy to swap. Machine stacks can only be swapped in a conforming way in C/C++ by using pre-emptive threads which is precisely what we're trying to avoid. I said "entirely" above because semantics and optimisation are heavily intertwined in any system. The comment about "syntactic sugar" is valid: there are at least four operators with different precedences all meaning "application of function to arguments". However note that in most languages this is true anyhow: x + y is really just add (x,y). Finding a good set of squiggles and marks that's acceptable to many people isn't easy. However the syntax is defined in the library, in user space, so you can add your own grammar or design your own domain specific sub-language, and add your favorite squiggles that way. Any contributions to making the standard syntax simpler would be welcome: I'm constantly struggling with this issue because I'm well aware syntax matters, especially early in learning a language.
- eriksank 14y ago
  I have created a blog post explaining why I think the language has too many problems to ever take off: http://erik-poupaert.blogspot.com/2013/01/the-felix-programming-language-or-how.html http://erik-poupaert.blogspot.com/2013/01/the-felix-programm...

Yttrill 14y ago

The proc/gen/fun distinction isn't entirely an optimisation issue, its a semantic one, heavily related to the implementation model. In principle fun and gen use the machine stack for return addresses whilst proc uses a heap allocated list which allows cooperative multi-tasking using channels for communication: such so-called spaghetti stacks are easy to swap. Machine stacks can only be swapped in a conforming way in C/C++ by using pre-emptive threads which is precisely what we're trying to avoid. I said "entirely" above because semantics and optimisation are heavily intertwined in any system. The comment about "syntactic sugar" is valid: there are at least four operators with different precedences all meaning "application of function to arguments". However note that in most languages this is true anyhow: x + y is really just add (x,y). Finding a good set of squiggles and marks that's acceptable to many people isn't easy. However the syntax is defined in the library, in user space, so you can add your own grammar or design your own domain specific sub-language, and add your favorite squiggles that way. Any contributions to making the standard syntax simpler would be welcome: I'm constantly struggling with this issue because I'm well aware syntax matters, especially early in learning a language.

eriksank 14y ago
I have created a blog post explaining why I think the language has too many problems to ever take off: http://erik-poupaert.blogspot.com/2013/01/the-felix-programming-language-or-how.html http://erik-poupaert.blogspot.com/2013/01/the-felix-programm...