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

*To*: "address@hidden" <address@hidden>*Subject*: Re: Typing and semantics [dynamic vs. static typing]*From*: John Clements <address@hidden>*Date*: Wed, 17 Dec 2003 15:32:19 -0500*Cc*: "address@hidden" <address@hidden>*In-reply-to*: <01C3C4A7.481B5840.kmillikin@atcorp.com>*References*: <01C3C4A7.481B5840.kmillikin@atcorp.com>*Sender*: address@hidden

On Dec 17, 2003, at 3:08 PM, Kevin S. Millikin wrote: > On Wednesday, December 17, 2003 12:51 PM, John Clements > [SMTP:clements@brinckerhoff.org] wrote: >> >> Cribbing again from my response to Ken, I think the core of the > debate >> has to do with typeclasses as a program abstraction mechanism that is >> inherently non-local. > > Invoking a first class function is "inherently non-local". Let me advance/retreat (depending on your point of view) to what I believe is a restatement of my prior claim. Informally: Let's say I'm trying to reason about a piece of code. Let's say that code is if (f(x)) then g() else h(); Let's further assume that I know what the value of x is, and what the values of f and g are. The hope is that I can then know what the language will evaluate f(x) to, and therefore figure out whether g or h will be called. I think everyone agrees that we want this. The question, then is what it means to "know the value" of f and g. In Scheme, ML, Java, & most other languages you can think of, you can easily identify the parts of the program that are part of the value of f and g. In particular, only parts of the program that have been evaluated will affect the values of f and g.[*] In Haskell, as I understand it, there are a certain number of cases in which these parts of the program will _not_ be sufficient to determine what's going to happen next. In particular, I have to examine the type proof of the program--the whole program--to see how things were resolved in order to figure out what's going to happen next. Put more concisely, you can't write down an operational semantics that doesn't involve computing the result of the type proof. john [*] plus some static set of type declarations.

**Follow-Ups**:**Re: Typing and semantics [dynamic vs. static typing]***From:*Ken Shan <ken@digitas.harvard.edu>

**References**:**RE: Typing and semantics [dynamic vs. static typing]***From:*"Kevin S. Millikin" <kmillikin@atcorp.com>

- Prev by Date:
**RE: More on dispatching by function return type** - Next by Date:
**Re: More on dispatching by function return type** - Previous by thread:
**RE: Typing and semantics [dynamic vs. static typing]** - Next by thread:
**Re: Typing and semantics [dynamic vs. static typing]** - Index(es):