On Thu, Dec 16, 2021 at 12:09:03PM +0100, pd wrote:
> On Thu, Dec 16, 2021 at 10:24 AM Alexander Burger <a...@software-lab.de>
> wrote:
> > First of all, forget other Lisps! I always say it is best if you start with
> > PicoLisp without knowing "Lisp".
>
> :) That's a nice advice but sadly I feel I can't do that ;-)
Yes yes ok, just for the moment ;)
> > The term "improper list" does not exist in PicoLisp. Everything is either a
> > number, a symbol or a pair.
>
> As you sure know proper or improper list always exist because is a semantic
> convention or noun, every list is a pair just only happen that when a list
> (a chained dotted pair) ends in NIL we call it proper list and when not
> ending in NIL but in any other atom, we call it improper list.
Right. I meant it does not exist in the PicoLisp terminology (docs, refs etc.).
Not relevant.
> I think I have a problem with picolisp documentation (my fault), it says "A
> dotted pair notation in the argument list like (... 'any . prg) indicates
> an unevaluated list of further arguments."
Yes
> to me this means in function application you should have a list
> of function name and arguments, like this (f) , (f 1) , (f a b c) ...
>
> being the doc of fun "(fun . args)" then:
>
> (fun ) ; args = '()
> (fun 1) ; args = '(1)
> (fun a b) ; args = '(a b)
Right, but without the quotes. For (fun a a) 'args' is a list of just two
elements (a b) and not three (quote a b).
> so a doc like "(de sym . any) -> sym" is quite different from a doc like
> "(quote . any) -> any".
The first could well be written (de . any), but then we could document all
functions as (fun . any) and it would be very boring.
(de sym . any) tells us that it expects a symbol (unevaluated), so we know we
should not call it as (de 1 ..)
But for (quote . any) it could really be anything.
> doc "(de sym . any) -> sym" means you should pass at least one argument and
> the rest if any are collected in a list, so every function call should be
There is nothing "collected". The pointer to the list is in the CDR of the call.
> the kind of:
>
> (de f ) ; any = '()
> (de f 3) ; any = '(3)
> (de f (x) (+ 2 1)) ; any = '((X) (+ 2 1))
>
> but it cannot be:
>
> (de f . 4) ; any = ??
No, it *can*. In fact, I do have this very often. For example in @lib/net.l
(de UDPMAX . 4096)
This could also be written as (setq UDPMAX 4096), but 'de' is better, because it
(1) gives a warning if 'UDPMAX' already has a different value, and (2) keeps
debug information, so that you later can say (vi 'UDPMAX).
Other examples are
@lib/form.l
(de *Go.png . "@img/go.png")
(de *No.png . "@img/no.png")
@lib/misc.l
(de *Day . (Mon Tue Wed Thu Fri Sat Sun .))
(de *Mon . (Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec .))
...
(de *DayFmt "Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday"
"Sunday")
@lib/svg.l
(de *A4-DX . 598)
(de *A4-DY . 842)
(de *A3-DX . 842)
(de *A3-DY . 1188)
@(de ULINE . 4)
(de U-OFF . 24)
(de REVERS . 7)
(de CYAN . 36)
(de RED . 31)
lib/vip.l
and probably many more.
> but it can:
>
> (def f . 4) ; makes f = 4 and so any should not be a list but atom 4,
(I think you meant 'de' instead of 'def' here) Yes, that's why the reference
says
(de sym . any) -> sym
and not (de sym . lst)
> And so what means the doc "(quote . any) -> any"? following doc convention
> any should be binded to an evaluated list of arguments, and arguments can
> be anything or nothing:
Yes, but not necessarily be a list. 'any' means "anything" ;)
> (quote) ; any = '()
> (quote 1) ; any = '(1)
> (quote a b) ; any = '(a b)
Completely OK, but also
(quote . a) # any = a
> but again what about (quote . a) ? what to bind to any? it only can be
> atom a and thus is what really happen but as said in doc, any is a list not
> an atom
No, the doc does not say it is a list. As you quoted above,
> dotted pair notation in the argument list like (... 'any . prg) indicates
> an unevaluated list of further arguments.
it talks about a 'prg', which is the abbreviation for a "prog", a *list* of
'exe's (executable expressions).
But the 'quote' refence says nothing of 'lst' or 'prg'.
> For my mind this is already so bad, but it's even worse because the
> behaviour is not predictible: (+ 1 . 2) does not return 3 but 1
As I said in my last mail, every function is free to interprete its arguments in
a way it considers suitable. For many functions this means that only pairs are
traversed (interpretation stops at an atom, which is usually but not necessarily
NIL).
> ok, you can assume you can pass arguments to functions in cdr part of cell
> and thus (quote . a) is another way to express normal lisp behaviour (quote
> a) and thus if (quote . a) is a, then you can say (quote a) is effectivey
> like (quote . (a . NIL)) and thus your are passsing a list to quote
> returning (a), but it should work also for + or print
Why waste execution time on such pathological cases? 'quote' simply does
nothing, and '+' ignores an atomic CDR.
And not only '+', but every built-in I can think of. Look at a typical case like
'list':
: (vi 'list)
# (list 'any ['any ..]) -> lst
(de _list (Exe)
(let
(X (cdr Exe)
Y (cons (eval (car X)) $Nil)
R (save Y) )
(while (pair (shift X))
(setq Y
(set 2 Y (cons (eval (car X)) $Nil)) ) )
R ) )
The point here is (while (pair (shift X)), it stops at any atom. Why bother
about NIL here? PicoLisp is pragmatical.
> I think the point is most lisp assume parameters to functions are always
> passed in CAR position of cells, which is the same of saying all functiion
> applications are proper list, while picolisp allow to pass arguments to
> functions in CDR position of cells and thus function applications are not
> proper list, but the problem is it seems this is not a general behaviour
> since some functions work with parameters in cdr position while others
> don't.
All functions in PicoLisp behave the same. They get the complete, unevaluated
stuff parsed to it: (fun . any)
What they then do with it is up to the functions. 'quote' simply does nothing:
: (vi 'quote)
# (quote . any) -> any
(de _quote (Exe)
(cdr Exe) )
while others process it in some way, like (while (pair ...)) which means that
they indeed look at it, but are just interested in its atomicity.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
