Re: unfolded expressions

new topic     » topic index » view thread      » older message » newer message

Ralf Nieuwenhuijsen wrote:
>However, its seems, such expressions are more of a problem:
>
>   x + 1 = 34
>
>First of all, one must agree when used like above, for example, it can be
>more readable.

I do not see how that is more readable than "x = 34 - 1", especially
considering that the emphasis is on what gets placed into the variable, not
on the actual processing. I would think

   (50 / (2 * x + 4)) - 335 = 762 + z - (y / 6)

is MUCH more confusing than

   x = (25 / (1097 + z - (y / 6))) - 4

After all, when trying to solve for 'x' in your head to understand what's
going on, you have to translate it into the second form anyway...

>However, about multiple variables on the left-side, why not consistently
>assign to the first variable mentioned or dissallow multiple variables
>alltogether.

Well, that's not as bad as only assigning to undefined variables, but it's
still a rather trite and inelegant hack to the problem. (And I'm not even
sure I want to ask which variable would be "first"... the first one visually
or the first one encountered during evaluation...)

>Actually, I feel sorry, that a new idea such as this, is approached upon
>implementation issues rather the theory and use behind it. I never specified
>on the exact rules, and it really shouldn't matter, the choice of wether or
>not allowing confusing code is one totally apart from the decision and
>discussion of such a language extension.

I disagree, and apparently so does Rob.

Again, one of Euphoria's strong points is it's clarity; and this is because
Rob has purposefully created syntax and limited extentions to prevent code
confusion. That's why we have the "declare-before-use" limitation. It forces
consistent (non-ambiguous) code on us.

It's not an implementation issue. I'm sure the limitation makes writing the
compiler easier, but according to Rob, that's NOT why he put in that
limitation. I think most programmers would balk at the complete lack of need
for something like "x + 1 = 34". There are languages out there that handle
formal math syntax; if one cannot or for some reason refuses to translate
that expression into its more universally accepted form ("x = 34 - 1"), then
it's time to take a look at the mathematical benefits of those other languages.


Rod

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu