[Mono-dev] misc: C# request info

[BGB]

----- Original Message ----- 
From: "Jonathan Pryor" <jonpryor at vt.edu>
To: "BGB" <cr88192 at hotmail.com>
Cc: "Marek Safar" <marek.safar at seznam.cz>; 
<mono-devel-list at lists.ximian.com>
Sent: Wednesday, February 25, 2009 3:22 AM
Subject: Re: [Mono-dev] misc: C# request info


> On Tue, 2009-02-24 at 20:46 +1000, BGB wrote:
>> > C# has some tricky syntax too, some tokens change behaviour of 
>> > following
>> > block. Some are just tricky to parse like generics, nullables, lambdas,
>> > etc.
>> >
>> > Here is one example
>> >
>> > Foo (x <y, z> (0));
>> >
>>
>> AFAIK the above can't be a generic since a generic can't appear in this
>> context (I will assume this being an expression...).
>
> Behold the proof that it works:
>
> public static bool x<T1, T2>(int n) {return n != 0;}
>
> If you have types y and z in scope, and a method Foo(bool), then the
> call Foo(x<y,z>(0)) is in fact, valid, calling the method Foo() with the
> result of the generic method call x<y,z>(0).
>
>> (funcall Foo (< x y) (> z 0))
>>
>> unless generics can appear in a expression context, which AFAIK they 
>> can't.
>
> In fact, they can, as demonstrated above.  Don't forget about generic
> methods. :-)
>

hmm... yes...


well, this adds to the complexity a little...

now that I remember, the disambiguation rule given in this case was that the 
'>' '(' sequence was used to detect this case, otherwise it is assumed to be 
an expression.

however, this still follows under the try-and-fail approach, only that in 
this case it first has to try matching a generic, and fail if it doesn't 
meet the criteria...


actually, all of this has led to a special case:
I have a modified token function which fails to parse '>>' or '>>=', or '>=' 
as a single token, but will instead parse the '>' as a brace and leave the 
rest for later.

but, yes, generics pose a difficulty (which continues leaving me wondering 
why the C++ people originally decided on using this syntax to begin 
with...). for example, couldn't they just as easily have use '{' and '}' for 
templates and have avoided this whole mess?...

"Foo{T};" or even custom braces "Foo<{T}>", rather then create the syntactic 
mess that this notation has caused?...

but, then again, this is the C family, historically known for its adherence 
to difficult to parse syntax...
(unlike the LISP family which has very simple syntax which most people would 
not want to use, and where using tricks to extend the number of brace types 
is common-place...).


oh well, at least I have more ideas for exception handling.
I had the idea that I can actually make a generic C-based API (making the 
handling C-usable), and probably internally use a potentially optimized form 
of this interface.

tehState state; //exception handling state
state=tehBegin();
if(tehTryP(state))
{
    ...
}else if(tehCatchP(state, "Foo"))
{
    //specific exception class
}else if(tehCatchP(state, NULL))
{
    //generic unhandled exception
}else if(tehUnwindP(state))
{
    //cleanup/finally
}else
{
    //unknown state
}
//finally
tehEnd(state);

now, this is not the lowest-possible-overhead route, but it is probably not 
like large amounts of time will be going into tight-loop exception handling 
either...


still unsure how to best represent exception handling in RPNIL (my 
compiler's native IL).

I am currently thinking:
begin_try
try_p $L0 jmp_true
$Foo catch_p $L1 jmp_true
unwind_p $L2 jmp_true
$RuntimeError throw
L0: <try...> $L3 jmp
L1: <handler...> $L3 jmp
L2: <finally...> rethrow
L3: <finally...>
end_try

actually, it may seem odd, but I use a vaguely similar construction to 
represent something analogous to the phi operator (allowing multiple-path 
stack item merging). note that the stack used here is not the machine stack, 
and typically also pushes literals, registers, symbols, blocks, ... onto the 
stack as well (and likewise, code which will conditionally modify the stack 
is not allowed).

"%cond $L0 jmp_true exch L0:" is an error condition...


for the time being I will ignore generics at this level...

> - Jon
>
>
>