[Mono-dev] misc: C# request info
cr88192 at hotmail.com
Tue Feb 24 05:46:44 EST 2009
----- 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
>>>> 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.
>>>> all of the namespaces and declarations are "lifted out" of the parse
>>>> 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.)
>>>> 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'?...
>> 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,
> 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
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?"
More information about the Mono-devel-list