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" [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)
>

Reply via email to