MacroReturn?

[Franky]

Hi people.

I think, for syntax-true programming with Macros, a MacroReturn could be usefull.

What´s that?
With a Procedure you can Write:

Code: Select all

Procedure MyReturn(var1,var2)
   ; Do some stuff in several Lines (not possible in one line)
   ProcedureReturn var1+var2
EndProcedure
var3=MyReturn(5,3)

With a Macro you have to add a special Parameter:

Code: Select all

Macro MyReturn(var1,var2,result)
     ;Do some stuff in Several Lines (not possible in one line)
    result=var1+var2
EndMacro

MyReturn(5,3,var3)

In the upper example with Procedure, everything is clear, but in the Macro-Example, it´s not clear to see (in a complexer Code, I mean ) that there is a new value associated to var3.

So my Idea would be:

Code: Select all

Macro MyReturn(var1,var2)
     ;Do some stuff in Several Lines (not possible in one line)
    MacroReturn var1+var2
EndMacro

var3=MyReturn(5,3)

the compiler could just put all the stuff which is not in the Line of the "MacroReturn" above the current Line (var=MyReturn(5,3)) and replace MyReturn(5,3) with 5+3.

Like this:

Code: Select all

;Do some stuff in several Lines(not possible in one line)
var3=5+3

This way, it would be possible to use macros to have a better speed.

The only thing that has to be watched out for is, that MacroReturn has to be the last Line of the Macro

Does anyone understand me? :roll:

[Dare]

Understood.

Agree to a degree.

[Matt]

Then why wouldn't you just use a procedure instead?
That is Not the True purpose of a macro though!
Read the manual to find out what macros are....

[Dare]

Ahem ...

Matt, a macro as used in PureBasic can be seen as a glorified "copy paste" or a glorified "IncludeFile" with parameters.

That is, it expands out to put code modified by parameters into places where it is the placemarker.

This is faster than a procedure.

So macros are sometimes preferable to procedures.

Having a facility that allows a macro to "return" a value is just a nice little enhancement. It saves doing a little bit of code contortion-ism in order to get the same effect. The contortion-ism adds codes and slows the macro, negating some of its value when used to speed up code.

Read between the lines.




Edit:

So I agree to a degree. The degree being there are other things that I personally would prefer to see first. But I would also like to see this.

[Hroudtwolf]

Hi,

This is not really possible.
Macros are not a bit similar to procedures.
Macros are closely related with constants and they aren't created for returning values.

Best regards

Wolf

[Dare]

Out of curiosity, how would you expect this macro to work? That is, what does it seem it should do?

Code: Select all

Procedure pReturn(a, b)
  r = a + 1
  v = b + 1
  ProcedureReturn r + v
EndProcedure

k = pReturn(10,11)
Debug k

Debug "---"

Macro mReturn(a, b)
  r = a + 1
  v = b + 1
  r + v
EndMacro

k = mReturn(10, 11)
Debug k
Debug "incidentally .."
Debug r
Debug v

Edit:

Read as is, it adds v to r
Read as a macro, it looks like it is saying k = r + v

Implementing a MacroReturn (or whatever keyword was used here) would simply tell the compiler that this line is incomplete, do not generate the r+ v code, instead generate the k = r + v code.

I am sure the PureBasic team has the nous to do something like that.


Edit again:

I bet the word "Return" pushes us into a mode of thinking. So rather let's use another word or two. Imagine this:

Code: Select all

Macro example(a, b)
  If a > b
    MacroUseLeft a - b
  Else
    MacroUseLeft b - a
  EndIf
EndMacro

k = example(3,2)

; expands to:

If a > b
  k = a - b
Else
  k = b - a
EndIf

; And to extend the silly season:

Macro exampleX(a, b)
  If a > b
    MacroUseLeft a - b MacroUseRight
  Else
    MacroUseLeft b - a MacroUseRight
  EndIf
EndMacro

k = exampleX(a,b) + 17

; expands to:

If a > b
  k = a - b + 17
Else
  k = b - a + 17
EndIf

Whereby whatever lies to the left and right of the macro is incorporated when "MacroUse*" is encountered.

And yes, there would be some rules required for stuff like:

Code: Select all

k = exampleX(a,b) + example(a,b)

Probably evaluate left to right or something.


As to what word(s) is/are used, who cares? Once defined by the dev team that is what it is.

[Hroudtwolf]

It returns nothing. It is replacing something.



