Variable number of parameters_(re)

Tue, 18 Mar 1997 21:24:22 GMT

  
(Continuation of this thread from c.l.p.b)

kblix@sn.no (Kim Robert Blix) wrote:
> heckenb@mi.uni-erlangen.de (Frank Heckenbach) once said:
> >> There is NO challange in locating the obstacles - they will become obvious
> >> anyway. Try to find a solution instead - Its so much more rewarding.
> >
> >No, I don't agree. Your approach sounds much like "let's just program a few
> >lines, and if it doesn't work, we'll change everything". This ad-hoc strategy
> >might work for small projects, but any larger project (of which a Pascal
> >compiler is most definitely one), needs some good planning and design before
> >starting the actual coding. This includes identifying all the obstacles in
> >advance, and finding solutions to them - first a general solution, then a
> >concrete way to implement the solution, then verify that the solution really
> >covers all situations... It might not be as much fun as just sitting down in
> >front of the screen and typing a few lines of code, but it's the only way to
> >manage the complexity of such a project.
> 
> Yes, I agree. What I meant was that when this was first presented to the group,
> a lot of people started by saying "this cant be done" and "this is not possible"
> instead of "this would be hard because of that and that, but could possibly be
> solved by this" .. The only constructive replays has come from you. 

Thanks! But don't forget that the newsgroup is about *Borland* Pascal, and
most people are mainly interested in it, and speaking from this perspective.

> >But again: be careful with it! C needs it because the language itself lacks
> >some features like constants or modularization. However, Pascal - in a
> >sufficiently sophisticated version - should not need a preprocessor at all,
> >except for things like symbol-dependent compilation. IMHO, it's good style
> >to avoid the preprocessor when possible.
> 
> But It can be oooh so practical when needed. :)

But there are many traps. Imagine the following:

{$define sum a+b}
d*sum - this will be d*a+b, i.e. (d*a)+b instead of d*(a+b) as one might
        expect.

or:

{$define square(a) a*a} (if sqr wasn't already declared)

function f:real;
begin {Long and complicated code} end;

square(f) - you see what happens?

> >> you could just check what the variable was defined as, and then handle it in the
> >> appropriate way. this would go for any declared variable. In cases like this:
> >> write('this is a number',51)
> >>
> >> you check if its a string (quoted) or a number (non-quoted). This pretty much
> >> includes most cases.
> >
> >Not quite. Detecting the types is a bit more complex than you might imagine
> >now, but it is surely possible - it's one of the important things the compile
> >has to keep track of. The difficulty comes in when the compiler has to decide
> >between several possible procedures/functions to call (as it can do for
> >Write(ln), but is quite more involved for user-defined overloading/varargs).
> 
> Do you have an example where the above approach would fail?

You mean the rule: string if quoted, number otherwise? There are many 
examples:

- variables: not quoted, but can be strings, numbers or anything else
- function results: the same
- expressions (like a+b): the same
- constants: the same
- ...

And dont't forget that there are many other types besides strings and numbers!

If you're really interested in how these things works, you'll have to find out
a lot about parsing and similar things.

> >I think we should carry on this discussion on the mailing list. If you follow
> >up, please post there. Anyone else from this group who's interested in this
> >subject can subscribe to the list or fetch the postings from its archive,
> >with the URLs I posted the other day.
> 
> Argh! :) You could have mentioned that a bit earlier in your post! :)
> I'll Jump in and subscribe today.

I'd assume you read the whole article before starting to reply...
Besides, you could still have posted to the list instead of the newsgroup,
I suppose...
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)