newLISP installs with several modules that one can load separately, including cgi.lsp and crypto.lsp. See /usr/share/newlisp/modules
I'm interested in using these but I want to be sure I avoid potential name clashes. Some of the contexts created by the individual modules are lower case and others are upper case (which I take to be the traditional convention for context names).
Is there another convention at work here that I'm unaware of?
Thanks,
John
Module Contexts
Probably they should be named all by the same convention. I find all uppercase too "load" when reading code, but how about uppercase for the first character only, as in:
Cgi
Crypto
Ftp
Gmp
...
This way we retain the uppercase convention for namespaces, but easier on the eyes.
What do others think about this this?
Cgi
Crypto
Ftp
Gmp
...
This way we retain the uppercase convention for namespaces, but easier on the eyes.
What do others think about this this?
-
cormullion
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
There are many different types of consistency. You could have:
- consistency with a guideline, such as "first letter is uppercase, all other characters lower"
- consistency with established usage, such as "FTP, GMP, CGI - these are all accepted abbreviations and are usually in all upper-case
- de facto consistency with, or at least compatibility with, existing code and newLISP installations everywhere which expect CGI, Crypto, SMTP, and so on, since that's what they are at the moment.
But you can't follow every type of consistency.
My suggestion: upper-case first letter, unless for a standard recognised abbreviation. Guideline to apply to future context names, of course - it would be silly indeed to break all existing code just for the sake of a fairly minor and arbitrary capitalization issue!
Even better - forget the minor issue of consistency, and let's have loads of really useful new libraries and modules with names as inconsistent as you like. Any dismay at the poor orthography will be greatly alleviated by delight at the new functionality .. :)
- consistency with a guideline, such as "first letter is uppercase, all other characters lower"
- consistency with established usage, such as "FTP, GMP, CGI - these are all accepted abbreviations and are usually in all upper-case
- de facto consistency with, or at least compatibility with, existing code and newLISP installations everywhere which expect CGI, Crypto, SMTP, and so on, since that's what they are at the moment.
But you can't follow every type of consistency.
My suggestion: upper-case first letter, unless for a standard recognised abbreviation. Guideline to apply to future context names, of course - it would be silly indeed to break all existing code just for the sake of a fairly minor and arbitrary capitalization issue!
Even better - forget the minor issue of consistency, and let's have loads of really useful new libraries and modules with names as inconsistent as you like. Any dismay at the poor orthography will be greatly alleviated by delight at the new functionality .. :)
Much as I would welcome new sets of useful libraries I think attention must also be paid to the framework in which they are loaded and simple ways for new users to create an use libraries within this framework.
I've been using newLISP for several years now and there is no doubt it is the first language I think of using and the one I develop in first even when I must produce code in some other language. But the one key feature that draws me to Perl or Python (among others) is the ability to load modules in systematic, conventional ways.
I agree it is unwise to break existing code (on the other hand, sometimes we receive a large benefit in return, as in the case of changing "unless"). What I am suggesting is a package loading mechanism that does not require knowledge of the /usr/share/newlisp directory itself. It would be aware of the modules shipped with newLISP and would protect their respective contexts. My interest in a convention for the names above is to enable simple inclusion of new modules with a naming mechanism that doesn't overlap.
I'm sure I haven't thought of all the contingencies here. From reading the replies to my original post it seems that consistency isn't so much what I'm looking for. It's more a statement about the convention for naming those modules and contexts that are included by default, and a proposal to simplify loading both these and user generated modules.
John
I've been using newLISP for several years now and there is no doubt it is the first language I think of using and the one I develop in first even when I must produce code in some other language. But the one key feature that draws me to Perl or Python (among others) is the ability to load modules in systematic, conventional ways.
I agree it is unwise to break existing code (on the other hand, sometimes we receive a large benefit in return, as in the case of changing "unless"). What I am suggesting is a package loading mechanism that does not require knowledge of the /usr/share/newlisp directory itself. It would be aware of the modules shipped with newLISP and would protect their respective contexts. My interest in a convention for the names above is to enable simple inclusion of new modules with a naming mechanism that doesn't overlap.
I'm sure I haven't thought of all the contingencies here. From reading the replies to my original post it seems that consistency isn't so much what I'm looking for. It's more a statement about the convention for naming those modules and contexts that are included by default, and a proposal to simplify loading both these and user generated modules.
John
For a platform independent, unique way to load modules see here:
http://www.newlisp.org/downloads/newlis ... nvironment
Regarding naming conventions:
In general the convention to title-case the names of contexts is a good idea, because contexts are treated very differently from other objects in the language. They always get passed by reference when used as function arguments, and when occurring in place of a list, array or string argument of a built-in fnctions, they default to their default functor, i.e. when writing: (nth i MyList) then MyList will default to MyList:MyList if MyList is a context. The same happens when using the context names in the function/operator position of a s-expression. In these types of context usage, title-casing the namespace name serves the purpose of making this special type of variable visible when reading and understanding code.
When using context names as prefixes in function and variable names the situation is different. The colon character ':' signals already that, the name preceding the colon is a context name, and upper-casing it is much less important.
Reviewing the modules available here: http://www.newlisp.org/modules/ , it turns out that, neither the shipped modules nor the once supplied by other parties follow a strict naming convention. Though title-case and all upper-case seem to be prevalent, all lower-case is used too. Some modules even use the MAIN space to implement their functionality. This seems Ok, when the module implements general utility type of functions as in EnFeutec's funlisp.lsp or Artful Code's funtional.lsp. Both also make their functions global, putting them on the same level as built-in primitives of the language.
For now I will follow Cormullion's suggestion and leave the naming of shipped modules like it is.
http://www.newlisp.org/downloads/newlis ... nvironment
Regarding naming conventions:
In general the convention to title-case the names of contexts is a good idea, because contexts are treated very differently from other objects in the language. They always get passed by reference when used as function arguments, and when occurring in place of a list, array or string argument of a built-in fnctions, they default to their default functor, i.e. when writing: (nth i MyList) then MyList will default to MyList:MyList if MyList is a context. The same happens when using the context names in the function/operator position of a s-expression. In these types of context usage, title-casing the namespace name serves the purpose of making this special type of variable visible when reading and understanding code.
When using context names as prefixes in function and variable names the situation is different. The colon character ':' signals already that, the name preceding the colon is a context name, and upper-casing it is much less important.
Reviewing the modules available here: http://www.newlisp.org/modules/ , it turns out that, neither the shipped modules nor the once supplied by other parties follow a strict naming convention. Though title-case and all upper-case seem to be prevalent, all lower-case is used too. Some modules even use the MAIN space to implement their functionality. This seems Ok, when the module implements general utility type of functions as in EnFeutec's funlisp.lsp or Artful Code's funtional.lsp. Both also make their functions global, putting them on the same level as built-in primitives of the language.
For now I will follow Cormullion's suggestion and leave the naming of shipped modules like it is.
-
cormullion
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
-
cormullion
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Thanks! There's enough to do at the moment... :)Lutz wrote:For now I will follow Cormullion's suggestion and leave the naming of shipped modules like it is.
I've got three versions of newLISP installed at the moment: 9.3, 9.4.5, and 9.9. It's possible for a newLISP script written in any one of these versions to be incompatible with the other two. Not perhaps the ideal time to be writing library modules...
I'm really hoping that next year we'll see a more stable platform, and a focus on extending, using, and promoting the language rather than just changing it.