sorry, I accidentally sent an incomplete message, here's the complete one
On Sat, Jan 28, 2017 at 1:51 AM, pd <eukel...@gmail.com> wrote:
> Thanks again for your explanations Alex, still some comments...
> On Fri, Jan 27, 2017 at 8:16 AM, Alexander Burger <a...@software-lab.de>
>> BTW, I thought again about the terminology of "list" versus "cons pairs"
>> 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
>> 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
> But I think it's interesting to distinguish between two different kind of
> lists, those having a NIL symbol in last cell CDR (let's say ending in NIL
> symbol) and with a non NIL in las cell CDR (those ending in a symbol not
> NIL) just because of almost every function dealing with lists assume they
> belong to NIL-ending kind.
> 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
> dealing with lists have a recursive pattern looking for an empty list
> condition to finish processing the list I think it would be interesting to
> discriminate between those two kinds of lists.
> For example, let's define f as:
> (de f (L) (print (car L)) (if (<> NIL (cdr L)) (f (cdr L))))
> then f is well defined for NIL ending lists but fails with non-NIL ending
>> > but when describing functions ' is a notation mark with a
>> > semantic, what is the semantic of dot notation mark when used in formal
>> > parameters in function description?
>> > I mean, you have these two notations for functions:
>> > - (dbs+ 'num . lst)
>> > - (delete 'any 'lst) -> lst
>> > are they applied the same? with the same kind of parameters?
>> The functions behave differently. (dbs+ 'num . lst) means that the the
>> takes an unlimited number of arguments, where only the first one is
>> while (delete 'any 'lst) takes two evaluated arguments.
> what about these two? are they equivalent?
> (f num lst) -> num
> (g num . lst) -> num
>> > evaluate to a number and rest of parameters will be bound to Z, so you
>> > this function like (dbs+ 4 a b c) , what notation will you use to
>> > you have to pass a list as parameter to a function? maybe (dbs+ 'lst)
>> ? I
>> These function definitions say nothing about the types of the arguments
>> number, list etc. This is determined by the behavior of the function's
> 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
> 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,
> so a function described as (f 'num 'num) informs that function f
> expects two parameters being numbers and since parameters are evaluated
> it's the value what is expected to be numers, so you can call f as (f 1 2)
> or (f a b) or even (f (x y z) 3) provided that values of symbols a and b
> are numbers and the result of x function call (x y z) returns a number but
> sure you cannot call f as (f (1 2)) or (f 'x 4)
> 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
> (if 'any1 any2 . prg) -> any
> Would the description below describe the same function?
> (if 'any1 any2 prg) -> any
> Even more, having into account notation used for describing functions I
> any - Anything: Any data type
> prg - Prog-Body: A list of executable expressions (run)
> so from description of function "if" which is "Conditional execution: If
> the condition any1 evaluates to non-NIL, any2 is evaluated and returned.
> Otherwise, prg is executed and the result returned." I undestand the
> "then" clause is any2 which gets evaluated when evaluated any1 is T and
> also it could be any type of value while prg is the "else" clause being
> evaluated only if evaluation of any1 returns NIL and also it is a list of
> executable expressions, from this I understand the following is a list of
> valid and invalid if function calls:
> (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)
> (if NIL (print "then") (print "else") (print "finally")) # a doubt here,
think it's invalid because two executable expressions are two lists not one
prg (one list of executable expressions)
# but maybe
valid but taking (print "else") as prg and ignoring last (print "finally")
and even when there must be a reason to allow "then clause" to be whatever
type while forcing "else clause" to be a list of executable expressions
(prg) rather than any thus avoiding the possibility to return a inmediate
number in a "the clause"
(if (really?) (print (car *Glist)) NIL) # invalid because you cannot use
a NIL value as "else" return, you need to supply a executable expressions
(if (really?) (print (car *Glist)) (NIL)) # so you must rewrite the
sentence this way, supposing (NIL) is a valid executable expression as it
would be (1 2)
# even when formally should be a
function appliance (executable expression) I think
But since I feel behaviour shoud be symmetrical for both "if-clauses" I
feel more comfortable having bothe "then-clause" and "else-clause" being
prg's in this case the descripton for the funcion should be this?
(if 'any1 prg1 . prg2) -> any
(if 'any1 prg1 prg2) -> any
>> There is no strict, static notation for the types of arguments to a
>> This is a dynamic issue.
ok but there's a convention on notation used to describe type or arguments
and return values as stated in docs
"For each function, the expected argument types and return values are
described with the following abbreviations:
The primary data types:
- num - Number
- sym - Symbol
- lst - List
Other (derived) data types
- any - Anything: Any data type
- flg - Flag: Boolean value (NIL or non-NIL)
- cnt - A count or a small number
- dat - Date: Days, starting first of March of the year 0 A.D.
- tim - Time: Seconds since midnight
- obj - Object/Class: A symbol with methods and/or classes
- var - Variable: Either a symbol or a cons pair
- exe - Executable: An executable expression (eval)
- prg - Prog-Body: A list of executable expressions (run)
- fun - Function: Either a number (code-pointer), a symbol (message) or
a list (lambda)
- msg - Message: A symbol sent to an object (to invoke a method)
- cls - Class: A symbol defined as an object's class
- typ - Type: A list of cls symbols
- pat - Pattern: A symbol whose name starts with an at-mark "@"
- pid - Process ID: A number, the ID of a Unix process
- tree - Database index tree specification
- hook - Database hook object
It's not a matter of type endorsement but a kind of type suggestion, am I
>> > could act as an operator being associative to the right, so you can
>> > ( a . b . c . d . NIL)
>> > to be equal to
>> > (a . (b . (c . (d . NIL))))
>> > and also equal to (a b c d)
>> > does it have any sense?
>> It would be possible to change the reader to accept (a . b . c . d .
>> NIL), but
>> I'm not sure at the moment. Would there be any advantage?
the only use I can think about is for parameter pattern matching or cond
function patter matching, like
(de f ( X (A . B) ) (...) ) # a function receiving two parameters, an
atom bound to X and a list which CAR is bound to A and CDR to B
(de g ( A . B . C . @ ) (...) ) # a function receiving a list whith the
first three items are bound to A, B and C and the rest of the list
(de h ( @ . Y . Z . NIL ) (...))# a function receving a list with at least
two items, binding the last two to Y and Z and all the previous items
may it be useful?