OpenEuphoria

2. Re: = vs := and = vs ==

• Posted by jaygade May 07, 2014
• 2104 views

I think that it would unnecessarily complicate things. You might as well introduce a keyword "let". I never had a problem differentiating between equality test and assignment.

As for comparing the equality of objects with "=" instead of "equal()", it's been discussed before but I would have to dig back through the archives to remember all of the old arguments pro/con.

4. Re: = vs := and = vs ==

• Posted by ryanj May 07, 2014
• 2105 views

I find that having multiple types of = just makes it easier to have syntax errors, such as accidentally assigning a value in an if statement and wondering why it always returns true. I like the simplicity of euphoria and the small set of symbols to remember. I find that languages that have 50 different types of operation symbols may make your code look more compact and gives you a sense of accomplishment when you managed to iterate a variable while shifting bits and doing logic operations all in 1 statement, but Euphoria code is so much easier to read and comprehend. I especially like the lack of semicolons between every statement.

6. Re: = vs := and = vs ==

• Posted by ghaberek (admin) May 07, 2014
• 2108 views

I do not think this is necessary. I don't think many people get confused by assignment vs comparison.

What is confusing, however, is why = cannot compare objects while equal() can. (Can't = just be shorthand for equal()?) IIRC, allowing = to compare objects in if/while statements is relatively trivial. I believe it's a simple matter of changing the op (opEQUAL?) routine in the interpreter. At least, this was true in Euphoria 2.x and 3.x. I haven't spent much time in the Euphoria 4.x source code, but I would welcome this change.

-Greg

8. Re: = vs := and = vs ==

• Posted by DerekParnell (admin) May 07, 2014
• 2067 views

There is no need to introduce new operators. The reason for Euphoria's limitation on using '=' for boolean compare in statements is the because of a design decision to evaluate the expression before using the result in the test. Basically it boils down to the definition of IF is more like ...

IF integer THEN

So when the parser sees 'if a = b then' it first evaluates the 'a = b' like this ...

When 'a' or 'b' is a sequence, then each of its elements are evaluated for equality and a sequence is returned as the result. We end up with

IF sequence THEN

which is illegal.

The way to properly "fix" this is to change the parser to perform a boolean test in these situations rather than a sequence operation. This is quite a big deal though, given the way its coded.

10. Re: = vs := and = vs ==

• Posted by gimlet May 08, 2014
• 2051 views

Just to put my position on this so people know.

I find == annoying in awk which I use a lot - it is error-prone.

I have always liked := and even <- for assignment (Ada, Pascal, Algol)

I don't mind = and for some reason I find Euphoria's usage for both assignment and comparison comfortable and easily better than C's =, ==.

My original comment was not a criticism but to make the point that a = b is not surprising but 'A' + 'B' is (even though it will sum in Euphoria).

I don't use goto much and would rather do without it generally but if x then goto ERROR is usually cleaner than other error-handling in Euphoria.

12. Re: = vs := and = vs ==

• Posted by jimcbrown (admin) May 08, 2014
• 2037 views

Huh? What's the usual error-handling in Euphoria, then?

14. Re: = vs := and = vs ==

• Posted by jimcbrown (admin) May 08, 2014
• 2081 views

Um, Euphoria doesn't have that yet.

So you think using goto is cleaner than exception handling? Interesting.

Or are you saying that using goto that way looks like exception handling in Euphoria (a poor man's exception handling, so to speak) and both are cleaner for that reason? In which case, they are cleaner than ... what, exactly?

16. Re: = vs := and = vs ==

• Posted by _tom (admin) May 08, 2014
• 2044 views

The problem in documentation is learning what is "surprise." One then writes something that hopefuly makes the surprise go away. (The fun part is writing a one line description in a thousand page manual so we can say RTFM.)

1. An object is composed of just one or many numbers.
2. The plus character + always adds.
3. The result of + is another number.

4. x = 'A' + 'B'
   

   x has to be a number, no surprise.

If you accept the principle that Euphoria is consistent and predictable then there is no room for surprise.

If you come pre-conditioned from another language then 'A'+'B' can have an alternative meaning.

Overloading + to mean concatenation is possibly convenient; I could equally say that when plus no longer adds, I am surprised.

_tom

18. Re: = vs := and = vs ==

• Posted by gimlet May 08, 2014
• 2017 views

The surprise is that this doesn't make good sense.

This is a distinction between what you can do and what you should do.

Basic's 'A' + 'B' was and still is concatenation.

20. Re: = vs := and = vs ==

• Posted by _tom (admin) May 08, 2014
• 2015 views

The Basic language was designed to "get something working" on a mainframe computer. Design and elegance was not a consideration at that time. Kids in computer 101 ran around with punch-cards and everyone was happy to get a for loop working. Basic does not make perfect sense, but it works.

Ruby is a "whimsical language" were the syntax follows what Yukihiro Matsumoto felt made sense. Lots of people, who think like Matsumoto, like Ruby. If you think in Ruby it makes sense.

Euphoria was inspired by "speed." To get speed you need a clean direct path to that speed. That is why when you learn that + means add numbers, Euphoria always adds numbers.

If I say "Euphoria is easy to learn" it is because once you learn a principle you can depend on it. That is much simpler than saying + sometimes adds and sometimes concatenates, but that is ok because the data-types are different.

If you add a lot of "should do" (for whimsical reasons) you no longer have a Euphoria language.

_tom

22. Re: = vs := and = vs ==

• Posted by SDPringle May 10, 2014
• 1982 views

I like := for assignment and == for comparison. I don't see why they should even throw errors necessarily when used in a place where = would have the other meaning. If I were designing a language from the ground up, I would have := for assignment and == for comparison. Comparison like Phix with == and comparison one object down with something like (==), two objects down with ((==)). Conditionals would have to evaluate to a boolean type, which would have to be builtin to the language, like Java.

Honey (==) Money -- is (false, true, true, true, true) 
Honey == Money   -- is false 
( "Ha", "Ja" ) (==) ( "Ja", "Ja" ) -- is (false, true) 
( "Ha", "Ja" ) ((==)) ( "Ja", "Ja") -- is [ (false, true), (true, true) ] 

Shawn

24. Re: = vs := and = vs ==

• Posted by ChrisB (moderator) May 10, 2014
• 1944 views

I'll raise your three yucks with six. ~shudder~

Chris

26. Re: = vs := and = vs ==

• Posted by petelomax May 11, 2014
• 1896 views

Mismatched sequence size is a no op for elements of the longer sequence [even for - and /]. 
{} op object is no op. Returns object unchanged. 

Interesting idea. Not that I have any compelling reason to make such changes, given the following function implements the current behaviour,

function sq_div(object a, object b) 
    if atom(a) then 
        if atom(b) then return a/b end if 
        for i=1 to length(b) do 
            b[i] = sq_div(a,b[i]) 
        end for 
        return b 
    elsif atom(b) then 
        for i=1 to length(a) do 
            a[i] = sq_div(a[i],b) 
        end for 
        return a 
    end if 
    if length(a)!=length(b) then fatal(a,b) end if 
    for i=1 to length(a) do 
        a[i] = sq_div(a[i],b[i]) 
    end for 
    return a 
end function 

then this implements that suggestion

function xq_div(object a, object b) 
    if atom(a) then 
        if atom(b) then return a/b end if 
        for i=1 to length(b) do 
            b[i] = xq_div(a,b[i]) 
        end for 
        return b 
    elsif atom(b) then 
        for i=1 to length(a) do 
            a[i] = xq_div(a[i],b) 
        end for 
        return a 
    end if 
--  if length(a)!=length(b) then fatal(a,b) end if 
    if length(a)<length(b) then 
        for i=1 to length(a) do 
            b[i] = xq_div(a[i],b[i]) 
        end for 
        return b 
    end if 
    for i=1 to length(b) do 
        a[i] = xq_div(a[i],b[i]) 
    end for 
    return a 
end function 

Not exactly difficult, at least in hll, though there are quite a few of them, and like I said I'm not convinced it is necessarily an improvement.

Oh, I have heard that one before

I concluded this is a knee-jerk reaction to the dreaded "true/false condition must be an ATOM", which used to plague me back in the days when I used RDS Eu.

Since moving full-time to Phix and removing implicit sequence ops, this happens, I kid you not, less than once a year.

Besides, I simply just don't buy that expressions such as "{1,2,3} and {4,5,6}" have any meaningful true/false answer, and for my money "programming error" wins hands down.

I have no clear idea what you really mean by that. If you are thinking of some mythical performance-related issue, I have found that it is almost always faster to use a non-sequence-op method, and in fact hll code such as that above can be aggressively pass-by-reference-optimized [although I should admit to recently breaking that handling in Phix] and therefore (at least for quite long/nested sequences) massively outperform the equivalent low-level code.

Pete

28. Re: = vs := and = vs ==

• Posted by BRyan May 11, 2014
• 1860 views

I thought the purpose of the Pre-Processor was add things like := and == etc.

30. Re: = vs := and = vs ==

• Posted by petelomax May 11, 2014
• 1797 views

I was almost entirely focused on the "builtins" word, vs hll code. I have no disagreement with anything else just said.

To be fair, I cannot see anything "wrong" with that idea, just not really anywhere it would be genuinely useful...

Pete

32. Re: = vs := and = vs ==

• Posted by jimcbrown (admin) Jun 09, 2014
• 1604 views

Mismatched sequence size is a no op for elements of the longer sequence [even for - and /]. 
{} op object is no op. Returns object unchanged. 

function xq_div(object a, object b) 
    if atom(a) then 
        if atom(b) then return a/b end if 
        for i=1 to length(b) do 
            b[i] = xq_div(a,b[i]) 
        end for 
        return b 
    elsif atom(b) then 
        for i=1 to length(a) do 
            a[i] = xq_div(a[i],b) 
        end for 
        return a 
    end if 
--  if length(a)!=length(b) then fatal(a,b) end if 
    if length(a)<length(b) then 
        for i=1 to length(a) do 
            b[i] = xq_div(a[i],b[i]) 
        end for 
        return b 
    end if 
    for i=1 to length(b) do 
        a[i] = xq_div(a[i],b[i]) 
    end for 
    return a 
end function 

I've now implemented something like this (though nop elements are truncated): http://scm.openeuphoria.org/hg/euphoria/rev/bc7ba9aea3a6

(I'll look into keeping, instead of truncating, the nop elements at some point in time.)

I've also implemented jaygade's suggestion for this in the feature branch.

34. Re: = vs := and = vs ==

• Posted by petelomax Jun 10, 2014
• 1536 views

That seems fine.

Is there a changeset for that?

Pete Edit: did you mean http://scm.openeuphoria.org/hg/euphoria/rev/587f8aedb552 ?

36. Re: = vs := and = vs ==

• Posted by jimcbrown (admin) Jun 11, 2014
• 1475 views

I've now implemented the keeping of nop elements: http://scm.openeuphoria.org/hg/euphoria/rev/253355d356ea

38. Re: = vs := and = vs ==

• Posted by jimcbrown (admin) Jun 15, 2014
• 1393 views

Should the relevant messages be moved from that thread to this one?

The reason this happened is that several years ago, someone made a comment about this kind of functionality on that thread. I replied recently, saying that it was now implemented, and the discussion grew from there.