On 08/11/2010, at 8:37 PM, Lenny222 wrote: >> Well, I am interested in "pure" ideas/theory because I think it helps >> get a nice clean "orthogonal" design ..as well as making the implementation >> simpler. > > Please take my rambling with a pinch of salt. I still need to recover > from my disapointment with a certain programming language community. > Most of everyone's time seems to be spend on things noone but a few > care for. Not many are interested in bringing the overall experience > to a level you'd take for granted for a long time. Real world stuff is > confined in a narrow niche.
Well you see, as a former member of ISO/IEC SC22/WG21 I have rather the opposite experience :) Indeed it was a pleasure to turn to Ocaml: the community there is heavily into theory but at the same time very pragmatic. Unfortunately the developers kept the core product to themselves and didn't help those wishing to extend it with libraries much: plenty of 3PLs but not part of the official product which leaves one wondering what happens when the developer moves on: which has more or less happened to Ocaml itself. Felix makes some interesting development choices. Well I mean, I made them .. :) For example, optimisation is paramount: it is more important than correctness. I want the code to go FAST, and if we find some of the algorithms are over-aggressive we can tune them down. The interesting example here is the semantics of "val" function parameters (the default). It's kind of counter-intuitive. "var" parameters (hey, I forgot to document this feature of functions .. ) are variables to which arguments are assigned. Which means "var" implies eager evaluation. Felix also does lazy evaluation. Contrary to popular belief (especially among Haskell people) lazy evaluation is generally VERY much faster than eager evaluation. The reason is: lazy, or normal order evaluation is just substitution. Replacing each use of a parameter with its argument expression allows the containing expression to be optimised heavily. It is only when a closure is required that lazy evaluation gets slow. Indeed, passing a closure usually involves assigning it to a variable .. which is in fact eager evaluation of the closure, but lazy evaluation of the application of the closure. So ... with "val" parameters, Felix is allowed to chose the evaluation strategy. It is neither eager nor lazy, but rather the client is responsible to ensure it doesn't matter: if you require eager evaluation use a var. If you require lazy evaluation lift the argument to a function (enclose it in an explicit wrapper). The "fact" is that usually it doesn't matter, and usually Felix choses the fastest approach. However I have been caught by this kind of thing myself: the nasty one was using STL iterators on strings. Felix thinks strings are values and so it feels free to copy them about: val x = "A string"; var i = stl_begin x; val e = stl_end x; whilst i != e do println$ "Char " + char (*i); ++i; done; WOOPS! Do you see the bug? [Hint: x is a val ..] -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
