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?


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

Reply via email to