Excuse my slow reply - I'm flat-out at the moment.
Grant Jacobs wrote:
Grant Jacobs wrote:
Debugging:
No, it isn't. Why do you think it should? `Exit' is BP compatible. To stop the program use `Halt'.
My screw up, sorry. I've never used BP, btw; exit in other languages exits the program.
In C, yes. (I don't know about `exit' in other languages.) In this case, I'd rather follow BP and UCSD than C, since `Exit' to leave a procedure is not really a misnomer.
Just leave it - its just a name in the end. I was just explaining how I got confused. Most languages I know of use exit() to exit the program and return to leave a subroutine|procedure. I suspect for historical reasons languages that are (largely) Unix-based (e.g. perl, C, Unix shells) use exit(). Who knows...?
I'll look at this again when I find time. I'd like to think I use a parameter in the routine though, it'd be a rather pointless parameter otherwise!
Sure, and then the second error is clear (to me). But the first one is more important, and if you don't get it, this would be a real problem.
One day...! Let's hope I remember.
I think my confusion must have come from the fact that all other other descriptions other than that for rewrite (append, reset, etc.) say its optional. They do hint to read rewrite for more details. I.e. read alone (without reading the rewrite section) the descriptions for append, etc. would be misleading. The impression I got on reading the "for more details see rewrite", was that'd it'd be more of the same in more detail, not that'd there might be something that'd contradict the text preceding it. I'd be good to add a line: "If you're using untyped files, the last parameter is essential; see rewrite for details." to the descriptions for reset, append, etc.
OK, I understand the confusion. I'll try to clarify things in the next release.
Ta. Hopefully it'll spare someone else the trouble.
Macro expansion of __FILE__ seems to be inconsistent. In cases it expands to a full path and in others to just the local filename. It seems to be that if the file is in the local directory compared to the main program being compiled, just the filename is returned; if the source file is in another directory, a full path is returned.
What do you suggest? Always a full path?
I'd prefer a full path as that has all the info. Its easy enough to get a substring for the bits, etc.
OK, I'll change that.
Sounds good!
Anyway it should be possible to define C macros to the same effect, such as:
#if defined (__STDC__) || defined (ALMOST_STDC) #define CONCAT2(a,b) a##b #else #define CONCAT2(a,b) a/**/b #endif
I was meaning varargs in particular, not macros in general (hope I'm reading you correctly.). I've got debugging macros in place already. I tried porting the ones I use in C code, but they have varags, so I've re-worked them as far as I could.
Making such a macro compatible to a new Pascal macro will then also be a one-time setup, so it's acceptable I hope.
No chance you can allow the user to define a preprocessor as a command-line option, then anyone who wants to can feed the code through the C (or other) preprocessor? This could have a other uses to people who want their code preprocessed by their own means. Reminds me I wrote a Pascal preprocessor. Forget why, though! (I'm thinking in part here that although I can currently do push a single source file though the preprocessor, to compile a whole project like by first preprocessing it, I'd have to compile everything to .o files, then link them as I won't have access to pulling in things via 'uses' the way the Pascal compiler does. It'd be better for the compiler to feed each source code through my choice of pre-processor on my behalf. Follow my meaning?)
About varargs in macros. I don't mind that varargs might be too much work (fair enough - there aren't enough hours in the day to do the things I want to either), but saying that debugging writes aren't a good enough use to justify varargs to me is not so valid... Like debugging, testing and verification isn't important enough...?!
I didn't mean to imply this (since I put a lot of work into maintaining GPC's test suite myself).
I had hoped not :-)
Rather I'm still thinking of alternatives, and how the effort required compares with implementing varargs macros (though, as I said, I'm not sure yet, how much effort the latter will be, perhaps it'll turn out rather easy). Of course you can always define `DebugWrite1', `DebugWrite2', ...
As I'm sure you already know, one of the key uses for varargs is so that you can blindly pass on argument lists without having to consider their syntax, e.g. the arguments to printf (in C). Two quick C e.g.s (not tested, based on e.g.s in Harbinson & Steele and what I recall off the top of my head my own use of them):
#ifdef DEBUG #define DebugPrint(...) \ printf( debugFile, "%s %s %s > ", __FILE__, __LINE__, timestamp() ) \ printf( debugFile, __VARARGS__ ) ; printf( debugFile, "\n" ) ; #else #define DebugPrint(...) #end
#define ArgList2String(...) #__VARARGS__
The reason I'm dropping these in is that they might be a couple of useful e.g.s to try test out your ideas on macros. Probably not much help, but...
I'm looking for ways to achieve a general form with the existing capabilities. Unfortunately I haven't found any so far. The direction I'm thinking along is something like
{$define DebugWrite(X) WriteLn X}
i.e. `DebugWrite ((foo, bar, baz))' -> `WriteLn (foo, bar,baz)' (just an extra pair of parentheses needed). Unfortunately, you probably don't want to write debug information to `Output' and I see no way to get a file parameter in that macro expansion ...
So varargs macros might be justified in the end, but I'm still waiting for other arguments for both sides ...
I'll try put my thinking cap in this. Jog my memory if I forget.
Personally I'd plug for you popping in user-defined pre-processing options into gpc, then you're covered either way.
BTW, about the C syntax, what does `__VA_ARGS__' actually stand for? I'm wondering if (if we do it in the end) we shouldn't allow to define a parameter name for the varargs instead of having such an (ugly IMHO) "magic" name.
Not sure precisely, but most likely something along the lines of VARiable (number of) ARGumentS.
Grant
Grant Jacobs wrote:
No chance you can allow the user to define a preprocessor as a command-line option, then anyone who wants to can feed the code through the C (or other) preprocessor? This could have a other uses to people who want their code preprocessed by their own means.
That's already possible, and I don't think GPC needs any particular support for it. Just let the preprocessor write its result to a temp file/pipe and let GPC read from that file/stdin(`-'). You might need `-x Pascal' (or here, perhaps, rather `-x Preprocessed-Pascal') if the temp file (or stdin obviously) does not have one of the known Pascal file name suffixes. With correctly set-up Makefiles or whatever (mostly a one-time job) it could be done quite automatically AFAICS.
It's quite the same way that program generators such as lex and yacc are usually invoked (though calling them preprocessors would be a little understatement).
Reminds me I wrote a Pascal preprocessor. Forget why, though! (I'm thinking in part here that although I can currently do push a single source file though the preprocessor, to compile a whole project like by first preprocessing it, I'd have to compile everything to .o files, then link them as I won't have access to pulling in things via 'uses' the way the Pascal compiler does. It'd be better for the compiler to feed each source code through my choice of pre-processor on my behalf. Follow my meaning?)
OK, then it would be job for the `gp' utility which is going to replace automake. Since I've yet to add user configuration to gp, this might be a point to consider. (In fact, I've thought about something like that WRT to lex and yacc, though no concrete ideas yet.)
As I'm sure you already know, one of the key uses for varargs is so that you can blindly pass on argument lists without having to consider their syntax, e.g. the arguments to printf (in C).
Sure. That's why I'm considering them at all. Currently, my plan is, when I get there, I'll see how difficult is it to implement them. If not, I'll just do it, otherwise let's see again ...
BTW, about the C syntax, what does `__VA_ARGS__' actually stand for? I'm wondering if (if we do it in the end) we shouldn't allow to define a parameter name for the varargs instead of having such an (ugly IMHO) "magic" name.
Not sure precisely, but most likely something along the lines of VARiable (number of) ARGumentS.
So `__VA_ARGS__' means `var. args. args.'!? ;-)
Frank
-
Frank Heckenbach -
Grant Jacobs