[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Dave.Touretzky@A.CS.CMU.EDU
- Subject: Plummer wins
- From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
- Date: Fri, 18 Apr 1986 16:13:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 17 Apr 1986 18:51-EST from Dave.Touretzky at A.CS.CMU.EDU
Well, I haven't said anything yet because I was hoping that this
discussion would die without any help. I strongly believe that
nothing even remotely resembling bit-fields should be a part of Common
Lisp. There seem to be two general kinds of uses for this thing:
1] External interfaces in which the exact bit layout must be specified.
2] Compact representation of structures containing small integers.
The bit-field mechanism is more oriented to systems hacking, in that
it allows the exact layout of bits to be specified. This is necessary
for systems hacking but is totally unnecessary for the second class of
uses. This exact-layout provision is also the cause of portability
problems with respect to fixnum size.
It seems pretty clear that the only portable programs that could use
bit-fields would use it simply to get compact record structures. As
people have observed, nothing prevents the current defstruct from
representing fields compactly, at least in the named case.
The only other justification for putting bit-fields in Common Lisp is
that it is so obviously useful for systems hacking that we might as
well standardize it. I strongly disagree with this view. At one time
we had a mechanism similar to defstruct with bit-fields; although it
was more general than what is proposed, we found it totally inadequate
for specifying our external interfaces.
It might be worth adding a :optimize defstruct keyword which could be
used to specifiy whether the representation should be optimized for
speed or space. It might also be worth relaxing the defstruct
specification so that even typed structures could have packed fields.