While looking deeper into the semantics of dynamic symbols, there has been this unexpected behavior:
sr@freen:~/newLISP$ newlisp
newLISP v.10.6.5 64-bit on Linux IPv4/6 UTF-8 libffi, options: newlisp -h
>
(set 'sy nil)
(define (f) (println 'sy:bar))
(delete 'sy)
(f)
nil
(lambda () (println 'sy:bar))
true
�~�:bar
bar:bar
>
When a deleted symbol was prefix in a dynamic symbol, memory got corrupted. The dynamic symbol reference is now replaced with
http://www.newlisp.org/downloads/development/inprogress/
Thanks, Lutz!
By your fix a 'Bus error' related to this problem has disappeared, too (in a more complex scenario: had just given a minimal version to trigger the problem).
[Update with full example]
Unfortunately I have to put some water into the wine...
newLISP v.10.6.5 64-bit on Linux IPv4/6 UTF-8 libffi, options: newlisp -h
>
(set 'sy nil)
(set 'foo MAIN)
(define (f) (foo:println 'sy:bar))
(delete 'sy)
f
nil
MAIN
(lambda () (foo:println 'sy:bar))
true
(lambda () (nil 'nil))
>
Fix is nil'ing too much...
I sometimes wish "referring" to a unknown symbol wasn't the same thing as "defining" it. perhaps if all symbols were stuck into the "undefined" context until they were properly defined by "set" or "define". Perhaps instead of "global" being a property of a symbol, global symbols would be moved to the GLOBAL context...
Corrected: http://www.newlisp.org/downloads/development/inprogress/
To Ted:
Requirement to define / declare variables also makes programming less casual and less interactive. Perl has a strict mode to turn it on and of. But not sure if its worth the additional code. One of the things people like about newLISP is, that it is fully dynamic.
Yes, I like the fully dynamic nature of newLisp. But, this summer, I ran into a lot of problems in coding with a team, because it was a big mystery where things were being defined. And using symbols that were expected to be defined but weren't, caused big headaches. The bug could cascade and cause errors far down the line. Not sure what is the right solution to that, but a "strict" mode for debugging would be nice.
I was thinking about debugging in another way: line numbers. If tokens were tagged with a line number when read from source, and also inherit line numbers from whatever altered them, that might make debugging easier. I'm not sure, did LISP ever have compilers that locate errors on a line? Is there some other debugging idiom? Being able to dump the state machine with a pointer showing where the error was in that code, would also be helpful. By state machine, I mean the output of (save). Sort of like the way SmallTalk snapshots the VM.
Now, for speed, I'm sure both of these suggestions are terrible. But for debugging, I think they would be useful. Be nice to have a parallel version of newlisp for this type of stuff.
Thanks for the info