'Cause of this, a macroreturn wouldn't work correctly with everything.

[Dare]

Hi mate, re-read my previous post.

There is some value in this, including reduction of typos and speed/ease of cutting code and speed of macro -v- speed of procedure.

And it doesn't break anything.

And those who don't like, don't use.

And (whatever other counter arguments apply)

[Hroudtwolf]

Ah. You've edited your post.

[Dare]

Yep, sorry, just before you posted. And now again, just after!

[einander]

;@Franky
;you can have a tricky return from macros: try this

Code: Select all

Macro MyReturn(var1,var2)
     var1+var2
EndMacro

A=5
For i=0 To 10
     MyReturn(A,3)
     Debug A
Next

Cheers

[Franky]

Hi people, nice to see your feedback

@Dare: Your idea sounds even cooler than mine
Even so I don´t really like those words (MacroReturn just remembers me of a ProcedureReturn, but you´re right, the way it works would be better discribed in MacroReplace or something)

Ah, we´llm find a name for those babies


@Einander: I already knew this possibility (so many i´s ) But the problem with this is, that you can not read it like "normal PB Syntax":

Of course, everybody in this board understands directly, what

Code: Select all

Macro MyReturn(var1,var2)
     var1+var2
EndMacro

A=5
For i=0 To 10
     MyReturn(A,3)
     Debug A
Next

does.

But imagine this: You get a code (whatever, JaPBE Opensource, TheMatrix reloaded, whatever) with, ah, lets say 10.000 Lines of code.

So, now you have a problem, that in Some case, A gets associated a wrong value. Now, what would you do, to find the problem?

I, and I think, most of the others would try to find the place, where this Value is associated to A. So you´ll scan the Lines Searching for an "A=".

But there is none.

so, what to do? Right, you´ll try to do a Debugg in each line, to see, after which line A changes.

That´s a little more work, isn´t it?

And now imagine, A doesn´t get this new associated Value inside this Macro but in a Macro which is "called" in a Macro which is "called" in a Macro which is "called" in a Macro which is "called" in the Macro you found responsible for the wrong A.

Have a bug? Have fun

And don´t forget, finding the place, where A gets the wrong value is not always the place, where the bug is So you might have some more Variables changing their variables in Macros;)



I hope you understand, what I mean

And btw: I know, that "called" is the wrong word, because Procedure are the only ones to be called, Macros are replaced. But I lost a page in my dictionary which contains the right word for "called" in the upper text :roll:

[freak]

Well, as Hroudtwolf said: A macro is replaced, so it cannot "return" anything either.

The calling of a procedure and the replacement of a macro are two very different things.
Mixing the two in terminology would only be a cause of trouble, because
it would look the same but still work very differently behind the scenes.

For example, take this procedure code:

Code: Select all

Procedure Something()
  WithSideEffects()
  ProcedureReturn 123
EndProcedure

a = MoreSideEffects() + Something()

It is clear that MoreSideEffects() is called before WithSideEffects(), because the procedure call is after the MoreSideEffects() call.

Now the same in your proposed macro version:

Code: Select all

Macro Something()
  WithSideEffects()
  MacroReturn 123
EndMacro

a = MoreSideEffects() + Something()

The intuition is that this works the same as the procedure code, as it looks almost the same and uses the same terminology. But it actually expands to this:

Code: Select all

WithSideEffects()
a = MoreSideEffects() + 123

I predict a ton of confused user's questions about that one, also it is a source
of very hard to find bugs, because it works different than it looks like on the
first glance.

What you people are looking for are inline procedures, which would allow you
to do pretty much the same things, but in a consistent way.

[Dare]

Thanks for the input, Freak. Given that I seldom know what I am talking about (not that it stops me) it is nice to learn something about what I was discussing.

Um, inline procedures?

* rushes off to learn what this means *

* gets lost on the way out *

[Rescator]

Although the idea it self is nice, I'd advice against adding this.
As either a register would be eaten up to handle the macro return val, or you'd have to have some sort of local macros which is a whole other issue.

If a procedure is too slow and a a macro lacks a "return",
maybe it's best to do what true optimizers do. Do it inline yourself

In the program or procedure make a result variable where your temporary calculation results are stored and then used again a few lines later.
The advantage of this is that the processor will notice this and should keep the often used result var's memory in the cpu cache somewhere,
so you get a speed increase that a MacroReturn would never get (as that would have to possibly create/destroy a local var each time it's used).