newLISP now on Graham's list

[Lutz]

I think this is just a question of programming style. There is always the possibility to recode a recursive algorithm in a linear, iterative fashion. Traditional LISP and Scheme focus a lot on recursion, but it doesn't have to be this way. There are situations where recursion is the more elegant solution, but there are also situations where a recursive solution is inefficient or obscure, even when using reference passing of parameters.



The work I am currently involved with at Kozoru is heavy in algorithms (of natural language processing) which traditionally often where coded recursively, but we never ran into limitations of the sort you are describing or it was easy to work out a solutions more suited to newLISPs style of programming.



You should try newLISP on bigger programs/projects. The context mechanism works well to divide a bigger problem into modules.



Lutz



Ps: The memory referenced by context references will go away automatically when that memory is not referenced anymore, just like in any other scripting language in that situation.

[Dmi]

eddier:

AFAI understand there is another nice way of passing parameters by reference in newLisp - using dinamic scope:

Code Select Expand

(define (recur p1 p2)
  (do-something-with-list lst)
  (recur [value] [value]))

(define (start-recur params)
  (let (lst '())
    (recur [value] [value])
    lst))
(start-recur [values])

so "lst" isn't a persistent context variable, _and_ it is passed dynamically by reference to inner functions.



Lutz, if I'm right, this trick is a nice candidate to explain it in manual.

[eddier]

Lutz,



To unreferece memory, do I need to make sure no variable or function is bound to the referenced memory, or do I need to delete the context?

I think this is just a question of programming style. There is always the possibility to recode a recursive algorithm in a linear, iterative fashion. Traditional LISP and Scheme focus a lot on recursion, but it doesn't have to be this way. There are situations where recursion is the more elegant solution, but there are also situations where a recursive solution is inefficient or obscure, even when using reference passing of parameters. /quote]



Yes, I understand that recursion and iteration are equivalent as for as computation goes, but, code dealing with tree structures "seem to me" a lot easier to write and maintain if they are done recursively.



Dmi,



I see what you are getting at, and it seems to make sense. This seems to be a reasonable approach if the function is called from only one other function. IMHO, There are two pitfalls to this approach. (1) I wont be able to compose functions using this parameter passing approach. and (2) in medium - large programs it will hide parameters deep inside functions that should be made visible (by the reader) through a functions arguments. Although this could be mitigated by comments, it also obfuscats how a function should be called.

 

Eddie

[Dmi]

I haven't much expirience in dynamic scope usage... And I still trying to understand is it better or worse thing :-)

Multiple recursive function calls aren't completely impossible:

Code Select Expand

.....
(let (lst some-list)
  (recur params)
  (let (lst another-list)
     (recur params)))

But, yes - usage of both 'lst' values at the same time will be impossible :-(



About readability: yes, in this case we must insert an additional comments to function definition.



About contexts: their naming and persistance in a dictionary is a payment for garbage collection absence. I think it's not a disadvantage, but newLisp in common really requires it's own programming style.

Possible an experience, tricks and rules of "mythical" Kozoru programmers can be extracted and published? (once upon a time)

[Lutz]

Eddie,



To release memory  just make sure nothing is referencing it and it will go away. Thaks for the dynamic scoping/recursion trick.



DMI,



Unused memory is collected, newLISP does recycle unused memory, it just does it in a different way, not using traditional garbage collecting techniques like mark/seep and refernece counting.



Contexts/name spaces have nothing to do with this. In fact namespaces in other interpreted languages are done in a simiar fashion. They only differ in the way they organize symbols internally, some (like newLISP) use binary trees, others use hash tables.



Lutz

[eddier]

Thanks Lutz,



Dmi posted the dynamic scoping/recursion trick. Credit where credit is due.



Eddie

[Dmi]

Unused memory is collected, newLISP does recycle unused memory, it just does it in a different way, not using traditional garbage collecting techniques like mark/seep and refernece counting.



Contexts/name spaces have nothing to do with this. In fact namespaces in other interpreted languages are done in a simiar fashion. They only differ in the way they organize symbols internally, some (like newLISP) use binary trees, others use hash tables.

The problem (or technical misunderstanding) with contexts in newlisp is caused by the fact, that they are proposed not only for namespace-modules, but for regular variable tricks (for ex., for the access by reference).



Let me explain:

Code Select Expand

newLISP v.8.7.0 on Win32 MinGW, execute 'newlisp -h' for more info.

> (set 'ctx:var 1)
1
> (let ((ctx:var 5)) ctx:var)
5
> ctx:var
1
> (let ((ctx1:var 7)) ctx1:var)
7
> ctx1:var
nil
> (context? ctx1)
true
>

As we can see, context variables are the subject of dynamic scope and creation.

But the contexts themselves are NOT: if I create dynamic context variable, it will be destroyed when the code block is closed, but the context definition itself stays persistent.

Most people (and me too) have logical expectations that context will be destroyed as well.



The real expectation: the context symbols must behave like regular symbols:

- there must be a way to create them in MAIN (function 'context' does that)

- there must be a way to create dynamic context with 'let' declaration.

-- Such context must be initially clean (if not initialized imlicitly), despite of contents of the overlapped one.

-- This context must be destroyed according to common rules for 'let'.

-- It will be nice to have a native way to return context contents (can be partially imitated with 'source')

- there must be a way to reference to current dynamic scope context or to global defined context in MAIN.



Something like this :-)



P.S. yes, in most cases at present we can approve a small dictionary overhead for contexts that will rest after dynamic variable declaration, but  potentially, in situations of namespace overlapping, this will be the point of errors.

[Dmi]

Ghm... I got a joke on myself :-)

The nice context behavior, I proposed early is not applicable for "using context as for passing parameters by reference" because it is based on global/static property of the contexts.

That happens ;-)

