Request: Function to give context given symbol

[cormullion]

Ah - I missed all the fun... :( My newsreader has obviously stopped working, with no updates since last week...



Glad to see new features and functions being added to newLISP... But (as usual) I'd like to register a mild protest at proposed changes that break existing code without adding much or anything in the way of new functionality. (I always say this... ;) I'd prefer to see lots of working newLISP examples on the web, rather than a few highly version-dependent scripts.



(cormullion - a synonym for curmudgeon... )

[hilti]

I'd prefer to see lots of working newLISP examples on the web

You're so right cormullion! Most good scripting or programming languages aren't recognized, because their users are doing "research for highly optimized code" instead of keeping it simple stupid (KISS). I think that's why PHP is widely used: most of the scripts aren't optimized and maybe crappy, but they do their work.



I started Dragonfly to do a little bit marketing for newLISP because I like this language. In my non-technological view I would say: it feels good! But at the moment I'm searching for the real newLISP kick-ass application, because Dragonfly seems not to be the one.



Although ruby profits by the rails framework, I think ;-)



Cheers

Hilti

[m i c h a e l]

cormullion has a valid point, and it must be especially hard for people with large code bases to update when something changes. And yet it's also prudent to use this opportunity to perfect the language while relatively few are using it. Lutz said he wanted to keep the language stable and see more projects being created, but let's face it: Lutz is a language hacker at heart and will probably never stop tweaking newLISP. Isn't it better for a language continue growing and adapting to the world around it? Picasso once said that as long as an artist continues to work on a canvas, it's alive, but as soon as the painting is hung in a museum, it's dead. Change is life!



As for new functionality, I see term as giving us the ability to use name as a variable.



Perhaps the real solution is to find a method that gracefully handles all newLISP versions without needing to change any code. Loading modules to modify newLISP to mimic the older versions, maybe. Or a special multi-version compilation of newLISP that sacrifices size (and maybe even speed) to enable all code to run without change. In most cases, though, a change like name to term only requires a simple search and replace, so any implementation mustn't require more work than it saves.



Viva newLISP!



m i c h a e l

[itistoday]

Perhaps the real solution is to find a method that gracefully handles all newLISP versions without needing to change any code

You know I thought I gave a pretty good generic solution to this problem (see above) that would allow backwards compatibility with existing code while at the same time giving us 'name' back, and it seems to have been largely ignored...

[Kazimir Majorinc]

Yes, you did itistoday.



#  Attempt to resolve symbol

# If fails, attempt to resolve symbol in deprecated map



OK, it is for deprecated words. It requires that Newlisp carry on deprecated functions as well. However, It is not unreasonable idea. It increases "the weight" of the Newlisp, but not really much - it is now 1MB, and it might be, say, 2MB in next 10 years.



Even explicit control of the version by programmer might be possible](legal-on-date '(October 10 1975) ;legal-in-version is also possible
   (println "please, donate for campaign "Carter for president!")
    ... ))[/code]
Possible advantages are:

[*] All standalone programs can work forever. New version of Newlisp interpreter can call old version, or issue specific warning if old version of Newlisp is not installed.

[*] Libraries and code requiring mix of versions can work as long as difference is only in names and behaviour of the primitives. One can even mix the code that contains different definitions of the same function, say inc (inc 'x) and (inc x).

[*] Changes in interpreter semantics can (but do not necessarily) make some mixes of old and new code impossible. In that case, specific warning can be given - even in advance. Say "The code legal on (October 10 1975) is mixed with new code. It works in the current version 14.99. It might stop working in version 15.00 and higher. Please take appropriate action if you wish to update."

[/list][/color]



Of course, it is not easy work ...

[Lutz]

Who has been following newLISP for the past 10 years, will see, that disruptive version upgrades where much more dramatic earlier and got less over time. The last more dramatic changes where for v.10.0.0, and most people got over it pretty well ;-). In my own software changes where done quickly even for that version.



All major versions have an updated "Deprecated functions and future changes" in the users manual. In the release notes of v.10.0.0 there was also a "Conversion Guide". And we will have conversion recommendations in 10.2.0 too for imdividual functions.



Lots of suggestions in this threads for things to add to newLISP to handle version incompatibilities. All of them are too costly for what they add in size and complexity and take away in loading performance.



But who feels strong about this, could use 'reader-event' to write a function handling function deprecation.



For the standard modules I did the following, to make them compatible with passed versions and future versions:



All integer applications of 'inc' and all applications of 'name' where replaced with the new '++' and 'term'. The 'inc' -> '++' change was only necessary in code where foreign functions are imported, newLISP's own functions never mind to take a float 1.0 as an integer 1 or the other way around.



