[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the forward method [dynamic vs. static typing]



On 2003-12-09T19:27:08-0800, Avi Bryant wrote:
> For example, wouldn't this mean that simply loading an implementation 
> of "not" that operated on, say, numbers, would change the semantics of 
> this program?  I'm not used to having far reaching changes come from 
> increasing the domain of a function, but maybe it's not a big deal in 
> practice.

Standard, no-frills Haskell guarantees coherence under an open-world
assumption, which means that the observable behavior of a (well-typed)
program never changes when linked with additional code.  Extensions
sometimes intentionally break this guarantee.

Cordelia V. Hall, Kevin Hammond, Simon L. Peyton Jones, and Philip
L. Wadler. 1996.  Type classes in Haskell.  ACM Transactions on
Programming Languages and Systems 18(2): 109-138.

> Anyway, this was an eye-opening example, thanks.  Is assume it's real 
> Haskell?

You're very welcome; yes!

On 2003-12-09T20:21:41-0800, Chris Page wrote:
> >I don't know of any language said to be dynamically typed that allows 
> >for dispatch based on return type; do you?
> 
> Dylan, Lisp, Smalltalk and C++. In the sense that a compiler can look 
> at the return type of a function A and use that to dispatch a 
> subsequent call to function B (when you pass the result of A to B).

That's not dispatching on the return type of a function; that's
dispatching on the type of a value returned by a function.  Dispatching
on the return type of a function does not involve calling the function.

> However, I suppose what you mean is that you want to dispatch a call to 
> A based upon the types of the arguments given to it, and the argument 
> type(s) of function B? Interesting, but is it useful? Can you provide 
> an example?

I provided one example:

On 2003-12-10T16:44:29+0530, Tom Locke wrote:
> >     getLine >>= print . (/2) . read
> >     getLine >>= print . not . read

but it gave rise to the following perception:

> Am I right in saying that the above is specific to reading from the
> outside world? DT systems don't need type annotations because they carry
> around type metadata with the data. Of course this breaks down when the
> data comes from outside.

The need to dispatch on functions' return types is not specific to
reading from the outside world.  The simplest illustration I can think
of is implicit rules in Makefiles: why write both

    .dvi.ps:

and

    	dvips $< -o $@

when you know (and Make should, too) that dvips converts dvi to ps?
That's redundancy.

The need to dispatch on return types has less to do with -when- the
dispatching is done, but the fact that the "type metadata" you refer to
includes, for functions, their return types.  I don't want to have to
call a function in order to know what kind of values it returns; I may
want to look through a ranked list of functions (as Make does) and pick
the first one with the return type I want.  (I can do that in Haskell.)

> DT systems propagate type information around at runtime, along with
> actual data, but an *expected* return type is not actual data. This is
> the essential difference between ST and DT - only ST is concerned with
> type information ahead of time.

Note that, in order to dispatch on return types, the type information
that is propagated -- whenever it is propagated -- must include return
types for functions.

> Also of note - the ST code is only more concise thanks to type
> inference, but can enough information be inferred? In some cases,
> explicit annotation will still be needed. In the above code for example,
> the function (/2) may accept a variety of numeric types: read will not
> know whether to read an integer or a double.

Ambiguity can certainly arise; Haskell's type system detects ambiguity
and disallows it.  The programmer can (then) put in more (non-redundant)
type annotations.

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
International Human Rights Day * 2003-12-10 * http://www.un.org/rights/

What if All Chemists Went on Strike? (science fiction)
http://www.iupac.org/publications/ci/2003/2506/iw3_letters.html

Attachment: signature.asc
Description: Digital signature