Re: newbie can't get exceptions to work!

[Mats Karlssohn <mats@mida.se>]

Ted Dennison wrote:
> 
> In article <3AD2AF50.6B5DD470@mida.se>, Mats Karlssohn says...
> >
> >Could we get the language to handle dispatching calls that in some of
> >the
> >cases dispatches to a function and in some cases just get the return
> >value
> >from one array *big smile* ? I've quite recently implemented a hirarchy
> >with these properties by wrapping the arrays in functions. It would be
> >nice if the compiler could generate the wrappers by itself. But maybe
> 
> Interesting example. :-)

Thanks, I try to be an interesting guy ;)

> First off, I don't think it would be consistent to do this kind of thing unless
> you also allowed an array to be a tagged type (not a component, but a tagged
> type in and of itself). Otherwise, what's the syntax for deciding what array to
> use? There may be some neat way of doing that, but I don't see it.

In my example the arrays were components of a tagged record, but
generalizing them to be tagged types themselves would be at least
interesting, possibly fruitful.

To clarify: I made an hirarchy (spl ?) of tagged records, one
dispatched function takes an integer argument and returns a
string. For some cases, the string needs to be calculated from
other components in the record. For other cases the string is
constant only depending on the integer, and thus (IMHO) best
implemented as an array of (constant) strings, so I had to
implement (inlined) functions that returns a value from the
array. Implementing the functions were no major hassle, since
there were quite few of them, BUT it feels kind of stupid to
do it this way.

As I'm writing this I realize that I should have tried to
implement the lookup functions as a generic function. I'll
have to try that (shouldn't be a big problem I guess).

BTW, the system I'm talking about in the example is part of
a status monitoring for distributed embedded processors. The
part I'm discussing is translating numeric status codes to
human readable messages.

> But let's pretend that wasn't an issue (now we're off in never-never land of
> course). In other posts I've been equating array indexing to an automaticly
> pragma-inlined canned mapping function.

Yes, IMHO that's a correct way of viewing it. I do have some
background in formal logic so I can se most relations as mapping
functions. However, I can also see the view that an array is just
data storage (thus ignoring the work needed to access the data).

> Now I think dispatching can be split into two cases: dynamic and static. Static
> dispatch is just the insertion of the proper type's function call into the
> generated code. It shouldn't be too big of a deal for a compile to insert the
> indexing code rather than a function call when appropriate.

Yes.

> For dynamic dispatch, the compiler essentially generates a big case statement,
> based on the object's tag, where each branch contains a function call. You could
> also think of it as a jump (to subroutine) table. Now if the compiler is just
> doing a table lookup and JSR'ing to the result, then there's going to be a
> subroutine call anyway. So you aren't really buying anything by not having to
> write that function that does nothing but index into an array.

That's right I guess. What is saved is the work of writing the
lookup functions (not a big deal) and more important we save
som cluttering of the source. I'd say that it'd be easier to
read if the compiler automatically generated the lookup function.

> However, if it actually is a big case statement, then there would be nothing
> wrong with having an inlined routine on one of the branches. In that case it
> would be doable. (Is pragma inline allowed for a dispatching call?)

Exactly my point. I don't know if it's legal or not.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809