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
>I'm a total Lisp noob (and a very rusty programmer), but from OO (Java,
>al) there is (behind the scenes, i.e., preprocessor) name mangling.
>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 --
>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
>that its (totally by chance also named) getBob function is meant. Am I
>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
>> 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.
>> 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
>> greatly enhance picoLisp code reuse, and also work somewhat against
>> "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
>> bare necessary ones, so no restrictions are put on the kind of code
>> applications using it. This thing is a easy path to bloatware, and to
>> 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,
>> 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/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
>> schema / class definitions (and more!) a module requires/expects for
>> environment where it should run in.
>> 7) documentation - how does the interested module user find out what
>> given module does and how does he/she decide if it solves his/her
>> 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
>> programming languages with one or even multiple package managers
>> ruby, node.js (npm), python?, .net, java?, php (pear and another one)
>> many more.
>> Maybe we could come up with a small tool, which can take picoLisp
>> (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
>> Wiki (that is the first original wiki, originally being a collection
>> discussion of Design Patterns).
>> A first search [2] brings some nice results like "What is a module"
>> and especially the "Module Dependency Problem" [4] (that one we
>> definitively look at!)
>> (I didn't study the Wiki entries entirely yet, so maybe there are
>> 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
>> ("tgs" being a shortname for my personal framework).
>> In this directory I have several directories for different topics,
>> 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
>> "@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
>> individual functions and avoid loading anything I don't need.
>> I also have directory "x" (for extra/external) where I put picoLisp
>> 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
>> so sure because I'm currently not using it.
>> I think the current system somewhat requires for all definitions
>> 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
>> (or someone who actually uses it - someone?) can say something about
>> 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
>> abstract class
>> tgs:foo        -> function (foo) within 'tgs'
>> ...
>> I prefer ':' (colon) over '~' or '-' or other signs because I find it
>> 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
>> library "tgs" (check the reference for special behavior of colon in
>> 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
>> as for most part I hadn't any symbol name clashes yet.
>> I think for actual usage to distinct from which modul a certain
>> comes from this is highly impractical.
>> Maybe there is a much better way, like when a module is load'ed, use
>> handy names unless a symbol is already defined, then use a longer
>> symbol name instead (but all references to that symbol have to be
>> too!).
>> ---
>> About 8), my first thought would be, that one picoLisp module should
>> just as one big foo.l-file, then it could contain definitions and
>> execute code which 2) checks dependencies.
>> This would fail as soon as one likes to pack not only picoLisp code
>> 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

Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Reply via email to