Lambda the Ultimate

inactiveTopic Selectors Make Analysis of case-lambda Too Hard
started 4/15/2003; 10:52:51 AM - last post 4/22/2003; 5:55:01 PM
Ehud Lamm - Selectors Make Analysis of case-lambda Too Hard  blueArrow
4/15/2003; 10:52:51 AM (reads: 1620, responses: 2)
Selectors Make Analysis of case-lambda Too Hard
Scheme and Functional Programming 2001. Meunier, Findler, Steckler, and Wand.

An interesting paper about set-based analysis (SBA) and the demise of MrSpidey.

The time complexity for analyizing the language with case-lambda using a selector-based framework was found to be unacceptable. A closure analysis framework is presented as an alternative.

A straigtforward macro implementation of case-lambda can be found in SRFI 16.


Posted to general by Ehud Lamm on 4/15/03; 10:53:58 AM

Ehud Lamm - Re: Selectors Make Analysis of case-lambda Too Hard  blueArrow
4/15/2003; 10:58:12 AM (reads: 585, responses: 0)
Anyone familiar with implementaions etc. that do partial evaluation of case-lambda?

Tim Sweeney - Re: Selectors Make Analysis of case-lambda Too Hard  blueArrow
4/22/2003; 5:55:01 PM (reads: 363, responses: 0)
In a type system with intersection types and contravariant subtyping of function argument types, you get case-lambda style functionality automatically. In that setting, you have results like:

add0=lambda().0 add1=lambda(x).x add2=lambda(x,y).x+y

intersection(add0,add1,add2)=a function that takes 0, 1, or 2 arguments and adds them.

However, I've found implementing intersection types and full contravariance very tricky, so this isn't an economical solution if all you want is case-lambda.