English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Same label in different types, how do people solve this?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-12-18 (14:44)
From: Bruce Hoult <bruce@h...>
Subject: Re: Same label in different types, how do people solve this?
At 4:43 AM +1100 13/12/00, John Max Skaller wrote:
>Chet Murthy wrote:
>>  The issue, about practicality, isn't whether you _can_ specify the
>>  particular types and type-usages you want.  The issue is whether, if
>>  you write a phrase, and you got it wrong, you have to know all about
>>  the type system, in order to debug that phrase.
>It is a tradeoff. Full inference makes code short: lack of
>inference severely pollutes programming style (as in C++).
>In Felix, I compromised: functions must be explicitly typed
>when declared, but values don't:
>	function f(a:int): int { val b = a; return b; }
>f must be explicitly typed. The type of b is deduced.

That's how most code gets written in Dylan.  You need to declare 
argument types for methods of generic functions so that the 
polymorphic dispatch can figure out which method to call for which 
actual arguments.  Once you've done that, the compiler can often 
figure out all the types within the method by itself.

Internal functions -- anonymous arguments to things such as map(), 
and ones used for tail-recursive looping, for example -- don't tend 
to have their arguments declared.

The difference between Dylan and ML-family languages is, of course, 
that in ML if the compiler can't figure out some types it complains, 
whereas Dylan just says "oh well, it's <object>, then", and you 
silently end up with less efficient code.  A good compiler will have 
tools to tell you about this sort of thing when you want to know 
about it, and ignore it otherwise.

-- Bruce