(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...