Re: modules?
As far as avoiding getBob clashes PL already has class and namespace functionality. On Tue, Feb 10, 2015 at 2:23 AM, Lawrence Bottorff 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, 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 wa
Re: modules?
Afaik, that should work :-) I thought about a loader doing this, but I didn't think about mixing it with the present namespace system. Great ideas Jakob! - Original Message - From: Jakob Eriksson [mailto:ja...@aurorasystems.eu] To: picolisp@software-lab.de Sent: Tue, 10 Feb 2015 10:11:17 +0100 Subject: 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 LawrenceNice 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, etal) there is (behind the scenes, i.e., preprocessor) name mangling. There'salso tagging s tuff with a huge hash generated numbers I say all thisbecause I'm hearing the need for uniqueness and anti-name-clash -- acrossfiles and systems. Is that a correct assumption here? So when you call"your" getBob function, some other code you're involved with doesn't thinkthat its (totally by chance also named) getBob function is meant. Am I onthe right track?LBOn 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 mod ules: 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
Re: modules?
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, 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, j
Re: modules?
Hi LawrenceNice 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, etal) there is (behind the scenes, i.e., preprocessor) name mangling. There'salso tagging stuff with a huge hash generated numbers I say all thisbecause I'm hearing the need for uniqueness and anti-name-clash -- acrossfiles and systems. Is that a correct assumption here? So when you call"your" getBob function, some other code you're involved with doesn't thinkthat its (totally by chance also named) getBob function is meant. Am I onthe right track?LBOn 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
Re: modules?
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, 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
Re: modules?
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 environment5) name clashing, especially of picoLisp code/symbols/function names/class names/etcetera6) 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 modules10) 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.lWhen 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 smal
Re: modules?
Could we cook up a convention? On February 9, 2015 6:12:17 PM CET, Henrik Sarvell wrote: >Hi Lawrence, if you're talking about something like Ruby's gems, then >no. > >On Mon, Feb 9, 2015 at 5:45 PM, Lawrence Bottorff >wrote: > >> I'm wondering what you offer in lieu of modules (as with, say, >Python). Is >> there a "black box" way to "package up" code in picoLisp that has >> module-like serviceability? >> >> LB >> -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
Re: modules?
Hi Lawrence, if you're talking about something like Ruby's gems, then no. On Mon, Feb 9, 2015 at 5:45 PM, Lawrence Bottorff wrote: > I'm wondering what you offer in lieu of modules (as with, say, Python). Is > there a "black box" way to "package up" code in picoLisp that has > module-like serviceability? > > LB >
Re: modules?
Hi Lawrence, > I'm wondering what you offer in lieu of modules (as with, say, Python). Is > there a "black box" way to "package up" code in picoLisp that has > module-like serviceability? I would say no, though I don't know the modules of Python. Similar to C, a source file has certain encapsulating properties (static scope in C versus transient symbol scope in PicoLisp). On the level of internal symbols, can use namespaces (via the function 'symbols', and its buddies 'local' and 'import') for encapsulation. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
modules?
I'm wondering what you offer in lieu of modules (as with, say, Python). Is there a "black box" way to "package up" code in picoLisp that has module-like serviceability? LB
