OpenEuphoria

2. Re: Multi-assign

• Posted by BRyan Nov 15, 2011
• 2722 views

{ x, y } = { 1, "foo" } 
 
{ $, x } = value( y ) 

I don't really understand what multiple assignment is; but if you use a dollar sign in a sequence could it be confused with the last position of a sequence for example: seq[1..$]

4. Re: Multi-assign

• Posted by mattlewis (admin) Nov 15, 2011
• 2681 views

Multiple assignment is a way to take the result of an expression that is a sequence, probably most commonly the return value of a sequence, and assign it in one go, without having to use a temporary variable. So:

-- instead of: 
x = value( something ) 
my_number = x[2] 
 
-- you could do: 
{ $, my_number } = value( something ) 

The confusion was the argument brought up, but I'm honestly not sure how one would confuse this. Also, $ can already be used as a list terminator:

constant 
    A = 1, 
    B = 2, 
    $ 
 
sequence s = { 1, 2, 3, $ } 

So, it's basically a place holder. Personally, I like it better than something like an underscore or a dash or a dot because as a glyph, it's fairly substantial and easy to spot and differentiate from other things.

Matt

6. Re: Multi-assign

• Posted by mattlewis (admin) Nov 16, 2011
• 2617 views

I've documenting what I've done. It currently looks like this:

Multiple Assignment

Special sequence notation on the left hand side of an assignment can be made to assign to multiple variables with a single statement. This can be useful for using functions that return multiple values in a sequence, such as value.

atom success, val 
 
{ success, val } = value( "100" ) 
 
-- success = GET_SUCCESS 
-- val     = 100 

It is also possible to ignore some of the values in the right hand side. Any elements beyond the number supplied on the left hand side are ignored. Other values can also be ignored by using a dollar sign ('$') instead of a variable name:

{ $, val } = value( "100" ) 

Variables may only appear once on the left hand side, however, they may appear on both the left and right hand side. For instance, to swap the values of two variables:

{ a, b } = { b, a } 

8. Re: Multi-assign

• Posted by jeremy (admin) Nov 16, 2011
• 2656 views

I dislike extra commas. They are hard to read, easy to get wrong and can make you look for hours for bad code. What about a - ?

{ -, last } = parse_name("John Doe") 

I know extra commas are used for parameters but I'd like to see that be deprecated and whatever we decide here be used there as well.

Jeremy

10. Re: Multi-assign

• Posted by jimcbrown (admin) Nov 16, 2011
• 2646 views

