On Sat, Mar 20, 2010 at 10:56 AM, Michal Suchanek <[email protected]> wrote:
> On 20 March 2010 17:43, Aleksi Nurmi <[email protected]> wrote:
>> 2010/3/20 Jonathan S. Shapiro <[email protected]>:
>>> So what do people think? To 'a, or not to 'a, that is the question.
>>
>> The namespaces could be separated Haskell-style, where type names
>> always begin with an upper case letter, leaving names starting with a
>> lower case letter for type variables. The solution includes the
>> possibility to use lower case greek letters.
>
> This generally nice but causes problem when importing libraries
> written for other languages which might have identifiers starting with
> either uppercase and lowercase letters.
My personal bias is that I've always disliked reserved identifiers. I
acknowledge this is silly, because saying "type variables start with
single quote" is no different in principle from saying "type names
start with uppercase".
But Michal raises an important point here, which is that CLI libraries
use normal identifiers for type variables, e.g.:
A id<A>(A x) { return x; }
This works because the type variables are not inferred. If the syntax
marking id as a generic procedure were absent, as in:
A id(A x) { return x; }
it would be difficult to determine whether A was a type variable or
just an unresolved reference. The presence of the quote in:
'a id('a x) { return x; }
is what tips us off that 'a should be inferred as a missing type variable.
So the question here is what to do about CLI compatibility. In
principle, there is no problem supporting regular identifiers as type
variables as long as they are declared. The following are merely
variations on syntax:
A id<A>(A x) { return x; }
forall A def id(x:A) { return x; }
forall 'a def id(x:'a) { return x; }
but this one is not:
def id(x:'a) {return x;}
because 'a is unbound and we must infer what it means.
So we *could* adopt the following policy:
1. Type variables introduced explicitly by FORALL are not required to
begin with a quote, but
2. Identifiers with a leading quote can only be used as type variables, and
3. Only those identifiers having a leading quote will be *inferred*
as type variables.
This allows us to map CLI conventions into BitC. The other alternative
would be to rewrite:
A id<A>(A x) { return x; } => forall 'A def id(x:'A) { return x; }
that is: report the type variables in generics as if they had had the
single quote all along.
My preference, if we can do it, is to say that all type variables in
BitC have a leading quote, and we will rename type parameters on
import to BitC.
One question about C# type variables arises. Is it legal for inner
declarations to "shadow" the type parameter name, as in:
static void f<A>(A x) {
....
int A; // note this shadows the type parameter!
...
}
Another: are the variable names in a CLI generic declaration
considered part of the type, or only their positions? That is: if we
rename the type parameter variables, are we making a new type?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
