[net.lang.mod2] extensions, a modest question

broman%bugs@NOSC.ARPA (Vincent Broman) (03/21/86)

Twice (or more) I've bumped heads with a small shortcoming of M2 that may
eventually be best cured by a small extension of M2 syntax.

Both in writing an i/o buffering scheme and a command interpreter the problem
arose of accessing components of a big structure which needs to be viewed as
having two different types: "buft=ARRAY range1 OF WORD", say, and
"datat=ARRAY range2 OF somerecord". Unfortunately, type casts are syntactically
expressions and not "designators", and only designators may be called,
dereferenced, subscripted, or selected. So, "datat(buff)[sub].field" bums out.
The only methods I've found which don't copy the whole durned structure are:
	TYPE dataptr = POINTER TO datat; VAR datap: dataptr
1.	datap := dataptr(ADR(buff));
	use(datap^[sub].field);		(* not beautiful *)
2. deceiving the compiler with untagged variant records (which I am too
honest to do :-).

Has anyone a suggestion on how to type cast AND select components?
My preference would be to allow wild-and-wooly syntax like

ComponentValue ::=
	Factor { "." Ident | "[" ExpList "]" | "^" | ActualParameters }.
ProcedureCall ::=
	ComponentValue [ ActualParameters ].
Factor ::=
	Set | Number | etc... | ComponentValue.


vincent broman, code 632,  naval ocean systems center, san diego, ca 92152, usa
phone: +1 619 225 2365     starship: 32d 42m 22s n/ 117d 14m 13s w
arpa: broman@bugs.nosc.mil uucp: {sdcsvax,gould9,bonnie,hp-sdd}!noscvax!broman

nagler%orb@SUN.ARPA (Rob Nagler) (03/22/86)

I believe that dereferencing a type cast is a bad idea.  This is just
like case variant records, but messier.  You should only need to do
this type of stuff in a very few places and having to do something 
grungy (like untagged variant records) will flag the few places with
a blazing mark to all who read the code.  If you make it too easy to
type cast and do other illicit deeds, I think programmers will take
advantage far too often.  Here is a random example from C:

    in_lnaof(((struct sockaddr_in *)&ifinet->if_addr)->sin_addr)

Yes, this is actual code that took me about 3 minutes to find 
in the 4.2 UNIX kernel.  I happen to know where the real bad
parts are.....

Rob