Wednesday, August 22, 2007

New Lisp warts

Well I haven't need to dig too deeply to find warts in NewLisp. and some of them do seem to be by design.

  1. No tail call optimization (and nver will be or so the creator has said) seems a little antagonistic to functional programming. And pass by value is not your friend here.
  2. Contexts are inadequate for any of the jobs they are supposed to do, and they have been overloaded with too many jobs.
  3. Macros facilites are inadaquate, as there are no gensyms and there is no macroexpand function.
  4. Memory management seems to be a dogma. The only problem I have with pass by value is that it seems to go against the grain of functional programming. where you pass in functions expecting them to not modify their arguments, so why copy them? I think copy on write would be a better strategy. to adopt, perhaps a little more complex but favarable to functional programming.
  5. No Type system. THere simply is no facility for user defined types. and hence no way to do anything interesting like generic functions

Why contexts are inadaquate

Context take the place of Module, hash tables, objects (closures really) and pass by reference mechanism.

They fail as a packaging system as they have a flat namespace so that all modules must be global. Every scripting language that I know of supports hiarchical modules simply because it works better and reduces the changes of two differnt packages defining the same module. Without hiarchical contexts developing an extensive standard library for newLisp is going to be impractical. Note that all of the successfull scripting languages have large standard libraries, it is just one of the signs that a language is a success.

As hashtables they sort of will do but are inadaquate simply because you must stick all your hashtables in MAIN, where they share a namespace with any loaded modules. So I can't have one without exposing it to the world and the chances of name collision have increased again. If I could create an anonymous context and bind it to a local variable that would be better.

As a method of passing by referance. Sorry but that is a plain ugly hack, which forces the proliferation og global objects. Again if this must be the only way to do it then anonymous context are what is needed.

As Objects. Well no what we have here are not objects but what every other Lisp would call a closure. Except that again while in all other Lisps closures are anonymous here they must be named, in the same namespace as Modules and Hash tables (boy its getting crowded in there). Yet again anonymous context seem to be what is missing.

Unfortunately neither Hiarchical Contexts or Anonymous contexts are likely to be added. Form what I have seen the Project maintainer has already expressed the opinion that he does not like the idea of hierarchical Contexts. Anonymous ones meanwhile would I suspect play havoc with the whole ORO memory management Idea. As once they existed people would use them (quite Heavily I imagine).

No comments: