This approach risks causing confusion when switching between parts of the program which use different operator precedence. I think that the UI can help with this by making it clear which precedence rules are in effect. I've attached a mock-up of a Squeak workspace with an embedded mathematical expression. It is clear from the font and layout where the domain-specific mathematical notation is being used.
Cheers, Josh
<<inline: notation-switch.gif>>
On Nov 23, 2007, at 9:22 PM, Michael FIG wrote:
Hi, "Waldemar Kornewald" <[EMAIL PROTECTED]> writes:Let's take the explanation from wikipedia: "... a mode is a distinct setting within a computer program ..., in which the same user input will produce perceived different results than it would in other settings" Clearly, you need two different settings with two different interpretations of the same action. In our case, the first setting is math. The second setting is theprogramming language. If you introduce a different interpretation in aprogramming language then you introduce a mode because math is more common than that language."Math" may be more common than "that language," but for somebody writing a lot of code in "that language," it may make more sense not to have modality within the language. We have three modes at work: 1) Math operator precedence, as taught to mathematics students. 2) Selector precedence, as taught to Smalltalk programmers. 3) The precedence of selectors that happen to look like math operators (#- #+ #* #/). You can unify modes 1 and 3 (which you are proposing), or modes 2 and 3 (which is the status quo, and what many other people in this debate are behind), but you cannot unify 1 and 2. No matter what the choice of unification is, somebody is going to be unhappy. This is why I suggested to refuse the default precedence for math-like selectors, and require parentheses to make the associativity explicit. In other words, the precedence of those selectors may be ambiguous because mathematicians are so fond of an implicit precedence that violates Smalltalk rules, so let's make it explicit. -- Michael FIG <[EMAIL PROTECTED]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
