Re: Lisp dinamism vs ML safety

"Javier" <javuchi@xxxxxxxxx> writes:

Thomas A. Russ ha escrito:

In respect to word size, you are right, dynamic ilanguagges allows you
to write less and more standard code. But the cost of this is that the
rest of the system may be unsafe if you don't declare things.

Well, safety is always relative. Just because there is compile-time
type safety doesn't help you when there is interactive input. Nor does
it protect you against algorithmic bugs, divide by zero (unless you make
rather heroic assumptions about the cleverness of the type system and
what it can figure out.)

I'll put here an example:

(defun sum-list (lst)
(cond
((null lst) nil)
(t (+ (car lst) (sum-list (cdr lst))))))


Imagine that the compiler spots this and you rush to fix it
as the telephone rings.

(defun sum-list (list)
(cond
((null list) 1)
(t (+ (car list)(sum-list (cdr list))))))

After the phone call you compile it; since it passes the
static type checks you press on to the next piece of code.
Have you won or lost? Why?

I've been working on some code so that I can do

CL-USER> (defun sum-list (lst)
(declare (test (((5 7)) 12)))
(cond
((null lst) nil)
(t (+ (car lst) (sum-list (cdr lst))))))

arglist = ((5 7)), required result = 12, actual result NIL.
((NESTUIT::UNEXPECTED-SIGNAL #<SIMPLE-TYPE-ERROR {481F15ED}>))
0.00% passed.
SUM-LIST

CL-USER> (defun sum-list (lst)
(declare (test (((5 7)) 12)))
(cond
((null lst) 1)
(t (+ (car lst) (sum-list (cdr lst))))))

arglist = ((5 7)), required result = 12, actual result 13.
((NESTUIT::WRONG-ANSWER :EXPECTED 12 :RECEIVED 13))
0.00% passed.
SUM-LIST

CL-USER> (defun sum-list (lst)
(declare (test (((5 7)) 12)))
(cond
((null lst) 0)
(t (+ (car lst) (sum-list (cdr lst))))))

arglist = ((5 7)), required result = 12, actual result 12.
All passed.
SUM-LIST

It shadows defun, uses the declaration declaration to tell
CL about TEST, and uses eval-when to get the declared tests
run a compile time.

The code is online at

http://www.cawtech.demon.co.uk/nestuit/current.lisp

so that you can see that I really have conforming code that
does this, but I've been tinkering and it is in a mess with
bits broken, and I've got three bits of documentation, all
obselete, all disagreeing.

If I press on with this, will I really use it, will I find
it worthwhile?

I don't think it is possible to think clearly about this
issue if you use the word "correct" for code that passes the
static type checks. I propose "typeck" as a neologism for
code that passes the static type checks. You need a
vocabularly that permits you to say that

(defun sum-list (list)
(cond
((null list) 1)
(t (+ (car list)(sum-list (cdr list))))))

is typeck but incorrect.

If you are stuck with a terminology that forces you to say
that it is correct but incorrect, you will just get in a
muddle.

Alan Crowe
Edinburgh
Scotland
.

Relevant Pages

  • Re: and/or functions revisited
    ... (cond ((null? ... ((not (car lst)) ...
    (comp.lang.scheme)
  • Re: How to think?
    ... element of lst fails to satisfy pred, ... Can you give me some guidance how to think when solving this problem ... (cond ((null? ... Maybe I could use similar pattern for "traversing a list" kind of ...
    (comp.lang.scheme)
  • Re: Lisp dinamism vs ML safety
    ... (defun sum-list (lst) ... => Error Argument Y is not a NUMBER: NIL ... compile properly, or does it give an error as well: ... (cond ((null lst) ...
    (comp.lang.lisp)
  • Re: References and interesting declarations
    ... > something of a really complicated declaration (in this case, ... It always passes a pointer to the first element. ... void func(Pointlst) ... subscripts on a pointer just like you can use them on an array. ...
    (comp.lang.cpp)