In article <···············@engc.bu.edu>, David Bakhash <·····@bu.edu> wrote:
> hey,
>
> if I have something like this:
>
> (defstruct person
> (age nil :type fixnum))
>
> the question is whether it's alright to initialize the `age' slot with
> `nil' instead of some bogus number. I ask because I do want the type
> spec to be useful, but I don't know, for sure, if any type of variable
> can store `nil'.
>
> in Allegro CL, I don't get errors, but maybe when it sees the `nil' as
> the default value it ignores the type spec?
just to be clear - one can use type declarations for a number of reasons:
1 as a sort of documentation to a reader of the source code of what is
expected,
2 as a debugging / programming error detection aid (with safety set high), or
3 to improve performance.
as far as performance goes, a declaration like the one you used above
tells the compiler that it can potentially represent a person object in a
particular way, i.e. such that objects are more compact and/or accessed
more efficiently.
in such cases where the compiler changes its representation in accordance
with the guidance you've given it in the form of declarations, it is an
error for the program to violate such guidance in ways such as you've
shown above.
to be more specific, the compiler could choose to represent person objects
in such a way that it is IMPOSSIBLE to store nil in the age slot, and the
code you show above could either generate a compiler error (for a smart,
friendly compiler), a runtime error (for a moderately "safe"
implementation), or just produce erroneous or unexpected results such as
nil being interpretted a number, etc. (e.g., for a highly optimizing
compiler with speed set high and safety set low).
in short, lying to the compiler can cause your programs to fail.
dave duff
····@iet.com
ps: i'm sure people will say things like "i tested it and it works in my
implementation", etc. that's not the point. many compilers ignore many
declarations. that doesn't make them "correct".