As far as avoiding getBob clashes PL already has class and namespace functionality.
On Tue, Feb 10, 2015 at 2:23 AM, Lawrence Bottorff <borg...@gmail.com> wrote: > 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"  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  brings some nice results like "What is a module"  > > and especially the "Module Dependency Problem"  (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) >