quote form in picolisp
Hello, this message is somehow related to the one with subject "Feature
request - 'fill'"
After playing with fill and quote in picolisp I've found picolisp
implmentation of quote is a bit "strange" in terms of lisp tradition.
In lisp quote is usually a special form than returns the form passed as
parameter and accepting only and only one parameter, thus:
(quote a) -> a
(quote (quote a)) -> 'a
(quote (a b c)) -> (a b c)
(quote '(a b c)) -> '(a b c)
(quote) -> *ERROR*
(quote a b c) -> *ERROR*
where ' is an alias for quote, so (quote '(a b)) = (quote (quote (a b)))
But this is not the case in picolisp, since quote accept several arguments
it is forced to return always a list even when quoting an atom:
(quote a) -> (a)
(quote 'a) -> ('a)
(quote (a)) -> ((a))
(quote '(a)) -> ('(a))
(quote) -> NIL; which is '()
(quote a b c) -> (a b c)
(quote 7) -> (7)
I think this is incorrect because 7 is not (7), 7 is an atom and it should
still be when quoted, but picolisp turns it into a list
This also have problems, for example in most lisp you are expected to
safely do:
(setq a 4) -> 4
(quote a) -> a
(eval (quote a)) -> 4
But in picolisp you get:
(set a 4) -> 4
(quote a) -> (a)
(eval (quote a))
Segmentation fault
This is because of converting an atom into a list and then evaluating it
tries to execute a function, the internal one at address 4, and thus you
get a segmentation.
This does not happen trying to evaluate a constant number just due to
picolisp special treatment of lists of numbers to avoid quotation:
(eval (quote 7)) -> (7)
Also there's no coherence between quote form and ' read macro:
(quote 3) -> (3)
'3 -> 3
(quote a) -> (a)
'a -> a
(quote (a b)) -> ((a b))
'(a b) -> (a b)
(quote '(a b)) -> ('(a b))
''(a b) -> '(a b)
(quote (quote (a b)) -> ('((a b)))
even when in the manual it's said "... read-macro in Lisp is the single
quote character ', which expands to a call of the quote function"
it seems read macro ' behaves as expected in lisp but quote form does not.
Maybe I misunderstand the details in quote form because if you use it as
not proper list it seems to behave as it should be:
(quote . 3) -> 3
(quote . a) -> a
(quote . (a b)) -> (a b)
(quote . '(a b)) -> '(a b)
(quote . (quote . (a b)) -> '(a b)
But this is a uncommon syntax and I feel an incorrect use for most lisp out
there.
May you explain and/or discuss this ?
shouldn't be possible that ' read-macro translate transparently into quote
forms and also quote forms and ' read macro were equivalent?
why not restrict quote form to use just one argument as most lisp do?
thanks and best regards
Re: quote form in picolisp
Hi pd, > implmentation of quote is a bit "strange" in terms of lisp tradition. > ... > May you explain and/or discuss this ? It is all explained in this article from 2011: https://picolisp.com/wiki/?ArticleQuote So I consider 'quote' in PicoLisp a big improvement over other lisps ;) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: quote form in picolisp
On Wed, Dec 15, 2021 at 5:18 PM Alexander Burger wrote: > > It is all explained in this article from 2011: > >https://picolisp.com/wiki/?ArticleQuote > > So I consider 'quote' in PicoLisp a big improvement over other lisps ;) > > interesting point of view but I consider this introduces several drawbacks just to afford only one cell: - it breaks compatibility with almost all lisp out there - it makes a dotted pair or improper list into an application which is not a right application form in any lisp AFAIK, function application is always a proper list not a dotted pair In all lisp I know you cannot write (+ 1 . 2) or (quote . a) or (+ . 1), they all produces an error, the right syntax is (+ 1 . (2)) or (quote . (a)) or (+ . (1)) because function application must be a proper list not a improper list That is also the case in picolisp, where you can write (quote . a) -> a but writing (+ . 1) produces a Segmentation fault whereas writing (+ . (1)) -> 1 produces the desired result This way the syntax and behaviour in picolist is not internally coherent, every function application must be a list but for quote, which can be not a list but an improper list. examples in picolisp of this strange behaviour: ( + 1) -> 1 ; expected behaviour (+ . (1)) -> 1 ; expected behaviour (+ . 1) ; Segmentation fault (+ 1 . 2) -> 1 ; behaviour not expected, it should be 3 (following quote) or ERROR (+ 1 . (2)) -> 3 ; expected behaviour (+ 1 . (5 . 3)) -> 6 ; behaviour not expected, it should be 9 (following quote) or ERROR Last example is interesting, It seems to simply ignore last item assuming last cell cdr as nil even if it is not It seems to me that incoherence is because picolisp treats all funcional applications as every lisp but quote form which is treated in a special way: (+ . (1)) -> 1 but (quote . (1)) -> 1 (list 3 . 5) -> (3)but (quote 3 . 5) -> (3 . 5) even when(list 3 5) -> (3 5) and (quote 3 5) = (quote . (3 5)) -> (3 5) ; with an undefined symbol zz (print . 'zz) 265606 -> 265606 but (quote . 'zz) -> 'zz (print . zz) NIL-> NIL but (quote . zz) -> zz (print zz) NIL-> NIL (print zz . vv) NIL-> NIL ; again skiping last symbol I really don't know what is the number 265606 printed and returned when calling (print . 'zz) Maybe I'm misunderstanding something.
Re: quote form in picolisp
Sorry all, I regret my 'Feature Request' mail, pushing additional complexity to the language to make a few lines of code more aesthetically pleasing (to me), and awakening the trolls.
Re: quote form in picolisp
Hi pd It seems You are looking for Wikipedia/Currying . What are Your further thoughts? What do You think about Wikipedia/De_Bruijn_index ? On Thu, Dec 16, 2021, 06:27 Danilo Kordic wrote: > Trolls!? > > On Thu, Dec 16, 2021, 02:59 Erik Gustafson > wrote: > >> Sorry all, >> >> I regret my 'Feature Request' mail, pushing additional complexity >> to the language to make a few lines of code more aesthetically pleasing >> (to me), and awakening the trolls. >> >
Re: quote form in picolisp
Trolls!? On Thu, Dec 16, 2021, 02:59 Erik Gustafson wrote: > Sorry all, > > I regret my 'Feature Request' mail, pushing additional complexity > to the language to make a few lines of code more aesthetically pleasing > (to me), and awakening the trolls. >
