> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 25 July 2000 09:30
> To: [EMAIL PROTECTED]
> Subject: Re: The type of zip
>
>
> Mon, 24 Jul 2000 09:04:58 +0100, Chris Angus
> <[EMAIL PROTECTED]> pisze:
>
I dont agree. To me it seems simply like a logical extension of GHC/Hugs'
Dynamic Type.
We maybe couldnt get thye kind of reflection that (say) java has but we
could get some
useful stuff.
eg. readDyn could have the signature
String -> Dynamic
we can ask the Dynamic what type it is, request a function which does a job
for that type
and invoke the function we are now back in the world of static typing.
around this area I'd be more interested in requesting values by name/type
rather than
discovering the type of an "untyped" object.
> > i.e. rather than having a read / show method for each type
> > we have a generic one which "asks" the type which type it
> > actually is or requests a constructor by name.
>
> Ugh, IMHO it's bad. Such operations should be overridable for
> particular classes. It breaks abstract types. It throws away static
> check that a type can be shown. It forces to have runtime type
> information for all objects. It requires special cases for various
> primitive types like arrays. It's not compatible with current and
> future extensions to the language (like existential and universal
> quantification).
>
> I would generally avoid reflection in a statically typed language.
>
> --
> __("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
> \__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
> ^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
> QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
>
>
