Re: quote form in picolisp

2021-12-16 Thread pd
On Thu, Dec 16, 2021 at 12:20 AM pd  wrote:

>   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.
>
> Maybe I'm misunderstanding something.
>
> indeed the example in picolisp reference for quote [Q (software-lab.de)
] seems strange to me, it
suggest you should use quote in a proper list as in all lisp:

: (quote (quote (quote a)))
-> ('('(a)))

but I think it should be written   (quote . (quote . (quote . a))) to be
compatible with quote syntax in picolisp and also with the behaviour of all
lisp I know about, in any lisp you get:

: (quote (quote (quote a)))
-> (quote (quote a))

(quote (quote a))  is equal to ''a   which is what you get in picolisp
with  (quote . (quote . (quote . a)))

Also I think you get collateral damage,  in lisp:

(eval (quote (quote (quote a  ->  (quote a)

in picolisp:

(eval (quote (quote (quote a
|? ('(a))
quote -- Protected
?

regards


Re: quote form in picolisp

2021-12-16 Thread Alexander Burger
Hi pd,

> - it breaks compatibility with almost all lisp out there
> ...
> Maybe I'm misunderstanding something.

Perhaps, though at a deeper level.

First of all, forget other Lisps! I always say it is best if you start with
PicoLisp without knowing "Lisp". Lisp dialects differ a lot, but PicoLisp starts
out from different assumptions, by targeting a pure interpreter while almost all
Lisps focus on compilation (even if they don't actually compile). Thinking this
consequently, you end up with a different language, not syntactically but
semantically.

The term "improper list" does not exist in PicoLisp. Everything is either a
number, a symbol or a pair.

As we are interpreter-only, every function is free to decide for itself how to
handle its arguments. Thus *every* built-in function is an FSUBR, always of the
form (fun . args).

If you look at the reference, you find plenty of cases like

   (de sym . any) -> sym
   (quote . any) -> any
   (if 'any1 any2 . prg) -> any
   (while 'any . prg) -> any
   (cond ('any1 . prg1) ('any2 . prg2) ..) -> any

There is no "special" form! (Or, everything is a special form)

Back to the 'quote' case:

-- Saving "only one cell" is not a minor detail. Keep in mind how often 'quote'
   is called in a typical program, and the performance of such an interpreted
   program in general is a linear function of the number of cells.

-- The syntax of 'quote' also allows for nicer source code formatting. If you
   ever look at a PicoLisp program, you find plenty of cases like

   (for X
  (quote
 ("html" . *XhtmlHtml)
 ("table" . *XhtmlTable)
 ("grid" . *XhtmlGrid)
 ("layout" . *XhtmlLayout)
 ("menu" . *XhtmlMenu)
 ("tab" . *XhtmlTab)
 ("input" . *XhtmlInput)
 ("field" . *XhtmlField)
 ("area" . *XhtmlArea)
 ("select" . *XhtmlSelect)
 ("submit" . *XhtmlSubmit) )

instead of (other Lisps!)

   (for X
  (quote
 (("html" . *XhtmlHtml)
("table" . *XhtmlTable)
("grid" . *XhtmlGrid)
("layout" . *XhtmlLayout)
("menu" . *XhtmlMenu)
("tab" . *XhtmlTab)
("input" . *XhtmlInput)
("field" . *XhtmlField)
("area" . *XhtmlArea)
("select" . *XhtmlSelect)
("submit" . *XhtmlSubmit) ) )

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: quote form in picolisp

2021-12-16 Thread pd
On Thu, Dec 16, 2021 at 6:35 AM Danilo Kordic 
wrote:

> Hi pd
>
>   It seems You are looking for Wikipedia/Currying .  What are Your further
> thoughts?
>

No I don't


>
>   What do  You think about Wikipedia/De_Bruijn_index ?
>

I think it's an interesting proposal for using with lambda calculus.

I'm not using Wikipedia at all and both questions you wrote are not related
at all with what I was talking about  (well they're related as a theorical
level since are questions related to lambda calculus, of course, but not
for the questions I'm discusing here)

 regards


Re: quote form in picolisp

2021-12-16 Thread andreas
Hi pd,

On 16.12.21 10:17, pd wrote:
> : (quote (quote (quote a)))
> -> (quote (quote a))          

In which practical use case do you ever need such an abhorrent nesting
of quotes?
If you need ''a or even a in code, then I strongly suspect your
software design is not appropriate for the specific use case.

About compatibility to lisp dialects in general - nice point.
But I'm having doubts about this being not just a superficial
theoretical whim, are there really any lisp dialects between which
general lisp knowledge is enough to be effective, without studying the
specific language? I have the impression that lisp dialects are very
diverse, while looking similar the differences are very consequential
and no useful programming can be done without studying them, maybe even
more so than the many languages which follow C syntax style.

Theory is nice, and focusing on theoretical elegance might be useful for
language research and pure math. But reality is messy, especially when
human users are involved (which is the case with most software systems).

Regards,
-- beneroth



Re: quote form in picolisp

2021-12-16 Thread pd
Thanks for your explanation, Alex

On Thu, Dec 16, 2021 at 10:24 AM Alexander Burger 
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  ;-)


> 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.
So picolisp HAS proper and improper list ;-)   in fact a circular list is a
kind of improper list and we all known picolisp has circular lists


> As we are interpreter-only, every function is free to decide for itself
> how to
> handle its arguments. Thus *every* built-in function is an FSUBR, always
> of the
> form (fun . args).
>
>
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." which is what you said in
previous paragraph and the way of constructing functions not evaluating
arguments, 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)

so a doc like "(de sym . any) -> sym" is quite different from a doc like
"(quote . any) -> any".

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
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 = ??

but it can:

(def f . 4)   ; makes f = 4   and so any should not be a list but atom 4,
contrary to doc definition "A dotted pair like (... 'any . prg) indicates
an unevaluated list of further arguments."

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:

(quote)   ; any = '()
(quote 1); any = '(1)
(quote a b) ; any = '(a b)

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

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

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

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.

Maybe I'm misunderstanding details and after all picolisp is breaking
traditions as stated in documentation, but this behaviour blows my square
mind ;-)

Anyway I think it worths to think about all this to further understand
picolisp internals  and picolisp way of lisp ;-)

best regards


Re: quote form in picolisp

2021-12-16 Thread pd
On Thu, Dec 16, 2021 at 11:51 AM  wrote:

>
> In which practical use case do you ever need such an abhorrent nesting of
> quotes?
>
it's not a question of practical use but compatibility and tradition, also
a question of semantics


> But I'm having doubts about this being not just a superficial theoretical
> whim, are there really any lisp dialects between which general lisp
> knowledge is enough to be effective, without studying the specific
> language? I have the impression that lisp dialects are very diverse, while
> looking similar the differences are very consequential and no useful
> programming can be done without studying them, maybe even more so than the
> many languages which follow C syntax style.
>
you're right, every language contains itself a "deviation" of its own
family and at the end you must learn special features of a concrete
dialect, so there's no common knowledge you can learn applicable to all
language dialects. But there's stablished traditions and there're formal
theory you should comply with.   I think quote behaviour is one of them and
also list application.

regards


Re: quote form in picolisp

2021-12-16 Thread Andras Pahi
Hi,

McCarthy’s "A micro-manual for Lisp" in 1978 lists 10 rules as the core of LISP.
The first rule states the behavior of QUOTE. If you select a different set of 
rules,
you get a different LISP.

In picoLisp QUOTE is defined differently.

Regards,
Andras Pahi


> On 2021. Dec 16., at 12:17, pd  wrote:
> But there's stablished traditions and there're formal theory you should 
> comply with.   I think quote behaviour is one of them and also list 
> application.  


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: quote form in picolisp

2021-12-16 Thread Alexander Burger
On Thu, Dec 16, 2021 at 12:09:03PM +0100, pd wrote:
> On Thu, Dec 16, 2021 at 10:24 AM Alexander Burger 
> 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 a

Re: quote form in picolisp

2021-12-16 Thread Alexander Burger
On Thu, Dec 16, 2021 at 03:37:50PM +0100, Alexander Burger wrote:
> 'quote' simply does nothing, and '+' ignores an atomic CDR.
> 
> And not only '+', but every built-in I can think of.

To be more clear: I'm talking of *evaluated* arguments. That is, I don't know
any function of the form (fun . 'any) or (fun . 'atom).

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: quote form in picolisp

2021-12-16 Thread Alexander Burger
Hi all,

this whole discussion got ridiculously complicated.

But in fact it is so simple!

A function call in PicoLisp is *always* just a single cell:

  +-+--+
  | Fun | Args |
  +-+--+

Both Fun and Args can be anything (number, symbol or pair).

If Fun is a number, the expression auto-quotes. Otherwise, while it is a symbol,
its value is taken. So we end up either with a number (code pointer) or a list
(EXPR, FEXPR, or a mixture of both). This is called with Args.

Fun is free to do with Args what it wants.

Who cares about proper or improper lists? Total freedom and power! :)

'quote' is the mother of all functions. It does nothing, and just returns Args.
No need for "special forms"!

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: quote form in picolisp

2021-12-16 Thread rick
Look for the book to come out soon: “Zen and the Art of Programming Language 
Development” :)

On Thu, 16 Dec 2021 15:48 -05:00, Alexander Burger wrote:
> Hi all,
>
> this whole discussion got ridiculously complicated.
>
> But in fact it is so simple!
>
> A function call in PicoLisp is *always* just a single cell:
>
>   +-+--+
>   | Fun | Args |
>   +-+--+
>
> Both Fun and Args can be anything (number, symbol or pair).
>
> If Fun is a number, the expression auto-quotes. Otherwise, while it is a 
> symbol,
> its value is taken. So we end up either with a number (code pointer) or a list
> (EXPR, FEXPR, or a mixture of both). This is called with Args.
>
> Fun is free to do with Args what it wants.
>
> Who cares about proper or improper lists? Total freedom and power! :)
>
> 'quote' is the mother of all functions. It does nothing, and just returns 
> Args.
> No need for "special forms"!
>
> ☺/ A!ex
>
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: quote form in picolisp

2021-12-16 Thread Tomas Hlavaty
On Thu 16 Dec 2021 at 21:48, Alexander Burger  wrote:
> 'quote' is the mother of all functions. It does nothing, and just returns 
> Args.
> No need for "special forms"!

Because there is no concept of compiler.
Compilation in picolisp is done ahead of time manually in another
language.

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe