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

Re: Whither MrFlow?

Lauri Alanko wrote:
> I gathered that MrSpidey will be replaced by a "MrFlow" in v200. Could
> someone knowledgeable about these things summarize their differences? 

MrSpidey is based on Flanagan's constraints-with-selectors 
formalism.  MrFlow is based on a 0CFA closure analysis (which lambdas
flow to which call sites).  See the paper from Scheme and Functional
Programming 2001 at	


for theoretical details.

> In
> particular I'm interested in whether it will be possible to use the
> type-checker with MzScheme. I'm somewhat loath to use graphical gimmicks
> in programming. Wouldn't the new module and syntax system allow for a
> special language, modules written in which would then get their type
> assertions checked?

Possibly, but the first priority is DrScheme.

> Also, from the very little experimenting that I've done with MrSpidey, I
> get the impression that the types are inferred "top-down", so to say,
> where each function's inferred type depends on the types of the
> arguments that it is given at its call sites. Though this is
> understandable, given that the original purpose of the system is to find
> out where primitive functions need their arguments checked, I find this
> a bit confusing, being used to traditional Hindley-Milner style
> inference that finds principal types.
> For example, this checks without a glitch:
> (define (foo x) x)
> (: foo (x -> x))
> But when I add
> (define x (foo 1))
> then the type assertion no longer passes. Why? Am I completely misguided
> in trying to use type assertions like I would use type annotations in ML
> or Haskell?

You're trying to assign a polymorphic type to `foo'.  I believe you
need to add a `polymorphic' wrapper around the definition of
`foo'.  I don't have MrSpidey here to confirm the precise details.

-- Paul

| Paul Steckler                                |
| steck@ccs.neu.edu                            |
| "I'm the type-checker; I'm here to help you" |