"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message
news:mailman.742.1327344456.16222.digitalmar...@puremagic.com...
> On Monday, January 23, 2012 10:08:50 Walter Bright wrote:
>> On 1/23/2012 5:08 AM, Iain Buclaw wrote:
>> > Walter, what are your views on emitting the names of aliased types to
>> > debug?
>>
>> I don't really have an opinion on it, except that generally when I'm
>> debugging I'm interested in what a type really is, not the layer over it.
That's a pain in the ass for library users. For example, Goldie uses a lot
of type sugar so that a nonteminal generated from the rule:
<Foo> ::= <Bar> ';'
Is usually referred to as type:
A: Token_myLang!("<Foo>", "<Bar>", ";")
Instead of:
B: Token_myLang!(
"<Foo>",
Token_myLang!(SymbolType.NonTerminal, "<Bar>"),
Token_myLang!(SymbolType.Terminal, ";") )
or:
C: _Token_myLang!("<Foo>", 47); // Rule ID#
The "B" is a rarely-needed unsugared version (which is guaranteed to be
unambiguous with other symbols in th grammar). And "C" (or something similar
to it) is the true underlying type that's intended purely as an
implementation detail - *NOT* for user consumption.
The policy of showing types de-aliased breaks proper encapsulation and just
detroys all of the above whenever there's a type error (which is the whole
point of having those types in the first place).
>
> I usually want the aliased type.
Same here. I usually find it far more relevent to the code the compiler's
referring too.
The current way is like having error messages show mangled names or talking
in terms of the generated assembly instructions: It totally breaks out of
the proper context and level-of-abstraction.
> I can look up what the alias is, but I can't
> know that something is using an alias if the alias is gone.
>
I hadn't thought of that, that's a good point, too.
