On Sat, Jan 28, 2017 at 02:35:09AM +0100, pd wrote:
> sorry, I accidentally sent an incomplete message, here's the complete one
> ...
> >>
> >> BTW, I thought again about the terminology of "list" versus "cons pairs"
> >> and
> >> plain "cells". "list" is a rather unprecise term, I feel it is not
> >> limited to "a
> >> chain of cells with NIL at the end". I use "list" for any sequence of
> >> cells (as
> >> opposed to other structures like "tree", "graph" or "set"). These include
> >> also
> >> e.g. "circular lists" like (1 2 3 .), which have no NIL at the end (in
> >> fact, no
> >> end at all).
> >>
> > Ok, so from this point of view every cons pair is a list even those with a
> > dotted pair in the tail
No, definitely not. I would not call (3 . 4) a list. Still, as I said, "list" is
a rather unprecise term. Some people use the term "proper list" for a
NIL-terminated list.
> > I mean, with a NIL ending list you have an empty list condition (NIL) but
> > how do you know a non-NIL ending list is empty? and since most functions
No. Only the atom 'NIL' is the empty list.
> > condition to finish processing the list I think it would be interesting to
> > discriminate between those two kinds of lists.
I think it does not matter. At least it is not very important. Every function in
Lisp is free to treat its arguments as it likes.
The PicoLisp interpreter doesn't care very much. Most list-processing functions
do not check for NIL at the end, but whether the item is atomic or not
In C:
while (isCell(cdr(x = cdr(x))))
In Asm:
ld X (X CDR) # Args
atom (X CDR) # more than one left?
while z # Yes
> > what about these two? are they equivalent?
> >
> > (f num lst) -> num
> > (g num . lst) -> num
No. 'f' takes two argument (supposed to evaluate to a number and a list), while
'g' takes an unlimited number of arguments (the first supposed to be a number
after evaluation, the rest unspecified).
> > of course it's the function body which determines the "type" of
> > parameters, if the body applies a parameter to a function expecting a
> > number, that parameter's type must be a number and not a symbol or list or
> > the function call in the body will fail, but you use a notation for
Right.
> > describing functions just to help users know what kind of parameter you
> > must provide, that's the reason to use that list of meaningful words, type
> > is not enforced (not possible) but suggested to user using the function,
> > right?
Exactly.
> > From this point of view my question is about the difference of using or
> > not using dot when describing a function, for example, take the if
> > description:
> >
> > (if 'any1 any2 . prg) -> any
> >
> > Would the description below describe the same function?
> >
> > (if 'any1 any2 prg) -> any
A typical call of 'if' could be
(if (testSomething) (doSomething1) (doSomething2) (doSomething3))
where
any1 is the result of evaluating (testSomething)
any2 is (doSomething1)
prg is ((doSomething2) (doSomething3))
Perhaps it helps understanding if we remember that
(if (testSomething) (doSomething1) (doSomething2) (doSomething3))
is the same as
(if (testSomething) (doSomething1) . ((doSomething2) (doSomething3)))
If 'if' were specified as in the second case (if 'any1 any2 prg), then we would
need to call it as
(if (testSomething) (doSomething1) ((doSomething2) (doSomething3)))
to match the spec (if 'any1 any2 prg) and get the same bindings.
> > (if T 3 (print "no")) # valid
> > (if (< 2 2) 'x (print "yeah")) # valid
> > (if T 3 4) # invalid
> > because 4 is a number not a prg (a list)
Yes, but the prg is (4), not 4.
> > (if NIL (print "then") (print "else") (print "finally")) # a doubt here,
> >
> # I
> think it's invalid because two executable expressions are two lists not one
> prg (one list of executable expressions)
No, it is perfectly valid.
(print "then") is the "then" part, an 'exe'
((print "else") (print "finally")) is the "else" part, a 'prg'
> (if (really?) (print (car *Glist)) NIL) # invalid because you cannot use
> a NIL value as "else" return, you need to supply a executable expressions
No, perfectly valid. The 'prg' is (NIL).
Remember how a 'prg' is executed: Each expressions is evaluated, one after the
other, and the result of the last one is the result of the whole 'prg'. The last
expression evaluated here is NIL, so the result is NIL.
> (if (really?) (print (car *Glist)) (NIL)) # so you must rewrite the
This would crash, as the 'prg' is ((NIL)), thus the last expression is (NIL),
and NIL is not a function.
> The primary data types:
>
> - num - Number
> - sym - Symbol
> - lst - List
> ...
> - any - Anything: Any data type
> It's not a matter of type endorsement but a kind of type suggestion, am I
> right?
Yes
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
