newLISP from delphi

[HPW]

Last year I post some delphi code to delphi sites.



http://www.delphipraxis.com/topic15357_embeded+lisp+in+delphi.html">http://www.delphipraxis.com/topic15357_ ... elphi.html">http://www.delphipraxis.com/topic15357_embeded+lisp+in+delphi.html



Sadly it does not get much attention.



http://www.swissdelphicenter.ch/de/showcode.php?id=1960">http://www.swissdelphicenter.ch/de/showcode.php?id=1960



Seems not easy to spread the word about newLISP.

[nigelbrown]

Hi Hans-Peter,

This probably applies to Lisp in general unless someone comes from a specific area where they are exposed to it - like Autocad/AutoLisp.

A delphi programmer may not see any advantage in adding in a new strange looking (well, Lisp is if you're not used to it) language as an embedded feature - unless perhaps there is an immediate value, that is, it adds something immediately rather than just adding a capability.

They already have lots of embedding choices, see http://jansfreeware.com/">http://jansfreeware.com/ Delphi Section for examples.



As far as getting exposure for NewLisp perhaps we could encourage one of the Linux distributions to include it - perhaps even a secondary specialised distribution (e.g. Quantian a clusterKnoppix derived scientific distro http://dirk.eddelbuettel.com/quantian.html">http://dirk.eddelbuettel.com/quantian.html ).



If a collection of generally useful, easily interfaced, scripts was available with newlisp then Delphi prople may look harder? Even if an unusual language (e.g. Icon http://www.cs.arizona.edu/icon/library/cprogs.htm">http://www.cs.arizona.edu/icon/library/cprogs.htm ) has a good set of progs its difference makes it difficult to access (granted I've always felt Icon had other problems like lack of IDE/debugger combination).



Some ideas for promoting newlisp should be tossed around here. Especially now 7.5 prog and docs looks pretty settled from the development point of view.



Regards

Nigel

[Lutz]

Having newLISP included in one ore more distributions would be fantastic! Unfortunately there is also opposition to it from conventional Common Lisp and Scheme users, who oppose newLISP just because it does things in a different way.



Currently Guile (GNU org Scheme) and sometimes CLISP seem to be the LISPs included on most ditributions. I think there is definitely a place for a LISP usable for scripting and tasks commonly programmed with Perl/Python.



Most people when they hear 'LISP' think of an AI- and Academic-only language . newLISP is much more than this. We have to change this!



Lutz

[nigelbrown]

Some of the opposition seems to come from the garbage collection method of newlisp. Is there some fuller explaination of it, or could there be? That may allay some of their suspicion.



Perhaps leave NewLisp the same but call it NewScript and slip it into a distro that way - or perhaps rename it NotLisp to keep them happy (just joking).



Nigel

[Lutz]

For a longer answer to the garbage collection question see this first draft of a new chapter for the manual or link in a newLISP FAQ:



http://www.newlisp.org/MemoryManagement.html">http://www.newlisp.org/MemoryManagement.html



I guess there are more of this kind of questions. Perhaps we can think of some kind of FAQ where this and other questions/differences about newLISP can be answered. For now I will just make a link to this article in the newLISP page after a second editing pass through it. Its time to do some newLISP advocacy ;)



Lutz

[nigelbrown]

Thanks for the memory management explaination.



If the newlisp memory management stuff was collected togther (? newlisp-mem.c or newlisp-cells.c) with a defined interface perhaps in the future the option of a compile option for one of the other available garbage-collected memory management systems could be offered. This would mean that if someone wanted to port code that didn't sit well with the copying used in the current newlisp implementation then a more standard  gc'ed version could be used (you have admit that ORO isn't standard - and thank you for offering it).



A quick look at the current 7.5.0 newlisp code shows the cell allocation and freeing functions grouped together already (by commenting).

Even using a gc'ed alloc and less careful cleaning-up could be an option for offering a different memory management option?



I must admit that I tend to be a bit careless in choosing destructive or non-destructive options relying on my usually small memory needs. However, I'll have to bear it in mind if I'm prototyping something that I might want to scale up!



What do others think about memory management style? (Is it time to spawn another thread on this?)



Nigel

[Lutz]

See new thread in 'Lisp in general' :



http://www.alh.net/newlisp/phpbb/viewtopic.php?t=171">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=171





Lutz

[HPW]

I updated my sample code with the new callback-method:



http://www.delphipraxis.net/topic15357_embeded+lisp+in+delphi.html">http://www.delphipraxis.net/topic15357_ ... elphi.html">http://www.delphipraxis.net/topic15357_embeded+lisp+in+delphi.html