The following regular expresssion where used for UNIX grep and in the VI editor to find the critical spots.



for inc -> "(inc "

for name -> "(name "



I also replaced 'read-buffer' and 'write-buffer' with 'read' and 'write', but the longer deprecated versions will stay (undocumented) for several official releases more.



After converting, I put the following lines at the top of the modules, to make them compatible with older versions:

Code Select Expand

; canvas.lsp:

; works only if write-buffer is used without the N-of-bytes parameter
(when (< (sys-info -2) 10110)
    (constant (global 'extend) write-buffer))

; postgres.lsp

; make this module compatible with version less than 10.1.11
(when (< (sys-info -2) 10110)
    (constant (global '++) inc))

; sqlite3.lsp

(when (< (sys-info -2) 10111)
    (constant (global 'term) name))

(when (< (sys-info -2) 10110)
    (constant (global '++) inc))

; stat.lsp

(if (< (sys-info -2) 10111)
    (constant (global 'term) name)


[itistoday]

All of them are too costly for what they add in size and complexity and take away in loading performance.

The deprecation map would add hardly anything in size. Maybe 1KB, max. As time went on it would get smaller in size because items would be removed from it. Eventually it could be removed if there was nothing in it.



If implemented properly, I doubt this would have much of an impact on performance. If you argue that it will you can easily check to see if you're right by doing a couple of benchmarks.



A deprecation map would discourage you from making changes that break people's existing code for the sake of "function brevity". I honestly see little justification in changing 'write-buffer' to 'write', etc. (use an editor with auto-complete!). If newLISP is to become more widely used, these sorts of changes need to stop, or, you can do them, but safely with a deprecation map. A deprecation map would allow you to safely rename functions at your whim. Without it, if nfshost decides to upgrade their newlisp installation, then just like that, all the newlisp powered websites they host could go down. That's not a very nice thing to do to people.

[cormullion]

Well I'd contribute to this (somewhat threadjacked) thread with a considered post, but I don't have the time at present.



Still, I expect that most of you know what I'd say... newLISP needs a stable development environment, a wide selection or working libraries and modules, and a thought-out development strategy far more than it needs the perfect terminology.

[m35]

May I step back a bit to the discussion of the new function names :)

sym-name and sym-context where good suggestions too, but I am trying to slowly move to shorter (but still recognizable) function names. E.g. many versions back sym was symbol and int was integer (integer is still recognized but not documented anymore).

I'm a huge fan of verbosity. It's a big reason why I picked up newLISP while ignoring Common LISP. All those CL shortcut symbols (e.g. `@.&:#,) probably make it easier to write impressive code, but it looks like chicken scratch to me. It's also why I like Java (and probably Objective-C if I used it more). Coding is hard, so my brain really likes things clearly spelled out. Today's editors take care of the extra keystrokes and parse outlines (and parentheses matching). Maybe back in the day I could understand keeping things shorter being useful, but I don't see how shorter symbol names add value to newLISP.



With that perspective sym-name, and sym-context are beautiful to me.

[m i c h a e l]

Correctly naming things is one of the most important tasks a programmer faces. The difference between code that is intelligible and code that is incomprehensible is the quality of the names chosen. When Lutz decides on a name, it's a reflection of his thoughtful (and sometimes tormented) consideration. The language itself is a record of this.



More modules means more functionality, yes, and maybe even greater acceptance, but someone has to write them first. We can't be afraid to develop something simply because the language may change. That would be like someone refusing to participate in life simply because they find out it will never be perfect. We must be willing to accept change and imperfection to fully embrace life. In the unforgiving context of programming, it's sometimes easy to forget that.

You know I thought I gave a pretty good generic solution to this problem (see above) that would allow backwards compatibility with existing code while at the same time giving us 'name' back, and it seems to have been largely ignored...

You did, Greg, and for all I know, it may be where I got the idea. I sometimes feel ignored here, too, but I don't think it's ever personal. I mostly read without commenting myself. Especially when the conversations become more technical and my mind begins to wander ;-)



I definitely do read and appreciate everyone here. And because we are such a small group, that means everyone's contribution matters that much more.



m i c h a e l



P.S. Can depreciated names be implemented in such a way that they continue to refer to the original but will not complain when overwritten? Like changing them from constants to variables. That would be one small step toward minimizing code disruption.

[itistoday]

P.S. Can depreciated names be implemented in such a way that they continue to refer to the original but will not complain when overwritten? Like changing them from constants to variables. That would be one small step toward minimizing code disruption.

That's pretty much the effect achieved by the depreciated/depricated map I described.

[itistoday]

Just an update to this thread, http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=3485&p=17726#p17726">newlisp 10.1.11 makes for-query-with-db possible! :-)