User definable operators 
Author Message
 User definable operators

Many programming languages allow the user to overload of language
defined operators. But a few languages also allow the user to define
their own operators.  I would like to have some feedback on the
experience of others with user definable operators with respect to
specifying their syntax, associativity, precedence, semantics (e.g.,
side effects or not), etc.

--

William B. Clodius              Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323            Group office: (505)-667-5776



Sat, 29 May 1999 03:00:00 GMT  
 User definable operators

Quote:

> Many programming languages allow the user to overload of language
> defined operators. But a few languages also allow the user to define
> their own operators.  I would like to have some feedback on the
> experience of others with user definable operators with respect to
> specifying their syntax, associativity, precedence, semantics (e.g.,
> side effects or not), etc.

I was going to wait until someone else replied to your question, just to
see what direction the discussion took.  But, since no one else took up
the challenge, I'll give it a go.

Now, for my own use, I would prefer languages with few operators.  This
isn't to say that I want no operators at all.  It's just that beyond
arithmetic, relational, string concatenation, and logical operators most
people have no intuition and most languages tend to get arbitrary and
arcane.  Indeed, most languages violate basic intuition with these basic
operators, never mind the user defined ones.

For most people, the relative precedence of the four arithmetic
operators is fairly intuitive.  However, there is no reason that unary
additive operators should have different precedence than their infix
counterparts.  Yet many languages give the unary operators high
precedence.  Now, add and multiply are arithmetically associative
(though not computationally so) and most people don't expect any
particular ordering of such operations unless parenthesized.  Languages
which violate this are either too restrictive on their optimizer or (if
they violate parenthesis) give too little control to the user.  If you
consider subtract as negate-and-add and if you consider divide as
invert-and-multiply, then they associate with add and multiply
(respectively) in a natural manner (this gives the same semantic
interpretation as having subtract and divide be left-to-right
associative, but it permits associativity to be applied during
optimization).

Exponentiation has a natural precedence above the other arithmetic
operators, but which is its natural associativity?  Left-to-right
associativity means that a^b^c is the same as a^(b*c), while
right-to-left means that a^b^c is the same as a^(b^c).  Right-to-left
preserves the operation and is what most languages select.  That's fine
and easily could be claimed to be intuitive (especially since none of us
have ever seen a language with the other convention).

For relational operators there seems very little evidence that their
precedence should differ at all.  They should certainly have lower
precedence than the arithmetic operators.  They also shouldn't associate
at all (unless, you can get things like a<b<c actually to mean that b is
between a and c).  After all, most attempts to associate such operators
is meaningless anyway : a<b>c; does this mean b is greater than both or
what?

The natural precedence of logical operators is 'not', 'and', followed by
'or' and 'exclusive or' in some order.  'Or' and 'exclusive or' both
associate with themselves but not with each other (so, if they are given
the same precedence, they should be non-associative).  The whole set of
logical operators should have lower precedence than relational operators
so that compound relations can be written without excessive parenthesis
(though some languages adopt a different convention simply because the
designer considered *some* parenthization desirable).

The question of whether associative logical operators should be made
left-to-right, so they can be short-circuited, is difficult.  Fully
associative definitions could be faster, especially on parallel machines
where the different conditions in a compound logical expression can be
independently evaluated.  Further, full association is closer to the
abstract semantic properties of the operators. In particular, when any
of the sub-expressions might have side-effects, it's nice to be able to
say that either none of those side-effects occurred (because the
expression was not evaluated at all) or all of them did.  (Of course
whether an expression should even be allowed to have side-effects at all
is also a contentious issue.)  On the other hand, short-circuiting is
important if one condition is required before the other can safely be
evaluated.  My own opinion is that the operators should be fully
assiciative and the conditional statements should have additional
short-circuit syntax forms:  "if(cond1) and if(cond2) then..." or "if
(cond1) or if(cond2) then..." would short-circuit after cond1 if the
whole condition can then be determined.

Concatenation is fully associative and has no natural precedence
relative to the arithmetic operators except that it should also be above
all the relational operators.

----

Now the reason to go through this discussion here - when the argument is
supposedly about user defined or overloaded operators - is to stress
that defining a set of operators to be natural and generally useful is a
difficult exercise.  Languages with lots of built-in operators tend to
be harder to learn and even programmers with long expertise in them tend
to occasionally have bugs arise due to their misuse.  When programmers
are allowed to define new operators and/or overload the existing ones on
a program by program basis, the difficulty of reading and maintaining
the code later is comparable to learning a new language for each
program.  For my own use, I'd prefer not to have to go though that.

