ML as Scheme: Dynamic typing in a strongly-typed language
cbbr...@hex.net
> g...@cobalt.transmeta.com (Guillermo 'Bill' J. Rozas) writes:
> > > You cannot be an experienced programmer if you do trust yourself.
> >
> > You can't be any kind of programmer if you don't trust yourself.
>
> Once you reach true understanding of programming, then you begin not
> to trust yourself. Only once you internalize the strongest part of
> programming (languages) do you understand the weakest part (3am
> Mountain Dew-fuelled psychotic rushes the night before deadline).
I think we've got conflicting understandings of "trust" here.
One of the meanings might be characterized by the following quote:
"... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result is
that thieves and bums use C++ and nice people use CLOS."
-- Erik Naggum
The basic point there is that the "Lisp approach," and, more
particularly, the "Common Lisp approach," is to build mechanisms that
are somewhat "trusting" in that if you _really_ wanted to, you could
write code that looks into the private details of objects and such.
In the "more paranoid" languages, the assumption is made that you
shouldn't be _able_ to have a mechanism to penetrate into the private
parts of function libraries. That sort of assumes that the
programmers are "thieves and bums" that would brazenly use such
mechanisms For Evil Purposes.
--
(concatenate 'string "cbbrowne" "@hex.net") <http://www.ntlug.org/~cbbrowne/>
"And 1.1.81 is officially BugFree(tm), so if you receive any bug
reports on it, you know they are just evil lies." -- Linus Torvalds
Robert Monfera
> But it is *much* less work to use types than to write down runtime
> checks! (At least in modern languages). I prefer specifying properties
> in types rather than in countless runtime checks, which I may forget in
> places, implement wrongly, etc.
Does it look like a lot of work?
(defclass snake (legless-animal)
((length :initarg :length :type (real (0) *))
(poison :initarg :poison :type (member :a-joke :mostly-fatal))))
An :after method on shared-initialize can retrieve slot types (through
MOP) and check for compliance. You may additionally test relationship
between data (e.g., large snakes aren't poisonous), which you can do
with shared-initialize too. I don't know how you do that with static
type checking in ML, but the point is that type checking is only a small
part of the overall problem of validation.
Method definitions themselves serve as a (restricted) way of type
checking, for example
(reinitialize-instance 'e)
Error: No methods applicable for generic function
#<STANDARD-GENERIC-FUNCTION REINITIALIZE-INSTANCE> with args (E) of
classes (SYMBOL)
Manifest typing is also necessary when your module works with a
collection or stream of heterogenous objects.
Robert