[Mono-dev] misc: C# request info

[BGB]

----- Original Message ----- 
From: "Marek Safar" <marek.safar at seznam.cz>
To: "BGB" <cr88192 at hotmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Tuesday, February 24, 2009 7:23 PM
Subject: Re: [Mono-dev] misc: C# request info


> Hi,
>>>> my guess is that it works like this:
>>>> the group of files is loaded;
>>>> each file is preprocessed and parsed (it is looking like C# uses a 
>>>> context-independent syntax?...);
>>>>
>>> Incorrect, C# uses context dependent keywords.
>>
>> I meant, context independent as in, the parser can parse things without 
>> knowing about previous declarations.
>> in C, it is necessary to know about declarations (typedefs, structs, ...) 
>> in order to be able to parse (otherwise... the syntax is ambiguous...).
>>
>> sadly, I am not all that familiar in detail with C#'s syntax.
>>
>> in C#, this would mean having to know about all of the classes in all of 
>> the visible namespaces before being able to parse, which would not seem 
>> to be the case.
> Correct, you don't have to know whether a token is definitely type but you 
> have to know whether it can be a type.
>

yep.


>>
>>>> all of the namespaces and declarations are "lifted out" of the parse 
>>>> trees;
>>>> each file's parse tree can then be compiled.
>>>>
>>>> from what I can tell, types are like this:
>>>> type = <qualifiers>* <type-name>
>>>>
>>>> so, I can type:
>>>> static Foo bar;
>>>>
>>>>
>>>> and the parser will know that 'Foo' is the type, even if the type for 
>>>> Foo is not visible at the time of parsing (in C, this can't be done 
>>>> since there is no clear distinction or ordering between types and 
>>>> qualifiers, and so one would not know if 'Foo' is the type, or an 
>>>> intended variable name with the type being assumed to be 'int').
>>>>
>>> No, parser does not yet know the type of 'Foo'.
>>>
>>
>> I am not certain which way you mean this.
>> 'no', as in it does not know the type, but still parses it;
>> 'no', as in it can't yet be parsed.
> C# parser does not complain because Foo can represent a type (primitive 
> type, imported, delegate, generic type, etc.)
>

yep.


>>>> unsigned int i;
>>>> int unsigned i;
>>>> int volatile i;
>>>> _Complex float f;
>>>> double _Complex g;
>>>>
>>>> unsigned i;
>>>> short int j;
>>>> int long k;
>>>> ..
>>>>
>>>> so, my guess then is that C# code is "just parsed", with no need to 
>>>> lookup, for example, is Foo a "struct or class or other typedef'ed 
>>>> type?" ...
>>>>
>>>> as far as the parser is concerned 'int' or 'byte' is syntactically not 
>>>> different from 'Foo' or 'Bar'?...
>>>>
>>> Correct.
>>>
>> so, in C we can have:
>>
>> C also has certain ugly syntactic forms which I will just assume that C# 
>> does not, such as:
>> int (*foo(int x, int y))(int z);
>>
> 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...).

(funcall Foo (< x y) (> z 0))

unless generics can appear in a expression context, which AFAIK they can't.
likewise, whether Foo is a function or type would not seem to matter that 
much either.

Foo foo = new Foo (x <y, z> (0));

would still not create a template, although Foo can be determined to be a 
type by this context...

(I could be wrong here: was a generic expected in this case?...).


actually, all of this is reminding me slightly of my past ideas related to 
making a machine-parsable subset of English grammar... (although, granted, 
my idea had assigned each word a particular part-of-speech, which would 
serve to simplify parsing somewhat).

"he came close to but did not close the door";
"do you polish the polish furnature?"
"it was left, right?"

this is ignoring the whole issue of semantic ambiguities...

"what do Engrish and the US goverment have in common?"
..
"b-rack"...


>
> Marek
>