pascal bourguignon

Nathan Baum <nathan_baum@btinternet.com> writes:


Yes, right. I wasn't awake. Sorry.


The point is that lisp is a dynamic language.
It would be silly to signal an error when you enter:

(defun bad () (node-label 12))

because you might enter:

(defgeneric node-label (object)
(:method ((self cons)) (first self))
(:method ((self t)) self))

just after, and then:

(bad)

would be perfectly good.

If you want Haskell, how would a language diametrically opposed help?


(Well, I understand that a Haskell with sexp syntax could be
useful. At least, more readable than normal Haskell syntax... But
sexpifying a programming language doesn't make it lisp.)


--
__Pascal Bourguignon__ http://www.informatimago.com/

"You cannot really appreciate Dilbert unless you read it in the
original Klingon"

nathan baum

Ah, but this depends upon *when* you signal the error. It would indeed be
silly for 'the compiler' to signal an error at 'compile time'. (Unless
NODE-LABEL was inline, or there was some non-standard declaration in force
which meant that NODE-LABEL would never be redefined.)

On the other hand, to be able to type (typecheck 'bad) at the REPL and get
messages about type conflicts *as they are at that time* would (IMO) be
useful. SBCL does as much whenever you define a function,

...
; caught WARNING:
; Asserted type LIST conflicts with derived type
; (VALUES (INTEGER 12 12) &OPTIONAL).
...

which seems to be a net win.

It's my experience that static type checking is a powerful, albiet not
universal, tool for detecting certain classes of error in a program.

You correctly identify that following common-sense coding standards like
using abstract data types can make it easier to remember what types go
where -- I imagine it's easier to remember that (NODE-LABEL node) is
(should be) a SYMBOL than (CAR node). I have no argument with that.

One can (and IMO should) also use unit tests to detect errors, including
type errors.

But one should not, I think, dismiss static type checking simply because
there are other alternatives available. I like to follow the engineering
practice of having "multiple independent failsafes".

Although static type checking can't detect all errors, it can detect some.
And although all the errors it can detect are avoidable by following
coding standards and detectable by running unit tests, that's no guarantee
that they actually will be avoided or detected by standards or tests.

At the same time, adding type inference to a language doesn't make it
*not* Lisp (as SBCL proves).

Additionally, I've never advocated changes to 'the language'. The basic
point of my post was that (1) type inference and static type checking can
be a win and (2) in Lisp they can implemented as a library.

aaron sokoloski

I think that Qi may be what you're looking for: http://www.lambdassociates.org/aboutqi.htm


"A language implemented in Common Lisp that generates efficient type
secure Lisp programs which you can run on any machine."

--Aaron

joe marshall

Just to clarify. A Common Lisp implementation is not required to
produce an error here.

A type declaration in Common Lisp is a promise from you to the compiler
that your program will always use the declared type. The compiler is
allowed to trust you competely on this point and could produce code
that has undefined consequences if you happen to be incorrect about the
declaration or lie to the compiler. For instance,

(defun f (x)
(declare (integer x))
(+ 1 x))

(f 3.0)
--- whirring noise --- reboot --- BIOS ERROR: UNFORMATED MEDIUM ----

The CHECK-TYPE macro causes an explicit type-check to be performed and
it is what you should use if you are interested in having the system
raise an error.

(defun f (x)
(check-type x integer)
(+ x 1)) (f 3.0)
---> Enters error handler.

pascal bourguignon

Nathan Baum <nathan_baum@btinternet.com> writes:


* (defun typecheck (fun) (funcall fun))

TYPECHECK
* (defun bad () (node-label 12))

BAD
* (typecheck 'bad)

debugger invoked on a TYPE-ERROR: The value 12 is not of type LIST.

;-)


This is a subject over discussed from dynamically typed languages news
groups to statically typed language news groups. There's no interest in it.

If you want static typing, use Haskell. If you want dynamic typing,
use Lisp.

You can (try to) develop tools to automatically prove any program
property you want, and I don't say I wouldn't use them with lisp if
they were available, but they're not needed.

IMO, for the kind of software I write (and what 99% of the programmers
write I'd say), static typing impacts less than 1% of the success of
the project.

--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.

kaz kylheku

Now if only we didn't /have/ a standard, that problem would nicely go
away.

jeffery zhang

On 2006-08-07 11:48:34 -0500, "Aaron Sokoloski" <asokoloski@gmail.com> said:


Thanks so much for this link. Qi looks like the perfect combo of Lisp
and ML. I miss pattern matching style function definitions. I should
study macros more to rework the syntax. Turing equivalent type
language, now that's simultaneously scary and interesting. I just hope
they have a debugger for the type system.

aaron sokoloski

Glad it's what you're looking for. I haven't looked into Qi too deeply
myself, but it did seem like there's plenty of documentation available.
"Scary and interesting" is a pretty apt description, especially when
the author gives an example of creating a type such as "prime integer"!