OpenEuphoria

1. Pass by Reference

• Posted by DerekParnell (admin) Sep 11, 2009
• 2492 views
• Last edited Sep 12, 2009

Forked from Re: switch design

3. Re: Pass by Reference

• Posted by mattlewis (admin) Sep 12, 2009
• 2375 views

There are some cases where that's possible. I think one place where reference semantics are probably necessary is when you start dealing with OO. Consider the case where you have a member procedure that does something with private data. In this case, you may not even consider this to be passing by reference, but it really is, from a low level perspective. However, I think that it's perfectly natural, and not likely to confuse anyone. (This assumes, of course, that some sort of OO is eventually added to euphoria).

There are certainly benefits to easily passing references, and if you came from another language, it wouldn't surprise me that this was something you found extremely lacking. If we add something like this, we have to be careful to keep it 'euphorian'.

One aspect of that is to avoid making it too complicated, or difficult to use. That's a difficult task. While we've talked about the theoretical performance implications of COW, they appear to mainly be just thattheoretical. I'm sure we could create a situation where it was a real performance killer, but I think that in real applications, it's not.

So the real reason for adding it should be that it makes certain tasks easier (which it certainly will) without making other things more difficult, or causing drastic changes to the language as a whole.

Things like var_id(), and other reflection like techniques are more likely to surface when we get into dynamically evaluated code. It might be a reasonable workaround for a more native implementation of PBR.

Matt

5. Re: Pass by Reference

• Posted by jaygade Sep 12, 2009
• 2337 views

Wow. You covered that very well, Derek.

I've got nothing to add really, though I'll wait for further discussion. I like this suggestion at its face value, though.

7. Re: Pass by Reference

• Posted by Critic Sep 12, 2009
• 2334 views

You can, but references in general are more powerful than just PBR. AFAIK the current Euphoria implementation avoids building an abstract syntax tree (AST). However an AST (or some other graph structure) would provide a much better infrastructure for various optimizations. But currently Euphoria lacks references and without them building an AST is tedious. PBR does not really help for graph structures.

Not sure, if I understand you completely, but Pascal does it at compile-time: Constants cannot be passed to var/PBR parameters.

Pascal managed to do it at compile-time in the 70's.

Yes.

Another solution is to introduce a new object datatype that provides OOP features and are always references, just like in Java. Or copy Lua's tables (including its reference semantics) that are more dynamic.

9. Re: Pass by Reference

• Posted by mattlewis (admin) Sep 12, 2009
• 2305 views

True. That's another area that has to be thought out before it could happen, and just for reasons like that.

Matt

11. Re: Pass by Reference

• Posted by DerekParnell (admin) Sep 12, 2009
• 2291 views

References do not have to be addresses. The new eumem.e module can be used to model virtual address spaces in which graphs and trees can be managed just as you would in C using RAM addresses. Plus with added safety and flexibility.

That's right. And how does the Pascal compiler know which arguments are PBR and which are not? It knows because the coder specifically designates which are which. That means new syntax and more to learn and more complexity in coding. There are trade offs involved and we all still want Euphoria to be a simple-to-use language.

But let's go down that path ... using pretend syntax for now here is a routine that accepts a PBR argument.

procedure toUpper( byref sequence text) 
   for i = 1 to length(text) do 
      if t_character(text[i]) then 
          text[i] = UniCode_Upper(text[i]) 
      end if 
   end for 
end procedure 
c

Ok, so this procedure converts characters in the passed sequence into uppercase characters.

sequence Name 
... 
   Name = db:fetch("name") 
   toUpper(Name) -- Ok as 'Name' is not immutable. 
... 
include defaults.e 
   Name = db:fetch("name") 
   if length(Name) = 0 then 
       toUpper(DefaultName) -- Not ok as this is a constant in 'defaults.e'. 
   else 
       toUpper(Name) -- Ok as 'Name' is not immutable. 
   end if 

Sure, this is a poor way to do it. So how's this ...

   if length(Name) = 0 then 
       Name = DefaultName 
   end if 
   toUpper(Name) -- Ok? as 'Name' is not immutable. 

Well not exactly. When one sequence is assigned to another, no actual copying of data takes place, just the reference to the original is copied and the reference counter incremented. So now, the call toUpper() would be modifying the constant value.

To avoid this we need to copy the constant data before calling the function. So now the coder must know which things are constants and which are not, know that they have to copy stuff explicitly (sometimes), and know which arguments are PBR ones. The complexity level rises.

I'm not saying that this is too hard to solve, just that by necessity, PBR will bring a little more complexity to the language, rather than make it simpler-to-use.

Ok, but now you add more responsibility onto the coder and make things more complex. For example (and again using pretend syntax) ...

