1. Swap and pass-by-reference
- Posted by bruce1961 Jan 26, 2011
- 1945 views
G'day
I just had a quick look into the past and saw a discussion in late 2009 about pass by reference. Has the situation changed at all? Reason I ask regards the RosettaCode question 'Generic Swap'; an Euphoria solution would seem to require pass by reference (or else something uniquely Euphorian that I'm ignorant of.)
The pass-by-value semantics means that that this
procedure swap( object a, object b ) object x x = a a = b b = x end procedure
doesn't work.
Kind regards, Bruce
2. Re: Swap and pass-by-reference
- Posted by DerekParnell (admin) Jan 26, 2011
- 1911 views
G'day
I just had a quick look into the past and saw a discussion in late 2009 about pass by reference. Has the situation changed at all? Reason I ask regards the RosettaCode question 'Generic Swap'; an Euphoria solution would seem to require pass by reference (or else something uniquely Euphorian that I'm ignorant of.)
Currently Euphoria can't do a generic swap.
I expect that either pass-by-reference and/or a swap operator will be implemented for Euphoria before too long.
I did start to do a swap operator but due to time constraints with getting v4.0 "out the door", work was suspended on it. I got it working in the interpreter and partly working in the translator. It would look like this ...
a <=> b
where 'a' and 'b' can be any Euphoria data type and the data types of 'a' and 'b' were compatible with each other.
3. Re: Swap and pass-by-reference
- Posted by petelomax Jan 27, 2011
- 1670 views
a <=> b
{a,b} = {b,a}
(or whatever syntax you lot settle on for multiple assignment) would be a more useful addition to the language.
I am surprised no-one has suggested swap(a,b) be implemented via a pre-processor.
Regards, Pete
4. Re: Swap and pass-by-reference
- Posted by mattlewis (admin) Jan 27, 2011
- 1662 views
a <=> b
{a,b} = {b,a}
(or whatever syntax you lot settle on for multiple assignment) would be a more useful addition to the language.
Your multi-assignment is another feature people have asked for (and that would be very useful):
{success, val} = value( some_variable )
Matt
5. Re: Swap and pass-by-reference
- Posted by DerekParnell (admin) Jan 28, 2011
- 1544 views
a <=> b
{a,b} = {b,a}
(or whatever syntax you lot settle on for multiple assignment) would be a more useful addition to the language.
The 'multiple assignment' (also known as de-sequencing) idea is a more generic one; the swap operator is a subset of that, but one which can provide better performance.
The difference is that the de-sequence operator requires a list of variables (lvalues) on the left-hand side and a list of values on the right-hand side (rvalues). It is a natural fit for a list of values in Euphoria to be represented by a sequence. The lvalue for this operation is not a sequence but a list of assignable identifiers, which is not the same as a sequence. The lvalue is a parsing issue and not a run-time issue.
When the de-sequence operation is implemented, one could use it to implement a swap operation, but it would not be as efficient as a purpose-built swap operation because the rvalue would have to construct a sequence at run-time (though a smart optimising parser might be able to improve this in some circumstances). For example ...
@(a,b) = {b,a}
(N.B: I'm using here a possible syntax @( ... ) to denote a list of variables.)
The right-hand side would create a temporary sequence containing the values inside 'b' and 'a', then the assignment of those values would be made to 'a' and 'b' respectively, thus effectively swapping them. The temporary sequence would then be deleted.
But by using a swap operator, there is no temporary sequence created and deleted, instead the values are swapped in the most efficient way for the data-types involved.
There is certainly a place for a de-sequence operator in Euphoria, and I would support its implementation, but I also think that a purpose built swap operator is also a useful construct in the language.
I am surprised no-one has suggested swap(a,b) be implemented via a pre-processor.
I think I do remember a brief discussion about that. A problem with the pre-processor is that it is not designed to handle multiple pre-processing tasks. For example, the Euphoria programs that create these web pages were run through a specific pre-processor that knows about web-stuff (webclay). Now if someone uses a swap operator in the webclay code, the output of the webclay preprocessor would then have to go through the 'swap' pre-processor as well, and I'm not sure if that is even feasible or desirable.
A pre-processor is designed to implement one specific transformation. If your code has multiple 'pre-processor' elements, it needs to be run through multiple pre-processors so that all the transformations are done. The management and performance of such a set of operations may not be so desirable.
This might be one reason that some form of built-in text-macro processing might be a useful (but dangerous?) addition to the language.
6. Re: Swap and pass-by-reference
- Posted by unkmar Jan 29, 2011
- 1437 views
@(a,b) = {b,a}
(N.B: I'm using here a possible syntax @( ... ) to denote a list of variables.)
Looks like perl.
7. Re: Swap and pass-by-reference
- Posted by DerekParnell (admin) Jan 29, 2011
- 1446 views
@(a,b) = {b,a}
(N.B: I'm using here a possible syntax @( ... ) to denote a list of variables.)
Looks like perl.
OMG!!! .... the world is about to implode ...
8. Proposed new preprocessor usage scheme for 4.0
- Posted by jimcbrown (admin) Jan 30, 2011
- 1341 views
I think I do remember a brief discussion about that. A problem with the pre-processor is that it is not designed to handle multiple pre-processing tasks. For example, the Euphoria programs that create these web pages were run through a specific pre-processor that knows about web-stuff (webclay). Now if someone uses a swap operator in the webclay code, the output of the webclay preprocessor would then have to go through the 'swap' pre-processor as well, and I'm not sure if that is even feasible or desirable.
A pre-processor is designed to implement one specific transformation. If your code has multiple 'pre-processor' elements, it needs to be run through multiple pre-processors so that all the transformations are done. The management and performance of such a set of operations may not be so desirable.
One particular concept, which although it has never been made official is currently supported by the current 4.0 preprocessor handler, is that each preprocessor is given a unique file extension and that the different preprocessors input and output are kept separate from each other.
For example, take the following: a preprocessor that handles only .h files (generating Euphoria dll/so library wrappers) combined with the webclay preprocessor that handles only .etml files and also a preprocessor that wraps .sql files (raw SQL statements) in (for example) edbi code, combined in the main .e/.ex code - that is unhandled by any preprocessor. The main .e/.ex code can directly include .h files and access the library, include the .sql files and easily do sql work, and include .etml and do dynamic html page generation. We have now combined 4 languages - C's header files and SQL and HTML and Euphoria.
None of that code is meant to go though multiple preprocessors but by using multiple preprocessors separately, we've saved the trouble of either having to convert or wrap C/SQL/HTML code and text by hand, or the trouble of having to deal with manually running the preprocessor and maintaining the output Euphoria code for a long term program.
So, this particular concept, that of preprocessor separation, where instead of running the same code through multiple preprocessors sequentially to add multiple features, we instead run separate parts of the code of the application through different preprocessors to make use of different features in different parts of the code, allows one to take advantage of multiple preprocessors in a far more practical, and maintainable, way.
Of course, this is not so useful if your goal is to be able to add features X, Y and Z from preprocessors A, B, and C and then use those features anywhere and everywhere in your code. (If you want to do this, I recommend dot4.)
9. Re: Proposed new preprocessor usage scheme for 4.0
- Posted by bruce1961 Jan 30, 2011
- 1321 views
One particular concept, which although it has never been made official is currently supported by the current 4.0 preprocessor handler, is that each preprocessor is given a unique file extension and that the different preprocessors input and output are kept separate from each other.
...
So, this particular concept, that of preprocessor separation, where instead of running the same code through multiple preprocessors sequentially to add multiple features, we instead run separate parts of the code of the application through different preprocessors to make use of different features in different parts of the code, allows one to take advantage of multiple preprocessors in a far more practical, and maintainable, way.
Sounds good to me. To use the StackOverflow notation: "1+"
Bruce.
10. Re: Proposed new preprocessor usage scheme for 4.0
- Posted by DerekParnell (admin) Jan 30, 2011
- 1346 views
One particular concept, which although it has never been made official is currently supported by the current 4.0 preprocessor handler, is that each preprocessor is given a unique file extension and that the different preprocessors input and output are kept separate from each other.
...
Of course, this is not so useful if your goal is to be able to add features X, Y and Z from preprocessors A, B, and C and then use those features anywhere and everywhere in your code ...
Which was exactly what I was referring to. The 'file extension' idea is both a useful and a useless idea - depending on what you are trying to achieve. It is useful when a complete file has been written in the 'pre-processor' (domain specific language) code but not so useful when you are 'cherry-picking' pre-processor functionality.
The swap concept could be implemented with either a text macro sub-language or an AST macro sub-language ... or as a native built-in operator.
11. Re: Proposed new preprocessor usage scheme for 4.0
- Posted by jimcbrown (admin) Jan 30, 2011
- 1371 views
Which was exactly what I was referring to. The 'file extension' idea is both a useful and a useless idea - depending on what you are trying to achieve. It is useful when a complete file has been written in the 'pre-processor' (domain specific language) code but not so useful when you are 'cherry-picking' pre-processor functionality.
Which is why I recommended dot4. Of course, this doesn't address the original problem that prompted this thread...
The swap concept could be implemented with either a text macro sub-language or an AST macro sub-language ... or as a native built-in operator.
The only example I've worked with is C's preprocessor (as key C features such as include/header files and text macros are implemented in the preprocessor) and M4, but using one in Euphoria feels too much like the "tack on another preprocessor" option.
