Re: unfolded expressions
- Posted by Roderick Jackson <rjackson at CSIWEB.COM> Jul 20, 1999
- 455 views
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