Hi Lawrence
Nice you're taking part here!
You're basically on the right track, but I think the things you mention don't work here, as picoLisp is strictly an interpreted language, there is no layer between source code and execution where such a name-mangling could happen.
The source code IS the programm, which also has the great advantage that no magic and no weird stuff is happening which is not in the source code.
There is namespace support in picoLisp ( http://thread.gmane.org/gmane.lisp.picolisp.general/2680 ), but currently I'm not sure if the problem is solved with it.
I stopped using it in my personal work for some reasons I don't remember on the top of my head, but I think it was about problems with definining a namespace in multiple/different files...
----- Original Message -----
From: Lawrence Bottorff [mailto:borg...@gmail.com]
To: picolisp@software-lab.de
Sent: Mon, 9 Feb 2015 20:23:16 -0500
Subject:
I'm a total Lisp noob (and a very rusty programmer), but from OO (Java, et
al) there is (behind the scenes, i.e., preprocessor) name mangling. There's
also tagging stuff with a huge hash generated numbers I say all this
because I'm hearing the need for uniqueness and anti-name-clash -- across
files and systems. Is that a correct assumption here? So when you call
"your" getBob function, some other code you're involved with doesn't think
that its (totally by chance also named) getBob function is meant. Am I on
the right track?
LB
On Mon, Feb 9, 2015 at 7:12 PM, <andr...@itship.ch> wrote:
> Hi list
>
> > Could we cook up a convention?
>
> Pretext
> ---------
> 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.
>
> DO WE REALLY NEED TO CREATE ANOTHER ONE?
>
> 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.
> Examples:
> @tgs/log/log.l
> @tgs/time/duration.l
> @tgs/time/tz-offset.l
> @tgs/time/utc2local.l
>
> 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.
> Examples:
> @x/cyborgar/web.l/...
> @x/regenaxer/osm/...
> @x/regenaxer/wiki/...
>
> -> 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)=
