> In a language like Ruby, > > pos.draw > > just doesn't care, If pos has an draw field at run-time, good enough. > Even if pos isn't a position but happens to have a draw field, just > keep on computing.
This is not quite accurate. You're conflating representation, reaction, and a smidgen of value judgment. So, for the benefit of those who did read your otherwise excellent explanation, here's a more accurate description, unfortunately using several big words (because I don't have time to write this using small ones with equal precision): Structured values mean something very different in Ruby/Python/JavaScript than they do in Java and Racket. In the latter, a structured value has a well-defined, fixed set of fields. Their names are first-order entities that can be used only in dereference positions. (That's a slight fudge when it comes to Racket, but this is a good conceptual model.) In contrast, in scripting languages structured values are simply associations from values to values. It makes no sense to say o.f and o[10] of the same o in Java, but it does in these languages. The reason is because .f is syntactic sugar for ["f"] (the quotes are literal -- they are not meta-syntax). That's the semantic representation. Separate from that is the reaction when something isn't present in the association. There is nothing preventing o.f -- which, as we've noted, is really o["f"] in these languages -- from halting with an error when "f" isn't associated with o. If Racket were to adopt an association syntax, I sure hope this is what it would do semantically. Sadly, the scripting languages prefer to continue evaluating with nonsense. And that's the value judgment. Shriram _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
