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)