Having said all that, I'll now take the opposite tack.  I'm something of
a libertarian about programming language features which do not make the
language too large.  That is, features which are easy to implement and
have a clear semantic definition don't really make the language that
much larger.  So, if some fragment of the target user community finds
the feature desirable, I say throw it in.  At least if it can meet the
following conditions (these conditions apply to all small language
features, user defined operators are just a specific example):

1) It must be easy to implement.  Well, user defined and/or overloaded
operators are simply syntactic sugar for function or procedure calls.
This makes them quite easy to implement in terms of features which
otherwise have to be in the language anyway.

2) The feature must be avoidable.  That is, a programmer who has not yet
learned the feature or has decided not to use it must not accidentally
stumble into the feature anyway.  Well, user defined operators require
rather verbose explicit declarations.  So it's difficult to merely
stumble into using them in your own code.  However, they might be
imported with modules or header files that are not well documented to
contain them.  So, this condition is met but deserves care.

3) Finally the feature should be locally discernible.  That is, you
shouldn't have to have an encyclopedic knowledge of the declarations in
effect in order to see that the use of the feature is involved in some
fragment of the code.  User defined operators fit this constraint.  If
you see an operator which is not intrinsic to the language, you know
that you must look up its definition to know what the program means
there (in this regard, it's merely a more terse version of a function
call in the same location).  Overloaded operators don't fit the
constraint, but you might relax it provided their range of applicability
is restricted.  For example, as long as '+' always means "add two
numeric values (of some type)", then you're not in for too many
surprises.  If it means "shuffle the deck of cards in the first operand
and deal them to the number of players given by the second operand"
you'll probably not be able to make much sense of the code.

-------

Language design is an exercise in compromise.  One of the advantages of
using a well known, standardized language is that the syntax and
semnatics of its features provide a stable set of signposts as to the
meaning of the program text.

A language with too simple a syntax (like some functional languages are
designed to be) tend to generate programs that appear uniform and
anonymous - it's simply difficult to find your way around.  You *hope*
that the programmer has chosen mnemonic names for things, that's your
only set of signposts.  Your only other option is to have an
encyclopedic knowledge of all the declarations in effect at all times
(easy for the compiler, but for the human?).

A language with too many (or very arcane) syntax rules is more difficult
to learn but has plenty of signposts.  There is a problem to the extent
that the features may strongly resemble each other (like very large
numbers of operators do) and may lead to just as serious a set of
misunderstandings as the language without significant structure.  If
your language looks like line noise, how do you know it's correct line
noise?  Or, if it's very verbose, with lots of long names and control
features, won't you tend to skim past the actual meat of the code?
(There's a whole additional discussion to be had about the value/penalty
of redundancy in a language's syntax.)

Allowing the individual programmer to design as many additional
features, or redefine the intrinsic ones as s/he wants is, in some
respects, the worst of both worlds.  The constraints I listed above are
a good guide for the language designer.  They are also a good guide for
the programmer who is faced with an overly mutable language.

There is no single balance of these considerations which is appropriate
for all programmers or application domains.  I have a vague idea where
*I* would draw the lines.  Indeed, I am writing a preprocessor for a

or punctuation).  So, for example, the way to construct a complex number

multiply its operand by the imaginary number 'i' and it returns type
complex.  Operators of this kind are quite discernable and
...

read more »



Sun, 30 May 1999 03:00:00 GMT  
 User definable operators


Quote:
1996 19:12:22 -0800 writes:

:>
:>>
[...]
:>
:>Well, that's my $0.04 (inflation).  I guess that on the original
:>question I am more in favor of user definable operators than of
:>overloading intrinsic ones.  Any other opinions?
:>
I agree with what you have said.
I like the ability to add operators because I also
know Algol68 and some APL.  These langauges had
several nice features for subscripting and sequences
which I would have liked to add to C++;  However C++ prevents me
from doing it.  Functions just don't hack it.  Might as well write it in pure
Lisp.

Ken Walter

All the above is hearsay and the opinion of no one in particular.



Mon, 31 May 1999 03:00:00 GMT  
 User definable operators

Quote:

