[bitc-dev] FN keyword

[Pal Engstad]

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-bounces at coyotos.org [bitc-dev-bounces at coyotos.org] On Behalf Of Jonathan S. Shapiro [shap at 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