
<html>

<head>

<style><!--

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Tahoma

}

--></style>

</head>

<body class='hmmessage'>

> No different from names of variables, formals, constants, or procedures.<BR>> I can't think why the backend would need them for code generation/optimization.<BR><BR>

 <BR>

For debugging.<BR>

 <BR>

<BR>> They do belong in debug info, however.<BR>

 <BR>

 <BR>

Exactly. Maybe.<BR>

Except, I'm thinking..maybe only for entering expressions with casts?<BR>

Maybe not for viewing any values?<BR>

 <BR>

I think the way the compiler is currently structured, it is a lot of work to get this right,<BR>

and not with much gain.<BR>

The gain would be that typenames in expressions with casts would be 1) evaluated<BR>

relative to context 2) easier...typenames should probably be lengthened<BR>

in order to have a context-independent name. The lexical scopes<BR>

that introduce type names, in order of decreasing frequency would be roughly:<BR>

  module<BR>

  toplevel function in a module<BR>

  block or nested function <BR>

 <BR>

We could qualify typenames with Module or Module.Function or Module.Function.NestedFunction.<BR>

There's no obvious good name for blocks (WITH, FOR, etc.), but maybe numbers 0, 1, 2, etc.<BR>

 <BR>

 <BR>

I think the frontend and frontend/backend interface need work.<BR>

In this case there's not much to gain.<BR>

I'll cover something else in a separate mail.<BR>

 <BR>

 <BR>

 - Jay<BR>

 <BR>                                          </body>

</html>