> Many programming languages allow the user to overload of language
> defined operators. But a few languages also allow the user to define
> their own operators.  I would like to have some feedback on the
> experience of others with user definable operators with respect to
> specifying their syntax, associativity, precedence, semantics (e.g.,
> side effects or not), etc.

        My experiences of user-definable operators in Algol were almost
entirely positive.  It's very nice to be able to write a program that
"mimics" the natural language used in mathematics or physics or
engineering or music or whatever.  I know it's only syntactic sugar
that distinguishes "if A isrelatedto B then ..." from
"if isrelatedto (A, B) then ...", but sugar is important to the look
and feel of a language.  In the early years of Algol 68, fears were
expressed about SE and efficiency -- you write "a*b" and you don't
know whether you're multiplying two numbers, or two dirty great big
matrices, or, for that matter, deciding whether plane "a" is on a
collision course with plane "b" -- but in practice good programmers
wrote good programs and bad programmers could wreck any language.

        The only real problem our students ever seemed to have with
the Algol model was the universal issue of precedence, and I don't
think there *is* a good answer here.  Too many levels, as in C or
Algol, and even experienced users sometimes get them wrong;  too
few, as in Pascal, and you find yourself having to parenthesise things
that you don't feel should need to be parenthesised;  sadly, the number
of levels that is enough is already too many.

--
Andy Walker, Maths Dept., Nott'm Univ., UK.



Tue, 01 Jun 1999 03:00:00 GMT  
 User definable operators


: > Many programming languages allow the user to overload of language
: > defined operators. But a few languages also allow the user to define
: > their own operators.  I would like to have some feedback on the
: > experience of others with user definable operators with respect to
: > specifying their syntax, associativity, precedence, semantics (e.g.,
: > side effects or not), etc.

:       My experiences of user-definable operators in Algol were almost
: entirely positive.  It's very nice to be able to write a program that
: "mimics" the natural language used in mathematics or physics or
: engineering or music or whatever.  I know it's only syntactic sugar
: that distinguishes "if A isrelatedto B then ..." from
: "if isrelatedto (A, B) then ...", but sugar is important to the look
: and feel of a language.

My suggestion.  Let

       (A operation B)

(with parentheses *required*) be  sugar for operation(A,B) or
A.operation(B) depending on the particulars of the language.

:       The only real problem our students ever seemed to have with
: the Algol model was the universal issue of precedence, and I don't
: think there *is* a good answer here.

See above??!
: --
: Andy Walker, Maths Dept., Nott'm Univ., UK.

--

Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/



Wed, 02 Jun 1999 03:00:00 GMT  
 User definable operators

Quote:



> : > Many programming languages allow the user to overload of language
> : > defined operators. But a few languages also allow the user to define
> : > their own operators.  I would like to have some feedback on the
> : > experience of others with user definable operators with respect to
> : > specifying their syntax, associativity, precedence, semantics (e.g.,
> : > side effects or not), etc.

> :  My experiences of user-definable operators in Algol were almost
> : entirely positive.  It's very nice to be able to write a program that
> : "mimics" the natural language used in mathematics or physics or
> : engineering or music or whatever.  I know it's only syntactic sugar
> : that distinguishes "if A isrelatedto B then ..." from
> : "if isrelatedto (A, B) then ...", but sugar is important to the look
> : and feel of a language.

> My suggestion.  Let

>        (A operation B)

> (with parentheses *required*) be  sugar for operation(A,B) or
> A.operation(B) depending on the particulars of the language.

It has been done.  The purely functional language Haskell uses

   a `identifier` b

as abbreviation for

   identifier a b

