thanks for describing your views on PicoLisp!
I'd like to respond, however, to one point:
> I think the one thing which does bother me though, is the lack of a
> separate macro-expansion phase. Sure, fexpr's give you what macro's do, at
I believe this is a common misunderstanding.
While it is true that there is no macro mechanism in the "define macro"
style of CL or Scheme, there are other mechanisms of (arguably) the same
(or higher) power.
The short reason (as you probably know) is: No compilation, no macro. A
macro in Lisp, but also in low-level languages like C or assembly, is a
piece of code evaluated at compile-time, resulting in another piece of
code which is finally compiled. In a pure interpreter there is no
compile-time, and thus such a macro doesn't make sense.
> But one of the key things which make me feel comfortable in any lisp is the
> knowledge that I can effectively re-arrange the syntax of certain operation
> sequences to forms that I prefer.
However, you can do that also in PicoLisp. The above doesn't mean that
you can't programmatically manipulate your code. Basically, there are
1. Use a read macro
In a certain sense, the reader is the "compiler" of PicoLisp. Once an
expression is read, it exists as an internal s-expression pointer-
structure. If you use a read macro with '`' or '~', you can build any
code structures you like.
(de foo (A B)
You might call that a "micro"-macro ;-)
2. Use 'def' instead of 'de' for a completely evaluated definition
'(some static expression)
(some calculated expression) ) )
Quite often it is convenient to simply use 'curry' here.
You can of course also combine these methods.
> Once you get used to this feeling of *freedom*, its really hard to give it
> up. And honestly, I think this is one key lisp'ism which picolisp lacks.
I would rather say that PicoLisp has _more_ freedom than CL or Scheme.
Take first class environments as an example, which don't exist in such a
smooth way in other languages (due to their static, lexical structures
and compiler-imposed restrictions).
> Because there is no separate macro-expansion phase, any "macros" which
> involve non-trivial re-arrangement of syntax become more burdensome to do -
> because you're painfully aware that you are going to be paying the cost for
> it at runtime - every time.
Which costs do you mean? PicoLisp's fexpr mechanisms imposes no cost at
all at runtime. That is, no cost except for the normal evaluation
mechanism. It may be said that internally _all_ functions are fexprs in
> personal and idiosyncratic idioms tend to creep in (eg: the strong
> preference for building lists dynamically, and not having any
> quasiquote-like templates)
There is a similar mechanism, the function 'fill' (a function, of
course, as this is more flexible that a static language feature). 'fill'
takes a template-like pattern, and optional parameters.
> I hope this doesn't read as a criticism of any particular style (apologies,
Not at all. I'm very glad about your views.
> if thats what it seems like). Its just that, any ONE style will not fit all.
True, especially for a deliberately small language like PicoLisp you
have to restrict yourself to some minimal style set.
> Is this a change which would significantly increase complexity? Honestly, I
> don't think so. Its just re-writing code, picolisp -> picolisp (once, at
> definitiion time, instead of every time the code is invoked)
Right. This is what I tried to explain above.
It would be interesting to see in which concrete cases you'd like to do
such a code re-write. Perhaps I can then post how I would solve it.
> Picolisp does deserve more positive press for some of the really
> interesting things it *DOES* have. For that, you need more folks to use
> picolisp on real stuff. Simple examples with real code.
As usual, I would point to rosettacode.org. It shows lots of real-world
tasks and their solutions in PicoLisp (nearly 600).