foo( 1, 2,, 4) becomes foo(1,2,#,4) 

I think that using the hash is a bad idea, as it's (imvho) more prone to being the result of a typo than the dollar sign would be.

What if the person meant <eucode> foo( 1, 2, #A, 4) </eucode> but missed the 'a'?

Of course, for a LHS of a multi-assign that's not an issue, since we can't have literal values (such as hexadecimals) in there anyways.

12. Re: Multi-assign

• Posted by Insolor Nov 16, 2011
• 2611 views

I vote for underscore. In some languages there is the anonymous _ variable, which is used when the value doesn't matter.

14. Re: Multi-assign

• Posted by jimcbrown (admin) Nov 16, 2011
• 2531 views

Which doesn't make it all that different from other keywords that we have added (like 'label' or 'loop') that were previously common variable names.

Even in 4.0 code, I doubt the underscore is a popular variable/routine name. In fact, I wonder if it has been used at all this way by any code.

16. Re: Multi-assign

• Posted by jimcbrown (admin) Nov 16, 2011
• 2550 views

That shouldbe fairly easy to fix up if necessary.

18. Re: Multi-assign

• Posted by jimcbrown (admin) Nov 16, 2011
• 2532 views

Wait, what? Why?

20. Re: Multi-assign

• Posted by jimcbrown (admin) Nov 16, 2011
• 2594 views

We could make it a one-character keyword (or other sort of reserved word). I don't think that using the underscore for this feature is very complicated from a technical perspective.

In any case, the aim should be to do what's easiest for users, not what's easiest to implement. Unless the effort to implement this is unreasonable, I wouldn't discount it (at least not for technical reasons).

Another idea would be to use a new keyword, like 'empty' or 'blank' instead of a special symbol (like the dollar sign or the hash character).

Hmm.

Nah, I'm totally against that.

22. Re: Multi-assign

• Posted by jeremy (admin) Nov 16, 2011
• 2552 views

I still like -,

{ -, lastname } = parse_name("John Doe") 

Sure, it is used in math but given the context it's pretty easy to determine it's not subtracting any numbers. Also consider my previous statement of making this newly chosen character (whatever it is) valid for function calls instead of just an extra comma:

some_func("John", -, "Doe") 
 
-- vs 
 
some_func("John", $, "Doe") 

Besides, $ requires a shift, - doesn't, that's reason enough

Jeremy

24. Re: Multi-assign

• Posted by DerekParnell (admin) Nov 16, 2011
• 2579 views

I'd prefer not to use '$' as it is already loaded with two meanings and to add a third is probably asking for future problems.

I think the dash '-' is fine for the LHS but not so good on the RHS. It could be a typo on the RHS where someone meant to key negative number as an parameter.

A new keyword is a really bad idea.

The preference for a shift-less character is not so important as the feature would not be a commonly used one. Also, keyboards vary as to which characters are shifted. For example, the tilde '~' is very awkward on some keyboards.

I think we need to have a glyph of some sort, and a visually prominent one would be preferable. We should try to avoid characters that are potentially typos.

So I think we are left with the single characters ... "@%^&*?" , and maybe combinations like "[]".

{ A, @, B }  = SomeFunc(1, @, 2) 
{ A, %, B }  = SomeFunc(1, %, 2) 
{ A, ^, B }  = SomeFunc(1, ^, 2) 
{ A, &, B }  = SomeFunc(1, &, 2) 
{ A, *, B }  = SomeFunc(1, *, 2) 
{ A, ?, B }  = SomeFunc(1, ?, 2) 
{ A, [], B } = SomeFunc(1, [], 2) 

26. Re: Multi-assign

• Posted by kinz Nov 17, 2011
• 2536 views

Multi-assign in BASIC is:

a,b,c,d,e = 1

So you need just:

object a,b,c,d,e = 1  --- is it possible in 4.*  now ? 
-- And then you can do: 
procedure ma(object a, object b) 
 if sequence(a) then 
   for i=1 to length(a) do 
        a[i]= b 
   end for 
 elsif atom(a) and atom(b) then 
        a = b 
 else 
 end if        
end procedure 
 
ma({a,b,e}, 2) 
 
?a 
?b 
?c 
?d 
?e 

Regards

28. Re: Multi-assign

• Posted by mattlewis (admin) Nov 17, 2011
• 2544 views

I agree with those reasons, and also believe that we should generally be parsimonious about adding keywords.

Yes, I agree with these. However, I think I may be the only one who still thinks the $ is perfect.

{ A, @, B }  = SomeFunc(1, @, 2) 

This is not awful, though I'd always imagined using @ for implicit routine id's or something in the future.

{ A, %, B }  = SomeFunc(1, %, 2) 
{ A, ^, B }  = SomeFunc(1, ^, 2) 
{ A, &, B }  = SomeFunc(1, &, 2) 
{ A, *, B }  = SomeFunc(1, *, 2) 
{ A, ?, B }  = SomeFunc(1, ?, 2) 

Yes. I was thinking modulo (%) and bitwise xor (^).

I think my preferences, so far, in order, are: $, ~, @.

Matt

30. Re: Multi-assign

• Posted by irv Nov 17, 2011
• 2480 views

The ~ by all means!

It's not currently used by Euphoria, so it's the best, least misunderstandable, most visible possibility. The fact that it is also used to indicate the user's home folder in Linux filenames isn't going to cause a problem.

Just read it as "whatever..."

32. Re: Multi-assign

• Posted by mattlewis (admin) Nov 17, 2011
• 2468 views

My original proposal was just for multi-assign. It seems to be growing into a generic bit bucket.

Matt

34. Re: Multi-assign

• Posted by jaygade Nov 17, 2011
• 2455 views

I was just wondering because the two ideas seemed kind of related. Not multi-assign and bit bucket, but placeholder and bit bucket.

36. Re: Multi-assign

• Posted by petelomax Nov 18, 2011
• 2374 views

{ A, ?, B }  = SomeFunc(1, ?, 2) 

That one makes the most sense to me.

Regarding $ on the RHS, to indicate omitted parameters, you cannot do that as it already has valid meaning:

sequence s 
s = {1,5,7} 
function f(object o) return o end function 
 
? s[f($)]  -- prints 7, as it should 
 
if getc(0) then end if 

Regards, Pete

38. Re: Multi-assign

• Posted by Insolor Nov 18, 2011
• 2319 views

? s[f($)] 

I used such trick in some programs:

s[rand($)]

40. Re: Multi-assign

• Posted by DerekParnell (admin) Nov 18, 2011
• 2306 views

s[rand($)]

Except that there is a problem with calling it a bug; it's documented as legal. Look at the section in the documentation on "Slicing of Sequences". In there we see ...

s[$][1..floor($/2)] -- first half of the last element of s 

Now although it may not be what some intended, it is documented, and what harm or problem does it cause?

42. Re: Multi-assign

• Posted by BRyan Nov 18, 2011
• 2279 views

Now that you agree with me :)

What about the ! explanation point ?

Bernie

44. Re: Multi-assign

• Posted by jimcbrown (admin) Nov 19, 2011
• 2244 views

What about $$$ ? That wouldn't break anything, iiuc.

46. Re: Multi-assign

• Posted by Fernando Nov 19, 2011
• 2232 views

Some interesting possibilities with LHS symbolic sequences:

• Initializing several variables with the same value:

{a,b,c} = 0

• Incrementing several variables:

{a,b,c} += 1

• Adding different values for different variables:

{a,b,c} += {d,e,f}

• Doubling several variables:

{a,b,c} *= 2

- Fernando

48. Re: Multi-assign

• Posted by Fernando Nov 19, 2011
• 2249 views

{a,b,c} = 0

{a,b,c} = 1       -- Assign 1 to a, b, and c 
{a,b,c} = {d,e,f} -- Assign {d,e,f} to a, b, and c or 
                  -- assign d to a, e to b, and f to c? 

IMHO, one of the intentions of multi-assign is to simplify the access to the elements of a returned sequence of a function. Then:

{a,b,c} = {d,e,f} -- assign d to a, e to b, and f to c

To satisfy the other case:

{a,b,c} = { {d,e,f} , {d,e,f} , {d,e,f} } 

- Fernando

50. Re: Multi-assign

• Posted by Fernando Nov 19, 2011
• 2203 views

{a,b,c} = 0

{a,b,c} = 1       -- Assign 1 to a, b, and c 
{a,b,c} = {d,e,f} -- Assign {d,e,f} to a, b, and c or 
                  -- assign d to a, e to b, and f to c? 

{a,b,c} = {d,e,f} -- assign d to a, e to b, and f to c

{a,b,c} = { {d,e,f} , {d,e,f} , {d,e,f} } 

My first thought was: because this is the Euphoric way. Comparing:

s += 1

with:

s += {a,b,c}

In the first case, each element of s is incremented. In the second case, first element of s is added by a, second element of s is added by b, ... and NOT the first element of s is added by {a,b,c}, ... But, the assignment operator '=' does not work as the assignment WITH operator (+=, *= , etc). We cannot assign an atom to a sequence. Thus, I think you're right: there would be an inconsistency in that form of initialization similar with the inconsistency in assignment operator with assignment with operator.

{a,b,c} = func() 

Yes, the assignment would operate differently depending on the type: atom or sequence.

52. Re: Multi-assign

• Posted by mattlewis (admin) Dec 03, 2011
• 1883 views

{ A, ?, B }  = SomeFunc(1, ?, 2) 

I think I have come around to this idea. I've updated the code, and added eubins for Windows / Linux, 32 and 64-bit here.

I also updated it so that you can use ? for default parameters in routine calls.

Matt

54. Re: Multi-assign

• Posted by mattlewis (admin) Dec 03, 2011
• 1908 views

Yes, I didn't put in the warning yet, but that was the plan.

Matt

56. Re: Multi-assign

• Posted by bill Dec 05, 2011
• 1706 views

I have viewed this thread with dismay.

Everyone seems to see only the positive (multi-assignment is good!). Yes it is useful (marginally). It provides a simple swap {a, b} = {b, a} and it allows the dreadful {?, x} = value(Y).

Consider:

integer a, b, c 
 
{a,b,c} = f(x)    -- 1 

A function (presumably) returns one value (sequence or atom).

If you are able to recover a, b & c then the {} are not acting as sequence forming operators in (1). (Otherwise: there would be a complaint about them being used before being initialised.)

The assumption is that the function will return values appropiate to the types of the LHS. What should those types be? The library functions often return different types (eg gets() returns -1 or a sequence).

{a,?,c} cannot be a sequence a slice [1..2] - what is its value?, its length?

f(x, ?, y): by the reasoning of {a, ?, c} the ? means 'disregard this value' not 'use the default'.

Disregard this value makes no sense applied to a function parameter.

Confusion between {a,b,c} = {d,e,f} as L-value <- R-value and an expression (pure R-value).

  {a,b,c} = {1,2,3}   -- either a:=1, b:=2, c:=3 or {a=1,b=2,c=3} 
  {1,2,3} = {a,b,c}   -- either an error or {a=1,b=2,c=3} 

The problem is not that you can't make this work. The problem is that syntactically they are identical. Therefore you cannot distinguish between an erroneous expression and a (correct) assignment and vice versa.

Instead of using {a,b,c} why not use something like < a, b,c > or | a, b, c | for multi-assign? That way it is clear this is not a sequence, but a list of some kind.

58. Re: Multi-assign

• Posted by jimcbrown (admin) Dec 05, 2011
• 1681 views

Why?

What's wrong with having a function return multiple values?

What are the negative effects?

Agreed. This is not the creation-of-sequence operator. This is in fact the inverse, it is desequencing.

Desequencing implies that the return type has to be a sequence (before the sequence can be desequenced) and to have a different type is to cause an error.

Well, you have a return value that is a sequence s that is desequenced such that a is assigned to s[1] and c is assigned to s[3] and s[2] is ignored.

So that symbol has at least two meanings. What of it?

I see these two technical meanings as very closely related. In both usages, the user is telling the language that the user does not care about the value.

  {a,b,c} = {1,2,3}   -- either a:=1, b:=2, c:=3 or {a=1,b=2,c=3} 
  {1,2,3} = {a,b,c}   -- either an error or {a=1,b=2,c=3} 

The answer:

  {a,b,c} = {1,2,3}   -- a:=1, b:=2, c:=3 
  -- conceptually shorthand for 
  sequence temp_s = {1,2,3} 
  a = s[1] 
  b = s[2] 
  c = s[3] 
  delete temp_s 
  {1,2,3} = {a,b,c}   -- an error 

I'm not clear on what you mean here.

It is technically possible to distinguish between the two. I know this because the code to do so has already been written and tested. The interpreter/translator/parser is able to do this.

Perhaps you mean that you think the concept is too confusing for a user?

I don't care much one way or the other on what symbols or characters are used, but changing that would not change the fundamental nature of desequencing.

A function would still return a sequence, and the operators would still desequence it.