Mathieu SUEN wrote:
> I ask those question because I am adding this to the new compiler.

And why didn't you say so before? See ESR's essay where he talks about 
"describe the goal not the steps". Your questions make a lot more sense 
when you add just that single sentence for explaining why you're looking 
at this code at all.

> So I have to follow the same structur to get the ExternalType. But it 
> seem to be not really pretty with nil value.

It is a perfectly reasonable thing to do. The compiler is querying for 
the existence of a type by that name. If there is none, the answer is 
undefined, an UndefinedObject, e.g., nil. What is not pretty about it?

> Now I am writing the grammar so is the atomicType restrict to
> 
>  bool,  void,  byte,  schar,  double,
>  float,  sbyte,  char,  ushort,  short,
>  longlong,  ulong,  ulonglong,  long
> 
> ?

Bad idea. Don't assume that this is any fixed set of atomic types. In 
fact, the code has been written the way it is (vectoring through 
ExternalType instead of hardcoding it in the parser) precisely to allow 
later extensions of external types without the compiler needing to 
recognize it. All the parser needs to recognize here is the *form* not 
the *function*.

Nicolas wrote:
>     You must understand that returning nil is a simple way to indicate a
>     failure (a kind of C-style programming).

Absolutely not. It is a query about "is there a type of that name"? 
Returning nil does not indicate failure - it indicates that no type by 
that name exist. Whether that denotes "failure" or a perfectly legal 
response is in the eye of the beholder (the sender of the message). As 
an example for this, look at the senders of #atomicTypeNamed: and notice 
how the response is used in a variety of ways none of which denotes 
"failure" in any way or shape.

Cheers,
   - Andreas