On Wed, 2006-11-15 at 19:09 -0800, Erick Tryzelaar wrote:
> We almost can do the haskell form right now, we just don't have a way of
> destructuring the curried arguments. So, I thought that this could be a
> possibly simpler form:
Yeah, I see ..
> fun eval Context -> Expr -> Context*Expr =
> | ?ctx -> (LispInt ?n) => ctx, LispInt n
Basically, this is a chained match. Given:
fun f(x:int) (y:int) : string = {
return
match x with
| 1 =>
match y with
| 1 => "1 1"
| 2 => "1 2"
endmatch
| 2 =>
match y with
| 1 => "2 1"
| 2 => "2 2"
endmatch
endmatch
;
}
you could rewrite it like:
match x,y with
| 1,1 => "1 1"
| 1,2 => "1 2"
| 2,1 => "2 1"
| 2,2 => "2 2"
but only because we can take the curry arguments x and y,
and couple them into a tuple, and this is possible because
they have names. In the Haskell style, we can indeed do this
if the argument is a tuple, but not if the arguments happen
to use curry form.
SO instead of writing
| 1,1 => "1 1"
you suggest
| 1 -> 1 => "1 1"
which can be used in the implicit match of the Haskell form:
fun f: int -> int -> string =
| 1 -> 1 => "1 1"
| 1 -> 2 => "1 2"
| 2 -> 1 => "2 1"
| 2 -> 2 => "2 2"
;
as if 'int -> int' were the argument and 1->1 matches it.
Possibly the notation should be
| 1 => 1 => "1 1"
but my brain is too low on caffeine at the moment
> Oh, and one last thing I've forgotten about. I'd still love if we could
> do this:
>
> match 5 with
> | 5 | 6 => 7
> | _ => 8
> endmatch;
Yeah, I've wanted to do that for ages. It is non-trivial
because the arguments have to be checked to be the same
name and type eg:
match .. with | X ?x | Y ?x => ..
we'd better be sure both cases define x, and the same type
of x.
At present the only way to do this is factor out the
match handler code into a subroutine, then call it.
The problem implementing this is long standing: matches
are desugared early in the game into an if/then/elif/else/endif
chain with special match checking functions, and a weirdish
way of extracting the match arguments and substituting them
into the match handler body.
The problem is that the 'if/elif' chain is just that: ordinary
goto spaghetti, no longer recognized as a match.
Really, this desugaring should be deferred, however it is done
so the front (and back) ends of the compiler only have to deal
with relatively simple functions and function calls.
hehe .. but since then, I have added GLR parsing, regular
expressions, classes and other very complicated stuff,
matches never got fixed up ... because they actually
seem to work.. :)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