[rickyboy]

I'm afraid [newLISP] is ... broken beyond hope of repair. It could be improved in minor ways ... but it's too little, to [sic] late.

Hmmm ... I know what's broken beyond repair -- and it's not newLISP -- it's Kogut, the language designed by the "impressive" genius Qrczak himself!  The http://sourceforge.net/projects/kokogut/files/">download page on SF, linked to from the http://kokogut.sourceforge.net/kogut.html">main page, indicates no significant developer activity in several years.  (Changing references to the author's email address in the source code listings 3 weeks ago, of course, doesn't count as "significant developer activity".)



Here's the user hangout: http://sourceforge.net/mailarchive/forum.php?forum_name=kokogut-users">http://sourceforge.net/mailarchive/foru ... ogut-users">http://sourceforge.net/mailarchive/forum.php?forum_name=kokogut-users.  It's mostly Qrczak and some dude named "Daniel" talking back at each other as if it were their private forum.  Hardly any of the activity that goes on here.  (One wonders, then, if Qrczak and Daniel are not indeed the same person.)



The http://kokogut.sourceforge.net/faq.html">FAQ is also telling.

The focus of the development of Kogut is making the code work correctly, not make [sic] it well-documented. Once Kogut has a stable codebase with tons of libraries, Marcin will spend more time on improving the documentation, but until then, it's up to the community.

Ha!  There is no community.  Kogut is dead.  This brings to mind something that http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=407#p2748">John Small said at the time: "The open market of ideas will insure the drift wood is carried out to sea and forgotten."  This piece of driftwood is long gone.



Rest in Peace, Kogut!



http://profile.ak.fbcdn.net/hprofile-ak-snc4/27526_128828310465519_4126_n.jpg">

[cormullion]

:)



Still, satisfaction ratings in the Kogut community must have been near 100% for most of its life, so that's something worth praising...

[newdep]

AHA!   So thats the language Qrczak was bragging about years ago...  



Lisp/scheme still has the longest breath ;-)  hahahah...