Re: The art of Unix Programming in PicoLisp

2011-09-05 Thread Henrik Sarvell
Doing it simply by ever longer function names limits you when it comes to future possible additions where instantiation and member variables make the solution more elegant. The added code complexity that holding that door open in the current code is worth it. As far as speed goes in my case the b

Re: The art of Unix Programming in PicoLisp

2011-09-05 Thread Alexander Burger
On Mon, Sep 05, 2011 at 01:54:25PM +0700, Henrik Sarvell wrote: > Doing it simply by ever longer function names limits you when it comes to > future possible additions where instantiation and member variables make the > solution more elegant. True. An additional advantage is that you can subclass

Proposal for Packages (Was: The art of Unix Programming in

2011-09-05 Thread Alexander Burger
Hi all, On Mon, Sep 05, 2011 at 08:17:04AM +0200, Alexander Burger wrote: > A call like > >(foo> '+Pckg ) > > is in no regard more encapsulating the namespace then > >(foo.Pckg ) > > but it is more tedious to write and read, takes up two cells more than > the second (4 versus 2), and e

Re: Proposal for Packages (Was: The art of Unix Programming in

2011-09-05 Thread Alexander Burger
On Mon, Sep 05, 2011 at 02:46:54PM +0200, Alexander Burger wrote: > 1. I would put these three expressions into "lib.l" > ... >(de dp "Args" > (push *Class "Args") > (let "@Msg" (car "Args") > (def "@Msg" > (curry ("@Msg") @ >(if (method '"@Msg"

Re: Proposal for Packages (Was: The art of Unix Programming in

2011-09-05 Thread Henrik Sarvell
The only objection I have against this is that it now becomes impossible to know if a certain function is global or not, and if not, to know which class it belongs, from simply looking at the invocation. I think this is a dangerous step towards too much magic that might create confusion and logica

Re: Proposal for Packages (Was: The art of Unix Programming in

2011-09-05 Thread Alexander Burger
Hi Henrik, > The only objection I have against this is that it now becomes impossible to > know if a certain function is global or not, and if not, to know which class > it belongs, from simply looking at the invocation. True. For that reason I first used a new convention using the '%' character

Re: Proposal for Packages (Was: The art of Unix Programming in

2011-09-05 Thread Alexander Burger
On Mon, Sep 05, 2011 at 05:50:07PM +0200, Alexander Burger wrote: > ... >(class +Add) > >(dp foo% (X Y) > (+ X Y) ) > >(dp bar% (X Y Z) > (+ X Y Z) ) BTW, another serious drawback with the (foo> '+Cls ) approach is that you can't easily do some things which make Lisp so p

Re: Proposal for Packages (Was: The art of Unix Programming in

2011-09-05 Thread Henrik Sarvell
The new % would solve some problems and you are right about the mapcar thing which can be annoying. However the ambiguity as to which class is controlling the behavior of func% remains but can perhaps be mitigated by yet another convention requiring you to put the context call in a special place,