2. Re: pass by ref

• Posted by SDPringle Sep 02, 2015
• 2330 views

Sort of. See the section in the Manual on 'Pseudo Memory'. In fact, it is a good idea you read the whole manual. If you only skim the API sections it is not so long.

Shawn

4. Re: pass by ref

• Posted by xecronix Sep 02, 2015
• 2288 views

For sure. I'll download/build it tomorrow and start trying it.

Thanks a lot. This is of course exactly what I was trying to do. Except I was attempting to merge the getters/setters into one function. But the more I think about that idea the more I'm convinced it's not a good idea.

I did change a small bit of your dude Class like code. Check it out! :)

dude_pseudo.ex with type checking

6. Re: pass by ref

• Posted by xecronix Sep 03, 2015
• 2239 views

Awesome, I think we just finished flushing out the tech for the next Additional Documentation topic.

8. Re: pass by ref

• Posted by _tom (admin) Feb 11, 2016
• 2053 views

OpenEuphoria frees you from some ideas you get by reading about programming in "other language." I wrote a tutorial to debunk ideas a beginner may have about PBR and "bigdata." A "clumsy example" now becomes a useful personal program.

_tom

OpenEuphoria vs PBR

Here are some thoughts about PBR (Pass-By-Reference) . If you program in OpenEuphoria you do not need PBR.

Pass-By-Reference

Using "other-language" the idea of PBR seems to offer:

1. speed
2. laziness
3. OOP

speed

Euphoria is fast without speed tricks like PBR. However, if your are programming in "other language" then tricks to speed things up are worthwile. Speed is the bonus you get by programming in Euphoria.

laziness

Using PBR to avoid writing an assignment statement is good for laziness and bad for safety. Unfortunately, PBR hides the exact location where the value of an object is changed in your code. Euphoria programs are easier to read and debug without PBR.

OOP

OOP style programming, while clever, can turn a simple program into a complicated program. By avoiding OOP and PBR you can keep programs simple. OpenEuphoria without PBR is friendlier.

But I Want PBR

OpenEuphoria is flexible if you insist. There is the option of using pseudo memory or structures to write powerful code. OpenEuphoria lets you write programs in your own style.

Conclusion

You don't need PBR to write efficient OpenEuphoria programs.

OpenEuphoria vs Big Data

The OpenEuphoria sequence is a marvel of language design. Go ahead and write reallybig_copy = reallybig without a speed or memory penalty because no actual copy is made. It "looks" like a copy and "behaves" like a copy but Euphoria actually uses internal pointers and optimizations to make your program fast and efficient. Go ahead and write simple--beginner--programs and let OpenEuphoria cope with "big data" effortlessly.

BigData Example

Create an enum to make indexing easier

enum Boss, Someone_else, Telno, Address, Next_meeting 

You get a set of constants numbered 1 2 3 4 5 without extra work.

You could create a huge sequence by writing:

atom hugenumber = 1_000_000 
sequence bigdata = repeat( {0,0,0,0,0}, hugenumber ) 

That gives you a database with a million items ready to be updated.

But, why bother when you can add an item just when you need it:

sequence bigdata = {} 
bigdata = append(bigdata, {"president", "", 41234, "head office", "Mon", "2:30pm" } ) 

You now have:

{ 
     {"president", "", 41234, "head office", "Mon 2:30pm" }, 
     -- room for lots more 
     $ 
} 

You are free to add, change, and remove items at any time.

Finally, use the enum constants to read and write values:

 
-- change values 
bigdata[1][Boss] = "Mr Big" 
bigdata[1][Next_meeting] = "Tue 9:00am" 
 
-- look at the values 
include std/console.e 
display( bigdata[1] ) 

You could create a procdure to output data:

procedure show( sequence data_item ) 
printf(1,  
` 

Boss            : %s 
Someone_else    : %s 
Telno           : %s 
Address         : %s 
Next_meeting    : %s 
`, data_item ) 

end procedure 

You now get output like:

show( bigdata[1] ) 

 
Boss            : Mr Big 
Someone_else    :  
Telno           : 41234 
Address         : head office 
Next_meeting    : Tue 9:00am 

A utilty to enter|change data looks like:

