[SOLVED] Macro to immitate C-style "return" statement

[furious programming]

I don't like the expression Exit(Foo) because it looks like a function call, not a control statement, what annoys me. Is there a way to create a return Foo statement using macros so that I don't have to use this parameterized Exit? I could kill to build such a return into the language.

BTW: A simple Exit replacement can be done with the {$DEFINE return := exit} macro, so that's not a problem.

[Martin_fr]

Not that I can think off. That is I can't find any way to add the closing: );

Marcos don't have params (beside those would probably be in parenthesis, which would render them mood).

So you need something at the end of the "return 1;" that can be translated to add the ).  (I assume "return 1);" is too ugly)

Closest I can get is define a temp macro inside the macro.... (and yes it is pure evil).
But it requires a word/identifier after the return value.

Code: Pascal  [Select][+][-]

1. program Project1;
2. {$Macro on}
3. {$define return := {$define bye := ); {$define bye := bye}} exit( }
4.  
5. function foo: integer;
6. var bye : Integer;
7. begin
8.   return 1 bye; // by here is a "keyword" not the variable.
9.   bye := 1;
10. end;
11.  
12. begin
13. end.
14.  

you could do "return 1 _;" underscore can be a macro for );

[PascalDragon]

I don't like the expression Exit(Foo) because it looks like a function call, not a control statement, what annoys me. Is there a way to create a return Foo statement using macros so that I don't have to use this parameterized Exit? I could kill to build such a return into the language.

Use MacPas mode if you're so desperate for it. Other than that this will not be supported.

Code: Pascal  [Select][+][-]

1. program treturn;
2.  
3. {$mode macpas}
4.  
5. function Test: LongInt;
6. begin
7.   return 42;
8. end;
9.  
10. begin
11.   Writeln(Test);
12. end.

[Thaddy]

exit(x) can usually - always - be avoided by altering the code  flow slightly.

[MarkMLl]

I don't like the expression Exit(Foo) because it looks like a function call, not a control statement,

I agree, but we're stuck with it: it's one of those quirks, like mod looking like a control statement but actually being an operator.

Actually, there are some very grey areas: allowing that "and" and "or" applied to booleans was inherited from ALGOL, I've seen ALGOL documentation which implied that the parser was handling if ... and ... or ... then and so on as an extremely complex statement type, rather than "and" and "or" being special short-circuiting operators.

MarkMLl

[furious programming]

Marcos don't have params (beside those would probably be in parenthesis, which would render them mood).

That's a pitty... I didn't think macros could be embedded. Good to know, thanks for the tip.

But why doesn't Free Pascal support macros with parameters? Haven't had time to implement them yet or for some other reason? They are very useful, especially for creating various constructions useful for debugging.

Use MacPas mode if you're so desperate for it.

I'm not desperate. I just don't like this construction, and if I don't like something, I'm looking for a way to change it and make it easier for me to work with the code.

I have a question for you. You suggest using the {$MODE} switch, but it not only adds return, it also changes other language constructs. However, for example, {$MODE MACPAS} does not allow me to use {$INCLUDE}, because it must be {$I} (short version, why?).

Does it work in such a way that the {$MODE} switch gives the same as a set of different {$MODESWITCH} and instead of {$MODE} you can just manually unlock and lock specific language features with multiple {$MODESWITCH}? If that's true, meaning instead of {$MODE}, you can specify everything yourself with a set of multiple {$MODESWITCH}, then that would be fine with me — I know which features I want to use and which ones I don't need.

exit(x) can usually - always - be avoided by altering the code  flow slightly.

Yes, it can, but in the case of sequential code that needs to set a specific result in many places and exit the function immediately, the exit(x) or return x construct is very convenient. Not only does it allow one instruction to do two things (set the result and exit the routine), and thus avoid creating unnecessary begin ends, it also allows to avoid long and repeatedly embedded blocks of conditional statements.

[Bogen85]

Marcos don't have params (beside those would probably be in parenthesis, which would render them mood).

That's a pitty... I didn't think macros could be embedded. Good to know, thanks for the tip.

I did not know know macros could be embedded either.... (And if I did, I don't seem to recall that...)

Martin_fr's attempt to get it to work almost seemed like he was mocking you, furious programming 

[MarkMLl]

I did not know know macros could be embedded either.... (And if I did, I don't seem to recall that...)

Martin_fr's attempt to get it to work almost seemed like he was mocking you, furious programming 

I think "nested" would be a better choice of words here. I'm not surprised that they can be nested, since they're very close to normal $defines. And they can extend over multiple lines etc. in a way that C macros can't (without messy escaping).

And I'm pretty sure Martin was genuinely trying to be helpful. Shame it didn't quite work.

MarkMLl

[Bogen85]

I think "nested" would be a better choice of words here. I'm not surprised that they can be nested, since they're very close to normal $defines. And they can extend over multiple lines etc. in a way that C macros can't (without messy escaping).

And I'm pretty sure Martin was genuinely trying to be helpful. Shame it didn't quite work.

Agreed, both on the "nested" and Martin's attempt.
Also, C macros can't define macros or do includes. (But do have their own nesting for expansion purposes...)

It is more like the limitations of FPC's macros that were doing the mocking (not Martin).

I've had some success using mcpp with the following options -NPk -I- -z.

The pre-processors that come with clang and gcc don't match line numbering adequately (and maybe some other issues, I don't recall).

However, while mcpp does work quite well, it complicates the build process too much, so I abandoned it, and just work within the confines of what fpc can do. And I even got that to work via make and staging directories where the actual build takes place, but it is just to messy in my opinion, and would not easily scale to be usable in Lazarus. Ok, it could, with a wrapper around fpc... Still, too complicated...

[furious programming]

And I'm pretty sure Martin was genuinely trying to be helpful. Shame it didn't quite work.

Now I know that it is unlikely to be done, and additionally that macros can be nested. So sure, he was very helpful.

[Bogen85]

I've had some success using mcpp with the following options -NPk -I- -z.

Also, mcpp can't stringify with a single quote, it can only use double-quotes, as it was never intended to be used for pascal.

[MarkMLl]

Ok, it could, with a wrapper around fpc... Still, too complicated...

No, it would need a hook inside fpc (or more likely the ppc binary it invokes) since the Pascal compiler will handle a whole tree of files in a single operation. And previous discussion has made it quite clear that even if somebody provided a patch for that it wouldn't be applied.

So I really do think we're best leaving it there.

MarkMLl

[Thaddy]

That said, mcpp is still useful when translating C headers because of its macro expansion feature:
h2pas will work much better on the pre-processed source. (then again cpp -E does much the same, only too verbose.)

[Martin_fr]

And I'm pretty sure Martin was genuinely trying to be helpful. Shame it didn't quite work.

Now I know that it is unlikely to be done, and additionally that macros can be nested. So sure, he was very helpful.

I wasn't mocking you... Though I did know that my result/example wasn't any good for you. I just thought I get the train rolling. Maybe others would have ideas sparked by it.

[MarkMLl]

I wasn't mocking you... Though I did know that my result/example wasn't any good for you. I just thought I get the train rolling. Maybe others would have ideas sparked by it.

You definitely made a good point, although I'm not entirely sure about your

But it requires a word/identifier after the return value.

Looking at this the other way round, if we assumed a finite number of return values e.g. an enumerated type like the days of the week, it would of course be possible to do something like

Code: Pascal  [Select][+][-]

1. {$define return_wednesday := exit(wednesday) }
2.  

Looking around in the past, I've not even been able to find a decent Pascal-oriented preprocessor which would fit nicely into a makefile.

MarkMLl