(which is simply function application).  Interestingly, also
`conversion' the other way round is possible:

   (infixoperator)

(with parentheses required) stands for the function taking the
left operand as its first argument, and the right as its second,
so that

   (infixoperator) a b = a infixoperator b

Similar notations could be very useful in imperative languages
too.  Note, however, that this does not make the problem of
precedence disappear: it is still necessary to know the
precedence of infix operators.

Groetjes,

 <><

Marnix
--
Marnix Klooster        |  If you reply to this post,



Wed, 02 Jun 1999 03:00:00 GMT  
 User definable operators



Quote:

>> Many programming languages allow the user to overload of language
>> defined operators. But a few languages also allow the user to define
>> their own operators.  I would like to have some feedback on the
>> experience of others with user definable operators with respect to
>> specifying their syntax, associativity, precedence, semantics (e.g.,
>> side effects or not), etc.

>    My experiences of user-definable operators in Algol were almost
>entirely positive.  It's very nice to be able to write a program that
>"mimics" the natural language used in mathematics or physics or
>engineering or music or whatever.  I know it's only syntactic sugar ...

Well, my experience with them in Algol 68 and other languages is that
their main problem is that the language designers lose their nerve and
only half-provide them.  Algol 68 is no exception, though it does have
the excuse that it was a trail-blazer.  For example, common omissions
are:

    1) Not allowing the user to redefine built-in operators - VERY useful
for debugging numeric problems!

    2) Not allowing the assignment operator to be redefined, which makes
it impossible to implement your own space management.

    3) Having certain 'hidden' operators, such as the implicit copying
of arguments in most imperative languages.

    4) Not allowing user-defined initialisations, I/O operations and so
on.  This is closely reated to the previous point, of course.

    5) Not allowing user-defined coercions, in languages that rely on
them (e.g. Algol 68!)  Yes, I know what this would have implied :-)

The acid test of whether the language designers and implementors have
done the job properly is whether the user can implement his own arbitrary
precision arithmetic package, with his own dynamically varying object
sizes and storage management, and then install it as a replacement for
a standard arithmetic type and build applications using it without ANY
changes to those applications.

Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.

Tel.:  +44 1223 334761    Fax:  +44 1223 334679



Wed, 02 Jun 1999 03:00:00 GMT  
 User definable operators

Quote:

> Many programming languages allow the user to overload of language
> defined operators. But a few languages also allow the user to define
> their own operators.  I would like to have some feedback on the
> experience of others with user definable operators with respect to
> specifying their syntax, associativity, precedence, semantics (e.g.,
> side effects or not), etc.

in the functional language world, there is often little difference
between a user-defined function and an operator which is part of the
implementation. for example, the lisp "cddr" is often defined in
terms of "car" and "cdr".

precedence is not a problem in this type of language...

stuart



Thu, 03 Jun 1999 03:00:00 GMT  
 User definable operators



Quote:


>: > Many programming languages allow the user to overload of language
>: > defined operators. But a few languages also allow the user to define
>: > their own operators.  I would like to have some feedback on the
>: > experience of others with user definable operators with respect to
>: > specifying their syntax, associativity, precedence, semantics (e.g.,
>: > side effects or not), etc.
>:   My experiences of user-definable operators in Algol were almost
>: entirely positive.  It's very nice to be able to write a program that
>: "mimics" the natural language used in mathematics or physics or
>: engineering or music or whatever.  I know it's only syntactic sugar
>: that distinguishes "if A isrelatedto B then ..." from
>: "if isrelatedto (A, B) then ...", but sugar is important to the look
>: and feel of a language.
>My suggestion.  Let
>       (A operation B)
>(with parentheses *required*) be  sugar for operation(A,B) or
>A.operation(B) depending on the particulars of the language.

There are two problems with this.  One is that languages generally do
not allow that sugar.  The other is that this is inadequate.

Let me illustrate this with a well-known, or at least it should be,
operator, exponentiation.  fortran has it as an operator, and as such
x**y takes into account the types of x and y, and the good compilers
even take into account, at compile time, some of the options for y.
One that I know of had a supplied expansion for every integer value
of y up to 50, and for the negatives of these, used the reciprocal of
the result for the positive value.  Others were even more sophisticated,
recognizing half integers and using an expansion with sqrt.  Remember
that this was at compile time, where additional branches are relatively
cheap, compared to run time, where they are more expensive.

But C cannot even overload the power function.  And while C++ can, it
cannot take into account the constants at compile time.  So you say
the programmer should?  Maybe, but source programs are also generated
by computers, and loops may be expanded either by a preprocessor or
by the compiler.

Quote:
>:   The only real problem our students ever seemed to have with
>: the Algol model was the universal issue of precedence, and I don't
>: think there *is* a good answer here.
>See above??!

Frankly, I believe that precedence is overblown.  There should be few
rules, lots of parentheses, and even adjuncts to parentheses, like (_5,
and the compiler should be able to check with the programmer.

What is the precedence of a << b + c?  The answer in C differs with
what people not knowing the convention in the C language would come
up with.  Isn't the operation << multiplying by 2^b?  I would rather
go to a language which had no precedence, and required parentheses
in all cases except for associative operators.
--
This address is for information only.  I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399



Thu, 03 Jun 1999 03:00:00 GMT  
 User definable operators

Quote:


>>My suggestion.  Let

>>       (A operation B)

>>(with parentheses *required*) be  sugar for operation(A,B) or
>>A.operation(B) depending on the particulars of the language.

>There are two problems with this.  One is that languages generally do
>not allow that sugar.

That a problem with some existing languages, not with Matt Kennel's
suggestion.

As has been pointed out, there are existing languages such as Haskell
which allow syntactic sugar of this form.

Quote:
> The other is that this is inadequate.

That depends on your purposes.  It's certainly adequate for
many purposes.

But, yes, I get your point about optimization.  It's a completely
separate, orthogonal issue, but yes it is something worth addressing.

The problem could be rectified with a pretty simple language extension.

Indeed, GNU C already supports something that is close to this:
__builtin_constant_p().  Unfortunately that only works in macros,
though, not in inline functions.

--

WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"



Fri, 04 Jun 1999 03:00:00 GMT  
 User definable operators

Quote:

>> My suggestion.  Let

>        (A operation B)

> (with parentheses *required*) be  sugar for operation(A,B) or
> A.operation(B) depending on the particulars of the language.

        That's not sugar!  More like vinegar!  Try it:

    (x1 := (((- b) + (sqrt (((b ^ 2) - ((4 * a) * c))))) / (2 * a)))

[I hope I've got that right!].  But, you may say, you didn't mean it
to apply to assignations and standard arithmetic?  OK, but then what
is meant by "standard"?  Are overloaded operators standard as long as
the formula "looks like" one from the underloaded versions?  If the
language supports "+" [etc] for complex numbers, how am I supposed to
know whether "conj" and "arg" are "official" or user-defined in some
prelude used everywhere in my institution?  If I change the declarations
of "a" [etc] to be rationals rather than reals, do I have to go round
adding parentheses all over the place?  From the *user's* point of
view, and especially the physicist's [engineer's, mathematician's,
...] POV, it's a dog's breakfast, no matter where you draw the line.

        People want to be able to take a formula from a textbook,
paper, whatever, plonk that into their program, and have it work.
That is what user-defined operators help to give you -- but then
we get into all these problems with precedence and association and
overloading.

--
Andy Walker, Maths Dept., Nott'm Univ., UK.



Fri, 04 Jun 1999 03:00:00 GMT  
 User definable operators


Quote:


> >> My suggestion.  Let

> >        (A operation B)

> > (with parentheses *required*) be  sugar for operation(A,B) or
> > A.operation(B) depending on the particulars of the language.

>         That's not sugar!  More like vinegar!  Try it:

>     (x1 := (((- b) + (sqrt (((b ^ 2) - ((4 * a) * c))))) / (2 * a)))
> [...]

A lot of languages don't support operator precedence and things don't
get this bad.  The only parenthesis needed are those to force a given
expected precedence.  None are needed for operators that you normally
regard as having the same precedence.  Hence the above is:

      x1 := (-b + sqrt((B^2) - (4*a*c)))/(2*a)

Of these, only two innermost sets of parenthesis are *not* needed if
operator precedence is implemented as most people expect:

      x1 := (-b + sqrt(b^2 - 4*a*c))/(2*a)

I agree that this is better.  But, let's not get carried away.  For
example, writing "4*a*c" as "(4*a)*c" is an attempt to enforce an
associativity rule, not a precedence.

--
J. Giles
Ricercar Software



Fri, 04 Jun 1999 03:00:00 GMT  
 User definable operators



: >My suggestion.  Let

: >       (A operation B)
:        
: >(with parentheses *required*) be  sugar for operation(A,B) or
: >A.operation(B) depending on the particulars of the language.

: There are two problems with this.  One is that languages generally do
: not allow that sugar.  

Well that's something worth changing.

: The other is that this is inadequate.

: Let me illustrate this with a well-known, or at least it should be,
: operator, exponentiation.  Fortran has it as an operator, and as such
: x**y takes into account the types of x and y, and the good compilers
: even take into account, at compile time, some of the options for y.
: One that I know of had a supplied expansion for every integer value
: of y up to 50, and for the negatives of these, used the reciprocal of
: the result for the positive value.  Others were even more sophisticated,
: recognizing half integers and using an expansion with sqrt.  Remember
: that this was at compile time, where additional branches are relatively
: cheap, compared to run time, where they are more expensive.

: But C cannot even overload the power function.  And while C++ can, it
: cannot take into account the constants at compile time.  

Sufficient inlining should help significantly here.  C++ is multiply
handicapped on account of its antideluvian "I only can see textfiles
one at a time" attitude.

: Frankly, I believe that precedence is overblown.  There should be few
: rules, lots of parentheses, and even adjuncts to parentheses, like (_5,
: and the compiler should be able to check with the programmer.

I agree, in my proposal, the human must insert disambiguating parentheses
for all operations not universally standard by human convention.


Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/



Fri, 04 Jun 1999 03:00:00 GMT  
 User definable operators


: >> My suggestion.  Let
: >
: >        (A operation B)
: >
: > (with parentheses *required*) be  sugar for operation(A,B) or
: > A.operation(B) depending on the particulars of the language.

:       That's not sugar!  More like vinegar!  Try it:

:     (x1 := (((- b) + (sqrt (((b ^ 2) - ((4 * a) * c))))) / (2 * a)))

: [I hope I've got that right!].  But, you may say, you didn't mean it
: to apply to assignations and standard arithmetic?  OK, but then what
: is meant by "standard"?

  plus, minus, times, divide, and power.

We can remember these.  

It's **&!~!$<<2 and the 'cross' in (a cross b) which
would require parentheses because there is no single human convention.

: Are overloaded operators standard as long as
: the formula "looks like" one from the underloaded versions?

Yes.  

"a + b" is sugar for a.plus(b) or plus(a,b) depending on how
the language works.  From then on, ordinary 'overloading' or disambiguation
rules must take over for the proper actual implementation.  That is the
'rules' devolve to whatever the rules are for ordinary named routines.

The goal is to only have ordinary routines at the core, but with extra
superficial syntax.

: If the
: language supports "+" [etc] for complex numbers, how am I supposed to
: know whether "conj" and "arg" are "official" or user-defined in some
: prelude used everywhere in my institution?  If I change the declarations
: of "a" [etc] to be rationals rather than reals, do I have to go round
: adding parentheses all over the place?

No, if you only use standard arithmetic.

(reals on a computer? )

: --
: Andy Walker, Maths Dept., Nott'm Univ., UK.

--

Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/



Fri, 04 Jun 1999 03:00:00 GMT  
 User definable operators

Excuse me, I feel like picking nits today.

Quote:

> I agree that this is better.  But, let's not get carried away.  For
> example, writing "4*a*c" as "(4*a)*c" is an attempt to enforce an
> associativity rule, not a precedence.

The distinction between associativity and precedence is actually
quite artificial, and a consequence of the use of `precedence
levels': an `associativity rule' simply declares precedence
between operators of the same precedence level.