constant FOO = {"bar", "qwerty"} 
procedure Xyzzy(sequence S) 
    for i = 1 to length(S) do 
        toUpper(S[i]) 
    end for 
end procedure 
 
Xyzzy( byref FOO ) 

Here we have a a procedure 'Xyzzy' that does not modify the referenced data passed to it (FOO still contains two references and those references are not modified by Xyzzy). But the procedure modifies the data pointed to by FOO. So is FOO a constant or not? Most people would expect that displaying FOO before and after calling Xyzzy() will give the same result.

Again, this can be solved but only by increasing the language's ease-of-use.

"Another solution"? - what was the first solution? And what was it solving?

Due to the way that Euphoria datatypes are recorded in RAM during run-time, adding any new datatype will cause some slowness to generally creep into every application, even if they do not use the new datatype.

Again, just noting that there could be trade-offs involved.

13. Re: Pass by Reference

• Posted by jacques_desch Sep 12, 2009
• 2254 views
• Last edited Sep 13, 2009

Can a variable be on the stack if it is not a procedure argument or local variable? If not so I don't see how this can be a problem. At parse time we know that a variable is on stack and so can forbid reference to it. Please show me an exemple where it's not true.

Jacques

15. Re: Pass by Reference

• Posted by jacques_desch Sep 12, 2009
• 2233 views
• Last edited Sep 13, 2009

But don't we know at any time that a reference is pointing to stack? If so we can forbid storage or return of that reference without flow analysis?

17. Re: Pass by Reference

• Posted by ghaberek (admin) Sep 13, 2009
• 2305 views

I really think PBR could be optimized into passing an object to a function and assigning its result to that same object, like:

foo = func(foo) 

To me, this seems seamless, if not elegant in its simplicity. It's an inherent and almost understood behavior. To elaborate, I have never thought that passing an object by reference for modification was all that good of an idea...

proc(foo) 

Here, it seems to me that the object just goes off into la-la land, never to be seen again. Something happens, but we don't care to know what, as we're not asking for a return value. If a function modifies an object, I should get that object back as the return. If I need to modify a sequence of objects, then I can pass multiple objects in a sequence:

sequence objs = {1, 2, 3, 4} 
objs = func(objs) 

-Greg

19. Re: Pass by Reference

• Posted by jemima Sep 13, 2009
• 2221 views

foo = func(foo) 

universe[x][y][z][t] = func(universe[x][y][z][t]) 

func(byref universe[x][y][z][t]) 

Unfortunately it might be clear when you are reading the function, but not when you are reading the call to the function.

IMO, the equivalent function call syntax would be something like

universe[x][y][z][t] = func($1) 

Where $1 means the first (or only) item being assigned on the LHS.

I believe PBR can be achieved by playing with reference counts. Consider the following code:

function notPBR(object x) 
    ... 
end function 
 
thing = notPBR(thing) 
 
object x 
procedure PBR() 
    ... 
end procedure 
x = thing 
thing = 0 
PBR() 
thing = x 
x = 0 

Clearly this is not an elegant way to actually code, but PBR() can modify x without COW overheads, whereas nonPBR() cannot. Perhaps you may need to write an example based on the above to prove the performance difference.

Then you need to think about how to get the compiler to safely mimic this code from some much simpler shorthand syntax, in particular allow a variable to be passed as a parameter and cleared or not ref-counted in one step.

21. Re: Pass by Reference

• Posted by mattlewis (admin) Sep 13, 2009
• 2201 views

I'm not sure you understood the original point. It wasn't about "something is modified." It was specifically about the arguments passed to the routine. Any language (Ok, maybe excepting pure functional) will allow changing some variable not within the scope of the routine.

Also, I'd quibble about your use of the term "global variables." While it's true that there is lots of code using global variables (of course, prior to 4.0, it was either local or global), I think you mean top level variables.

Even so, I don't think this criticism makes a lot of sense. Those top level variables are often the procedural equivalent to an object's member data in OO languages.

Also, your concerns don't mean a whole lot (in terms of expectations of effects of code). We're talking here about what a euphoria programmer expects. Since you've reminded us many times, those are words that will never describe you. I guess you're more of a Pascal programmer, where reference semantics and therefore expectation have existed for a while. A euphoria programmer does not expect for any arguments that are passed to a euphoria routine to be modified.

Even in languages like Java, there is a fair amount of confusion about how arguments are passed (hint: they are passed by value).

Matt

23. Re: Pass by Reference

• Posted by jeremy (admin) Sep 13, 2009
• 2158 views

Old Euphoria code as that was taught somehow to Euphoria programmers . We are trying to set a right example now with 4.0. I think every single global that was in Euphoria std libs and interpreter/translator code is gone.

Jeremy