Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.misc Subject: Re: Dynamic typing (part 32_767) Message-ID: Date: 22 Apr 91 13:02:18 GMT References: <2024@optima.cs.arizona.edu> <3086@opal.cs.tu-berlin.de> Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Followup-To: comp.lang.misc Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 33 In-Reply-To: olson@juliet.ll.mit.edu's message of 18 Apr 91 07:16:07 GMT Nntp-Posting-Host: cdollin.hpl.hp.com Here's a hetrogenous list: [[ widget % LabelWidget % name % name.as_string % translations % standard_translations % install % set_actions(% action %) % borderWidth % 1 % borderColor % 'black' % background % 'gray' % ]] The %-ed items are evaluated, the others (eg "widget") are not. This list is one of the arguments to a widget instantiator. If I wrote it in a statically typed language, I expect I'd have to (a) gather each name-value pair into a twople [*1] and (b) inject each of the values into a suitable union type. If anyone's really interested, I'll explain what it means. I'm happy to admit that type errors may occur at run-time here; in fact, I'll lay odds that many of those same type errors would occur in a statically-typed language (when projecting a value back out of the presumed union type). So we need a way of handling exceptions; but we knew *that* already. It would be bootless to tell me that I ought to have an interface to the instantiator that took (say) the widget as a separate argument, the colour(s) as others, etc; one of the points about this interface is that given a widget description, it can be modified (usually by appending stuff on the end) without instantiating it, or inspected. -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."