function write( sequence boss="", sequence someone_else="", sequence telno="", sequence address="", sequence nextmeeting="" ) 
    return { boss, someone_else, telno, address, nextmeeting } 
end function 
 
 

For example you could add a new item:

bigdata = append(bigdata, write("CEO","","","Branch Office", "Fri 3pm" ) ) 
 
display( bigdata ) 

The demo program now looks like:

enum Boss, Someone_else, Telno, Address, Next_meeting 
 
sequence bigdata = {} 
bigdata = append(bigdata, {"president", "", "41234", "head office", "Mon", "2:30pm" } ) 
 
-- change values 
bigdata[1][Boss] = "Mr Big" 
bigdata[1][Next_meeting] = "Tue 9:00am" 
 
-- look at the values 
include std/console.e 
display( bigdata[1] ) 
 
/* 

{ 
  "Mr Big", 
  "", 
  41234, 
  "head office", 
  "Tue 9:00am", 
  "2:30pm" 
} 
*/ 
 
 
procedure show( sequence data_item ) 
printf(1,  
` 

Boss            : %s 
Someone_else    : %s 
Telno           : %s 
Address         : %s 
Next_meeting    : %s 
`, data_item ) 

end procedure 
 
show( bigdata[1] ) 
 
/* 

Boss            : Mr Big 
Someone_else    :  
Telno           : 41234 
Address         : head office 
Next_meeting    : Tue 9:00am 
*/ 
 
 
--A utilty to enter|change data looks like: 
function write( sequence boss="", sequence someone_else="", sequence telno="", sequence address="", sequence nextmeeting="" ) 
    return { boss, someone_else, telno, address, nextmeeting } 
end function 
 
 
--For example you could add a new item: 
bigdata = append(bigdata, write("CEO","","","Branch Office", "Fri 3pm" ) ) 
 
display( bigdata ) 
 
/* 

 { 
    "Mr Big", 
    "", 
    "41234", 
    "head office", 
    "Tue 9:00am", 
    "2:30pm" 
  }, 
  { 
    "CEO", 
    "", 
    "", 
    "Branch Office", 
    "Fri 3pm" 
  } 
} 
*/ 

Conclusion

You can create a small database program for yourself, with unlimited capacity and flexibility, with very little code.

10. Re: pass by ref

• Posted by LarryMiller Feb 12, 2016
• 1893 views

OpenEuphoria has facilities that are usually better than pass by reference. But usually is not always. There are situations where pass by reference would be the easiest and most straightforward way of getting the job done. Using techniques like pseudo memory makes simulation of pass by reference less awkward but not as good as the real thing.

Almost all of the time using goto is a bad idea. But there are some situations where goto is a lesser evil than whatever else you might come up with to avoid it. The same with pass by reference.

12. Re: pass by ref

• Posted by _tom (admin) Feb 12, 2016
• 1906 views

I guess a language should be looked on a compromise. You can trim down a language to make it simpler--like Euphoria, or you can bloat it with features so that only one person can understand what you wrote--like Perl.

_tom

14. Re: pass by ref

• Posted by jimcbrown (admin) Feb 12, 2016
• 1886 views

integer a 
sequence b 
mytype c 
myothertype d 
    {a,b,c,d} = somefunc() 

Actually, dcuny wrote about this a year ago:

http://openeuphoria.org/forum/m/125975.wc

16. Re: pass by ref

• Posted by jimcbrown (admin) Feb 12, 2016
• 1872 views

Well, both aspects were mentioned. http://openeuphoria.org/forum/m/126202.wc and your response http://openeuphoria.org/forum/m/126215.wc

I also think I mentioned that what dcuny wanted was entirely doable with a preprocessor (compile (or rather preprocessor) time errors and syntax sugar). So, if someone else wrote one, and we had an actual proof of concept to work with, then it would be a lot easier to get this sort of change in. (Not that the acceptance is guaranteed - it's kind of confusing to have both multiple assignment and desequencing imvho, and desequencing is much more versatile in that stuff like value() doesn't have to be rewritten to make use of the new functionality.)

In any case, as was said before, we could implement all these checks in the parser, but with respect to desequencing, instead of adding another feature. I think the sticking point is that we don't have a way to specify strict type checking (or checking on # of ret vals) on return values today.