A function with effect annotation is really a tripple, Fun(arg_type, res_type,
effect_type), so you just have to come up with a ternary syntax for it.
Of course, you would have to make sure that the separators are distinct from
other elements in the syntax used in type expressions.
Examples to consider:
int -> int [[noalloc]] // '[[' and ']]' can't occur in type expressions
{noalloc} int -> int // '{' and '}' can't occur in type expressions
(problem if you do layout rules)
int -(noalloc)-> int // '-(' and ')->' can't occur in type expressions
int -> noalloc | int // '|' can't be used
noalloc |- int -> int // '|-' can't be used
PKE.
______________________________________
From: bitc-dev-boun...@coyotos.org [bitc-dev-boun...@coyotos.org] On Behalf Of
Jonathan S. Shapiro [s...@eros-os.org]
Sent: Tuesday, August 10, 2010 4:01 PM
To: Discussions about the BitC language
Subject: [bitc-dev] FN keyword
Bah. I remembered why the darned FN keyword is in there. The full production
for function types is:
fntype: [effects] fn ( argType [, argType]* ) -> resultType
The problem is that effects are optional, so if we remove the "fn" there is an
abiguity between:
type: [effects] fn ( argType [, argType]* ) -> resultType
type: ( type )
>From a readability perspective, I don't really want to put the effect on the
>arrow itself, and we can't treat this as a type class. There are a couple of
>options here:
1. I can probably jigger the productions around to make this okay
if we have to, giving:
'a -> 'b
noalloc 'a -> 'b
2. Failing that, we can use the FN keyword only when an effect
is present on the type, giving:
'a -> 'b
noalloc fn 'a -> 'b
>From an english-language readability perspective I almost prefer "noalloc fn
>'a -> 'b", but I have no strong preference.
shap
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
