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 logical bugs.
Instead of using the class functionality in a basically static way like I
often do it would then maybe be better to simply impose a new convention
which could read something like this:
"If you find yourself doing something in a way that would constitute a class
with only static methods and no member variables in another language then
you should dispense with the class and instead do (de classname.funcname ())
instead of public methods and (de "funcname" ()) instead of private
The above then forces the programmer to think and plan before coding, as
opposed to what I'm doing now when I simply go for classes because it gives
me a maximum of future options at the expense of overly verbose syntax and
code that executes slower.
To sum it up: making use of the fact that PicoLisp is perhaps the most
forgiving language when it comes to what characters are allowed in function
names should be exploited further instead of creating new constructs that
add complexity to the language.
We already have conventions where we use ?, " and > in names, we can have
On Mon, Sep 5, 2011 at 7:46 PM, Alexander Burger <a...@software-lab.de>wrote:
> Hi all,
> On Mon, Sep 05, 2011 at 08:17:04AM +0200, Alexander Burger wrote:
> > A call like
> > (foo> '+Pckg <arg>)
> > is in no regard more encapsulating the namespace then
> > (foo.Pckg <arg>)
> > but it is more tedious to write and read, takes up two cells more than
> > the second (4 versus 2), and eats up performance at each call for the
> > method lookup.
> If people like to stick with this way of building packages from classes,
> how about the following proposal?
> It still has the same performance handicap as the straight-forward usage
> of classes and methods, but it provides for some syntactic sugar, and
> does not impose the cell space penalty.
> I would call it "Dynamic Packages", because it does a dynamic runtime
> lookup, like in Henrik's style, but with a less noisy syntax.
> 1. I would put these three expressions into "lib.l"
> # Dynamic packages
> (off "Context")
> (de context Lst
> (setq "Context" Lst) )
> (de dp "Args"
> (push *Class "Args")
> (let "@Msg" (car "Args")
> (def "@Msg"
> (curry ("@Msg") @
> (if (method '"@Msg" '"Context")
> (pass @)
> (quit "Not in context" '"@Msg") ) ) ) ) )
> 2. Then we can define "packages", e.g. '+Add' and '+Mul'. Note that such
> packages are still just normal classes, allowing class variables,
> subclasses, inheritance etc. The difference is only that methods are
> not defined with 'dm' (define method) but with 'dp' (define package
> (class +Add)
> (dp foo (X Y)
> (+ X Y) )
> (dp bar (X Y Z)
> (+ X Y Z) )
> (class +Mul)
> (dp foo (X Y)
> (* X Y) )
> (dp bar (X Y Z)
> (* X Y Z) )
> 3. Later, package search order can be specified with 'context'.
> 'context' takes any number of classes, to be searched sequentially
> from left to right:
> (context +Add +Mul)
> (println (foo 3 4) (bar 2 3 4)) # Prints 7 9
> (context +Mul +Add)
> (println (foo 3 4) (bar 2 3 4)) # Prints 12 24
> One disadvantage of this mechanism (in addition to the runtime overhead)
> is that functions defined with 'dp' can only be EXPRs (i.e. evaluating
> all arguments).
> Any opinions?
> - Alex
> UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe