Mangling writeup

[Jim Dehnert]

This discussion (mangling) is probably of interest to the whole group now...

> Date: Mon, 13 Mar 2000 22:30:33 -0800
> From: Daveed Vandevoorde <daveed at edg.com>
> 
> Jim Dehnert wrote:
> > 
> > If you take a look at the ABI layout document, I've heavily reworked the
> > mangling writeup.  It incorporates a couple of choices we made last week
> > for the loose ends list, but primarily it converts the presentation to a
> > more consistent (I hope) BNF grammar for the mangling.  I think it
> > provides a clearer picture of just where various components occur, but
> > I'd appreciate it if you would take a careful look at it before I point
> > out its presence to the whole group tomorrow, for omissions, errors,
> > misunderstandings, etc.
>
> I'd rather not use "Sn" for the sentry because S<letter> was meant to be
> reserved for the abbreviation catalog.  How about GV (guard variable)
> instead?

Sounds good.

> Also, it occurs to me that return-types cannot be omitted from non-toplevel
> function types because:
> 	void f(int()) {}
> 	void f(double()) {}
> is a valid overload set.

I think the distinction required is that if we're encoding the type of
a function _object_, e.g. a top-level function name or a thunk, we
don't need the return type, whereas if the function _type_ is itself
what's being mangled, we need it.  True?

> (<value number> is a nonterminal without a production.)

The "value" is in italics, to be ignored, so this is <number>, which
appears in the first cluster of productions.

> > I haven't yet touched the compression or examples sections.  I've been
> > trying to figure out a good way to indicate in the grammar segments
> > which components get compressed, but haven't come up with a nice one
> > yet.  Ideas?
> 
> How about:
> 
> 	<substitution> ::= S <number> _
> 	               ::= Sb
> 	               ::= Ss
> 
> 	<type> ::= <substitution>
> 	       ::= <substitution> <template-args>
> 	<name> ::= <substitution>
> 	<nesting-qualifier> ::= <substitution>
> 	                    ::= <substitution> <template-args>
> 	<qualified-name> ::= St <name>
> 
> Hmmm, this doesn't reflect the fact that a substitution should not appear
> as a nonleading qualifier.

Why not?  It would be coincidental to find a match, and therefore
unusual, but would it be a problem?

> Maybe <nesting-qualifier>+ should be replaced
> by <qualifier> from:
> 	<simple-qualifier> ::= <source-name>
> 	                   ::= <source-name> <template-args>
> 
> 	<qualifier> ::= <simple-qualifier>+
> 	            ::= <substitution>
> 	            ::= <substitution> <simple-qualifier>+

How does the following work as a general principle?  Suppose that the
(grammatical) components that are candidates for later abbreviation are
precisely the same ones that may be replaced by a later abbreviation.
In that case, we need only be careful that our specification grammar
isolates replaceable components in their own productions, and then
indicate those productions, either by a special mark, or by adding a
"::= <substitution>" RHS (the latter would require some more care to
avoid including extras).

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272