This would be a lifesaver, I've found myself needing this so many times: a function to give me the context of a symbol.
I.e. check out this awesome function:
(letn (db (eval db) sql (db:prepare-sql query) keys '())
(dotimes (i (sql:col-count))
(push (sym (upper-case (sql:col-name i)) ctx) keys -1)
)
(push-autorelease-pool) ; in case we have blobs
(while (list? (setf values (sql:next-row)))
(eval (expand (cons 'begin $args) (unify keys values)))
)
(pop-autorelease-pool)
(deallocate sql)
)
)
It can't live because the body ($args) uses symbols in a different context. I have to manually *tell* 'sym' what context the symbols in the body are coming from.
This function is going to be in Dragonfly 0.61, it will let you do stuff like this:
<tr><td>ID</td><td>Name</td><td>Age</td></tr>
<% (for-query-with-db db "SELECT rowid,name,age FROM people" %>
<tr><td><%=ROWID%></td><td><%=NAME%></td><td><%=AGE%></td></tr>
<% ) %>
</table>
That's pretty great, but currently this will just show a bunch of nil's. To get it to show the right values I have to hack it up and make it ugly:
<tr><td>ID</td><td>Name</td><td>Age</td></tr>
<% (for-query-with-db db "SELECT rowid,name,age FROM people" DF %>
<tr><td><%=ROWID%></td><td><%=NAME%></td><td><%=AGE%></td></tr>
<% ) %>
</table>
I could get rid of that 'DF' on the end if there was a (sym->ctx) function available. There are so many other cool things you could do if such a function existed. Can such a function be brought into newLISP?
There is one in the next version:
> (setf s 'Foo:bar)
Foo:bar
> (path s)
Foo
> (context? (path s))
true
> (context (path s))
Foo
Foo>
Awesome! Thanks Lutz! :-D
(I would only advise against using 'path' for the name, as that is probably used in a lot of existing newlisp code, and making it a primitive would break all of that code).
Also, will it work with non-symbols? i.e:
(blah "asdf") => MAIN
Perhaps "path" would be too easily confused with basename/filename type of operations? Perhaps "context-of" would be a better name?
Ted
I like "context-of". Use of "of", "is", "from", "to" etc. is, I believe, good naming practice.
Symbol names as strings:
It cannot work on strings because the context of a symbol is encoded with the symbol. The symbol with the name "blah" could be in several contexts. One could check if "blah" is present in a specific context:
(sym "blah" MAIN nil) => nil
(sym "blah" Foo nil) => Foo:blah
This tells us that "blah" is not present in the current context and not in MAIN, but is defined in Foo. The 'nil' parameter tells 'sym' not to create the symbol, if not present.
Naming of the new function:
Name clashes with new function names are always a possibility, and we always have had these in the past. I remember introducing 'name', which caused a lot of clashes being used in many web forms. I don't think it is a good practice to make the name more complicated for the sake of avoiding name clashes. Perhaps it should be practice to making
Conceptually 'name' and 'path' belong together:
(= s (sym (name s) (path s))) => true
In other areas in computing, i.e. file systems, the same labels are used to describe tree structures. See: path-name or pathname, path in a symbol tree.
Fortunately built-in symbols are protected. So a name clash is pretty obvious accompanied by an error message.
Thanks for the reminder about the (name) function. I see your point, and agree; name and path are a good pairing.
Quote from: "Lutz"
It cannot work on strings because the context of a symbol is encoded with the symbol. The symbol with the name "blah" could be in several contexts. One could check if "blah" is present in a specific context:
I think you misunderstood me, and I think it's my fault. I think what I'm asking for is may not be addressed by this path function. In the original function that I gave, what I want to be able to do is to find out the context an fexpr is called in. Here's an updated version of it using path:
(letn (db (eval db) sql (db:prepare-sql (eval query)) keys '())
(dotimes (i (sql:col-count))
(push (sym (upper-case (sql:col-name i)) (path query)) keys -1)
)
(push-autorelease-pool) ; in case we have blobs
(while (list? (setf values (sql:next-row)))
(eval (expand (cons 'begin $args) (unify keys values)))
)
(pop-autorelease-pool)
)
)
See the (path query)? I want that to return the context that the fexpr was called in, because otherwise I can't use 'for-query-with-db' in any context other than its own (without manually specifying it when calling it).
You mean the callee knowing about the caller?
(define (Foo:func) (Bar:func))
(Foo:func) => Foo:func ; or Foo
Quote from: "Lutz"
(define (Foo:func) (Bar:func))
(Foo:func) => Foo:func ; or Foo
Yes! (path (caller)) looks like it should work, especially if it works with macros as well. I can only imagine the kinds of things you could do with this. Many thanks!
I always think of the file system when I see
And why wouldn't it be called
And Dragonfly uses "path" in it's framework libraries, breaking a site's installation on a minor newLISP release...
If I remember right, Clojure uses
From the newlisp manual: context
-----------------------------------------------
In the second syntax, context can be used create symbols in a
-----------------------------------------------
(Also found a manual error: can be used
> (setf s 'Foo:bar)
Foo:bar
> (namespace s)
Foo
> (context? (namespace s))
true
> (context (namespace s))
Foo
Foo>
-- xytroxon
I second (third?) xytroxon's comments, and I think he picked a good names for it; 'namespace' is good, 'root' is slightly less descriptive and more likely to break existing code, but it's still better than 'path'. I think breaking existing code frequently by using commonly used names like 'name' and 'path' is a bad thing, and could scare people away from newlisp. Further, 'path' is a legitimate name to use for many other things, it would be a great loss to not be able to use it.
Since contexts
m i c h a e l
Quote from: "m i c h a e l"
That's a good point, in light of that I vote for Kazimir's
I still like 'path' best, but how about 'space' ? What does Cormullion think about all this? I want something short!
Holy smokes, this thread has gone on long. Now that Lutz explained it, I like his original two choices of name and path.
But if we are voting on alternatives, then I would vote to rename the functions
(setq a 'Foo:b)
(symname a) => b
(symname 'Foo:b) => b
(symcontext a) => Foo
(symcontext 'Foo:b) => Foo
Quote from: "Lutz"
What's wrong with
Neither 'path' nor 'space' tell me that the function gives the
I also like TedWalther's alternate suggestions as that would give us back 'name', but I would suggest they be hyphenated to fit with the rest of newLISP's functions:
There are several neat aspects to
[list=1]
How about 'prefix' ?
(prefix s) => Foo
A more generic term, not as specific as the other suggestions, but short, immediately understood, and name clashes not very likely.
Yes, I like
m i c h a e l
I like itistoday's `sym-context`.
What if "warning" is used instead of "error" when name clashes (redefining protected names)? Old code can be run without changes, because it didn't mean to use the "new" definition of the names.
By the way, I use a naming convention that starts "variables" with an uppercase letter (got the idea from PicoLisp), to prevent name clashes with "functions". (But then they may clash with "classes"!)
Thanks for all the suggestions!
It will be 'prefix' then. It is a term often used in science with Latin roots and probably recognizable by many non-English speakers too.
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).
In version 10.2.0 'read' and 'write' will be allowed as shorter writing of the elementary I/O operations 'read-buffer' and 'write-buffer' which will still be valid for a long time.
I share Michaels feeling about clashing with 'name', which also still happens to me, on the other side I cannot think of a better word for it. I decided for 'prefix' because I started to agree that there are to much clashes with 'path', e.g. there is already 'real-path' in newLISP referring to files/directories.
I am also not sure if 'suffix' would be technically correct. As I see the meaning of the words prefix and suffix, it is: prefix-TheName-suffix, so in newLISP Foo:bar Foo is the prefix and bar is TheName. As Michael suggests it would be: Foo is the prefix and bar is the suffix (something missing in the middle ?!). What I mean is, that prefix/suffix implies that something is in the
xytroxon suggested root for the prefix, then name could be perhaps 'leaf' as in <prefix>:<leaf>, ... sigh ... still don't like it.
You're right about
m i c h a e l
Yes, 'term' absolutely works and it is short too and a beautiful word! 'term' will be introduced in the coming release version 10.2.0 (or any development version before it).
I knew, we needed and English professor to solve this ;-), many thanks to Melissa!
(= s (sym (term s) (prefix s))) => true
Ps: a quick check in the standard modules shows, that gmp.lsp, mysql.lsp, odbc.lsp, postgres.lsp sqlite.lsp and stat.lsp are affected. So perhaps we keep both for some time and let 'name' die slowly through deprecation; having the reference entry for 'name' saying: "please use 'term' instead", but keep it working for some time.
Quote from: "Lutz"
Yay, I'm glad we've come to a conclusion on this, this way I can update Dragonfly to support existing versions of newLISP and this upcoming one.
Will the
Quote
How about modifying newLISP to include a deprecated map of functions?
The evaluator would work like this:
That way no code breaks, you'll have a new mechanism to alert users of these sorts of changes, *and* users can immediately begin using 'name' as a symbol.
For example, in the next release, someone could write this code with no problem](set 'name 5)[/code]
At the same time, someone else could write this code with no problems too:
Both versions would work, and the second version will print the warning message, but would still work. :-)
So I guess Occam's Razor means that:
> (Got-FOOP? symbol-name)
true
> $ctx
symbol-context
is out of consideration also???
-- xytroxon ;p)
In
last
might be good choice, or even better
In some distant future (say Newlisp 20.0.0), you might think about developing this concept further to nested contexts and have
Actually, it is already possible to define
Kazimir, I like your sym-first and sym-last. It does make conceptual sense, based on how the default functor works.
Regarding version 2.0, for there to be nested contexts, Lutz will have to re-implement closures, which LISPers are claiming can be done efficiently these days. But wouldn't closures negate the benefits of ORO? And once we go the route of closures, won't continuations be next? What cans of worms will that open?
Having only one level of contexts in newLISP is an arbitrary design decision made early on in newLISP development and has nothing to do with the absence of SCHEME-like function closures in newLISP.
The symbol and context system in newLISP comes from one of my earlier language projects:
This topic has been discussed many times over the years. To make a long story short: There will never be nested contexts in newLISP.
To clear up confusion about upcoming functions, these are the new functions in the next version: 'caller', 'prefix', 'term' (like 'name').
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... )
Quote
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
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
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
Viva newLISP!
m i c h a e l
Quote from: "m i c h a e l"
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...
# 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:
[/color]
Of course, it is not easy work ...
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:
; 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)
Quote from: "Lutz"
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.
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.
May I step back a bit to the discussion of the new function names :)
Quote from: "Lutz"
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
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.
Quote from: "itistoday"
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.
Quote from: "m i c h a e l"
That's pretty much the effect achieved by the depreciated/depricated map I described.
Just an update to this thread,