Paul_Abrahams%Wayne-MTS@UM.CC.UMICH.EDU (11/18/90)
Thanks to all for your replies to my query on this subject. Re Ralph's comment: yes, I was being sloppy in saying that the type of a variable can change. Viewing variables as untyped containers of arbitrary values is both cleaner and and the correct depiction of reality. Yes, you can use Icon's flexible typing structure to construct heterogeneous lists. But what isn't clear to me is what such lists are good for, particu- larly when they contain values of truly arbitrary types rather than of related types. In SPLASH I have a `box' type that can designate variables of any type. That provides an escape from strong typing---the second approach that Dave Gudeman suggested. I'm still wrestling with the semantics of boxes, though. What prompted my query was wondering what operations you might want on a box in addition to the image operation (in the sense of the Icon `image' procedure). In particular, the image operation would suffice for the trapping that Gregg gave as an example. You might think that an obvious operation on boxes would be to get a string giving the type of the box. But that turns out to be remarkably difficult in the presence of recursive types. That problem doesn't come up in Icon because Icon doesn't have recursive types---with dynamic typing, you don't need them. To clarify: in Pascalish languages you can have something like: type t is record v: integer; link: ref t end How then would you display the definition of t in a form that id independent of the name you give the type? In Icon the type would simply be `t' (which actually isn't very revealing if you don't have the definition of `t' handy). By the way, Modula-3 has a `refany' type which provides an escape from strong typing in that language. But you can only dereference a `refany' value using a `typecase' construction, which forces you to enumerate all the possibilities. That's less general than being able to apply `image' without knowing the type. Paul abrahams%wayne-mts@um.cc.umich.edu
nowlin@iwtqg.att.com (11/18/90)
> ... > How then would you display the definition of t in a form that is > independent of the name you give the type? In Icon the type would > simply be `t' (which actually isn't very revealing if you don't have > the definition of `t' handy). > ... > > Paul In fact, type 't' from Icon isn't that bad for some applications. You can get the fact that type 't' is a record by looking at the image() and then you can just treat values of 't' like lists and generate the members or directly subscript them. I don't know how you'd find the specific member names but you can get at the member values and that's more important in most cases. Jerry Nowlin (iwtqg!nowlin)