Request: Function to give context given symbol

[Lutz]

I still like 'path' best, but how about 'space' ? What does Cormullion think about all this? I want something short!

[TedWalther]

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 symname and symcontext  And for teh win in shortness, how about symnm and symct?  nm being an abbreviation for "name" and ct being an abbreviation for "context".  symnm is only 1 character longer than name, and symct is only 1 character longer than path.  And I think they signal pretty well what they do, ie, operating on symbols.

Code Select Expand


(setq a 'Foo:b)

(symname a) => b
(symname 'Foo:b) => b

(symcontext a) => Foo
(symcontext 'Foo:b) => Foo


[itistoday]

I still like 'path' best, but how about 'space' ? What does Cormullion think about all this? I want something short!

What's wrong with context-of? It's not going to be a very often used function, and there are plenty of newLISP functions that are longer (write-buffer, bayes-query, remove-file, etc.). context-of isn't long, and it's very clear what its purpose is.



Neither 'path' nor 'space' tell me that the function gives the context of a given symbol.



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: sym-name, sym-context.

[itistoday]

There are several neat aspects to sym-context and sym-name:


[list=1]

[*] They tell you almost exactly what the function takes and what it returns

[*] They avoid conflicts in code with commonly used symbol names

[*] They "complete the picture" with sym, creating the "sym family of functions"

[/list]

[Lutz]

How about 'prefix' ?

Code Select Expand

(setq s 'Foo:bar)

(prefix s) => Foo

A more generic term, not as specific as the other suggestions, but short, immediately understood, and name clashes not very likely.

[m i c h a e l]

Yes, I like prefix, but does that mean we can change name to suffix, too? Like many others, I'm constantly bumping into name because it's such a natural name for a name ;-)



m i c h a e l

[kks]

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"!)

[Lutz]

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 middle surrounded by prefix and suffix, but I may be wrong on this. I consulted http://www.dict.org">http://www.dict.org



xytroxon suggested root for the prefix, then name could be perhaps 'leaf' as in <prefix>:<leaf>, ... sigh ... still don't like it.

[m i c h a e l]

You're right about suffix, Lutz. I was half-joking about the suggestion, but I'm serious about the problems encountered with name (as you acknowledge here). When I asked Melissa—the source of all things grammatical—what comes between prefix and suffix, she said term. Would this work?



m i c h a e l

[Lutz]

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!

Code Select Expand

(setq s 'Foo:bar)

(= 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.

[itistoday]

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).

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 caller function be in the next release too?

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.

How about modifying newLISP to include a deprecated map of functions?



The evaluator would work like this:

[*] Attempt to resolve symbol

[*] If fails, attempt to resolve symbol in deprecated map

[*] If found, use that old version and print an warning message to stderr saying that the function is deprecated and will be removed in a future version

[/list]

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:

Code Select Expand

(name 'Foo:bar)

Both versions would work, and the second version will print the warning message, but would still work. :-)

[xytroxon]

So I guess Occam's Razor means that:

Code Select Expand


> (Got-FOOP?  symbol-name)
true

> $ctx
symbol-context


is out of consideration also???



-- xytroxon  ;p)

[Kazimir Majorinc]

In http://kazimirmajorinc.blogspot.com/2009/12/symbols-as-sexprs.html">one of my last blogposts, I came to the conclusion that it is beneficial to use lists as symbol names, and con:var can be seen as (con var) written in different syntax, so overload of



first

last



might be good choice, or even better sym-first, and sym-last (I do not like overload by default.) Advantage is that there is no need for new words. It is not good when new words are introduced for already existing concepts.



In some distant future (say Newlisp 20.0.0), you might think about developing this concept further to nested contexts and have sym-nth and (sym-first (sym-first s)) working and so forth.



Actually, it is already possible to define (sym-nth i s) that works for i=0 and i=1.

[TedWalther]

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?

[Lutz]

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: RuleTalk, which was a Prolog like language. It featured contexts inside context. Nested contexts lead to over complicated and ugly code, hard to maintain and debug. That was my experience with RuleTalk.



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').