Hi list

> Could we cook up a convention?

In this context I assume "modules" is meant not in the sense of program design but in the sense of "software packages", a format to download/copy a piece of picoLisp code (maybe accompanied by other files, e.g. pictures) and insert it into your own picoLisp environment and/or picoLisp application and getting it running without further manual adaption.

I see a potentially big advantage of such a formalized system, as it could greatly enhance picoLisp code reuse, and also work somewhat against the "Lisp Curse" [1] and the sometimes claimed "lack of libraries".

But it must be designed very carefully, keeping it as simple and short as possible, keeping it free from any assumptions (about the picoLisp environment or the layout of a picoLisp application) besides the absolute bare necessary ones, so no restrictions are put on the kind of code and applications using it. This thing is a easy path to bloatware, and to my understanding the picoLisp philosophy is all about precluding bloat.

So I see following problems:
1) identity: how to identify a module and all parts belonging to it?
  (uniquely and universal)
2) dependencies on other modules: how to verify if another module, which the current module depends on, is 'installed' (and functional) ?
3) versioning of modules?
4) upgrading/downgrading of a module version, also: being able to use multiple versions of a module in the same environment
5) name clashing, especially of picoLisp code/symbols/function names/class names/etcetera
6) lets assume modules are not only used to extend the picoLisp environment (e.g. stuff in "@lib/"), but also for applications and parts of applications - then there should probably a way to formulate which database schema / class definitions (and more!) a module requires/expects for the environment where it should run in.
7) documentation - how does the interested module user find out what a given module does and how does he/she decide if it solves his/her needs?
8) in which form would a module be distributed?
9) uniform method of error reporting, especially to spot the source of an error in a composition of modules
10) other problems?

Oh, special question
we have package manager on OS (e.g., apt-get), now we have all this hip programming languages with one or even multiple package managers each, ruby, node.js (npm), python?, .net, java?, php (pear and another one) and many more.


Maybe we could come up with a small tool, which can take picoLisp code (and a bunch of files) and create a package to use with one of those existing module/package managers?
I mean the question in the spirit of http://xkcd.com/927/

My thoughts on solutions
(previous question ignored for the moment)
Whenever I stumble on such common software design problems, I query the Wiki (that is the first original wiki, originally being a collection and discussion of Design Patterns).
A first search [2] brings some nice results like "What is a module" [3] and especially the "Module Dependency Problem" [4] (that one we should definitively look at!)
(I didn't study the Wiki entries entirely yet, so maybe there are better solutions mentioned there then what I think about below).

I was pondering about similiar stuff before, mainly to find a good way to organize my own code.
For the moment, I created a directory "tgs" in the picoLisp installation ("tgs" being a shortname for my personal framework).
In this directory I have several directories for different topics, and within those I keep *.l-files.

When I like to use a specific function I load the specific "function.l"-file. This can easily be done with (unless tz-offset.l (load "@tgs/time/tz-offset.l"))
I try to keep the individual files as granular and small as possible, often having only one function defined in such a file, so I can load single individual functions and avoid loading anything I don't need.

I also have directory "x" (for extra/external) where I put picoLisp code which is neither part of the standard distribution nor made by me.

-> So such a scheme may solve one part of problem 1), how the modules should look like on the filesystem when 'installed'


The biggest problem I see in 4), how to avoid or handle symbol name clashes.
Maybe this can solved with namespace system present in picoLisp, I'm not so sure because I'm currently not using it.
I think the current system somewhat requires for all definitions (which are meant to be in the same namespace) to be defined in the same go, probably for the best being defined all in the same file.
This works against the small granulation I prefer as described above.
Maybe someone with a better understanding of the picoLisp naming system (or someone who actually uses it - someone?) can say something about it.

I partly use a naming scheme of <namespace>:<symbol> for some stuff, mixing that with the standard picoLisp naming conventions:
+tgs:Class     -> class within 'tgs'
+tgs:class     -> abstract class within 'tgs'
+tgs:class:Foo -> one of multiple concrete implementations of a certain abstract class
tgs:foo        -> function (foo) within 'tgs'
I prefer ':' (colon) over '~' or '-' or other signs because I find it a smaller and more readable character, but it could give side effects if a used symbol is not defined and the readers startings looking for the shared library "tgs" (check the reference for special behavior of colon in symbol names).

And of course, this quickly produces loooooong symbol names, which can end in unreadable:stupid:stuff and also costs extra memory and performance when executed
I'm still unsure about that thing and use it inconsistently at the moment, as for most part I hadn't any symbol name clashes yet.

I think for actual usage to distinct from which modul a certain symbol comes from this is highly impractical.
Maybe there is a much better way, like when a module is load'ed, use short handy names unless a symbol is already defined, then use a longer explicit symbol name instead (but all references to that symbol have to be updated too!).


About 8), my first thought would be, that one picoLisp module should come just as one big foo.l-file, then it could contain definitions and even execute code which 2) checks dependencies.
This would fail as soon as one likes to pack not only picoLisp code but also arbitrary files, so we will end up with a directory and so with a .zip or better with a .tgz-file (similar to distribution of standard picoLisp).
What about: module is a directory, it consists of the files it requires, and one special file, e.g. MODULE.l, which must define a set of functions:
- (version) -> give the modules version number similiar to "pil -version"
- (module) -> a symbol/string being the unique identifier for that module
- (dependencies) -> a list of unique identifiers of modules this module depends on
- (creator) -> information about the creator of the module
- (license) -> information about the licensing of the module (well, not sure if anything beside MIT-style is really practicable ...)
- (install) -> check the setup and create/update stuff if needed
- (remove) -> clean up
- what more?
So one could query this thing, e.g. with "pil modules/mymodule/MODUL.l -dependencies" or even "mymodule/MODUL.l -version" when hashbang is present.
Not sure if these are a good ideas or not, especially looking at install/remove :-|


Wow! You made it! You read through this entire wall of text? Congratulations and thank you.
Have fun reading some more following the mentioned references...

[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
[2] http://c2.com/cgi/wiki/wiki?search=Modul
[3] http://c2.com/cgi/wiki/wiki?ModuleSystem
[4] http://c2.com/cgi/wiki/wiki?ModuleDependencyProblem

----- Original Message -----
From: Jakob Eriksson [mailto:ja...@aurorasystems.eu]
To: picolisp@software-lab.de
Sent: Mon, 09 Feb 2015 20:23:13 +0100

Could we cook up a convention?

On February 9, 2015 6:12:17 PM CET, Henrik Sarvell <hsarv...@gmail.com> wrote:
Hi Lawrence, if you're talking about something like Ruby's gems, then no.

On Mon, Feb 9, 2015 at 5:45 PM, Lawrence Bottorff <borg...@gmail.com> wrote:
I'm wondering what you offer in lieu of modules (as with, say, Python) Is there a "black box" way to "package up" code in picoLisp that has module-like serviceability?


Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Reply via email to