Even if that were so, couldn't we fix this with a convention in the module loader? That is, the loader concatenates all files into one upon loading.
Is this crazy talk? On February 10, 2015 9:47:54 AM CET, andr...@itship.ch wrote: >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)= -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