Using precedence levels -- which is in fact an absolute way to
state something relative -- is not necessary.  All that is needed



(illegal combination), or both (associative).  This I call the

Usually, this information is given by assigning each operator a
precedence level and an associativity (left, right, or none).
This system has several limitations however.  For one, it forces
one to declare the relative precedence of operators that may
never be used together.  Further, it does not allow to declare
a/b*c illegal and a*b/c legal; I'd like to do that.  Finally, it
seems a bit awkward that I should state relative precedence
information in terms of absolute levels.

The first and last limitations are avoided by the precedence
system used in Cecil

http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html

There one divides the operators into groups, and one has to
declare explicitly which group takes precedence over which.  This
results in a `precedence lattice.'  Precedence within a group is
decided by associativity declarations.

Quote:
> --
> J. Giles

Groetjes,

 <><

Marnix
--
Marnix Klooster        |  If you reply to this post,



Sun, 06 Jun 1999 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. operator overloading and user definable operators.

2. Definable operators

3. Definable operators

4. Definable operators (was: Problems with Hardware, Languages, and Compilers)

5. User Definable Runtime Report Formater/Wizard-CPD2x

6. User definable field name?

7. user definable browse box

8. User Definable Reports

9. Adding a User Definable Logo to an app

10. User-definable WRITE from F90?

11. User-definable Tk widgets, example code

12. User-definable Tk widgets

 

 
Powered by phpBB® Forum Software