>>>>> On 6 Jul 1996 16:08:08 GMT, ·······@peoplesparc.cs.berkeley.edu (Richard J. Fateman) said:
rjf> In article <·························@news.edvz.uni-linz.ac.at>,
rjf> jason harris <········@phys.canterbury.ac.nz> wrote:
>> In article <·········@lace.colorado.edu>, ······@mars.Colorado.EDU (Carlos
>> A. Felippa) wrote:
>> .... The use of brackets is
>> normally ambiguous in a "mathematical" setting. For instance if I write on
>> a blackboard or piece of paper:
>>
>> a(b+c)
>>
>> And show it to a mathematically literate person they would commonly
>> understand this to be multiplication. If I instead wrote:
>>
>> f(b+c)
>>
>> They would commonly understand this to be function application. Therefore
>> the use of () in common mathematics is ambiguous.
>>
>> Some languages take the design decision - we are going to force the above
>> to always be function application and any multiplication must be done with
>> *.
rjf> It is not the () that are ambiguous, but the space between the
rjf> first symbol and the ( that is ambiguous.
rjf> To see this, observe that
rjf> sin x has no parentheses, but is usually understood to be function
rjf> application. Whereas
rjf> a x is usually thought to be multiplication.
rjf> The ambiguity is handled more-or-less by context. Mathematicians
rjf> thrive (sometimes unconsciously) on "abuse of notation", and this
rjf> is just one example. What does the space between x and d mean in
rjf> integral x dx ?
In a typed language, you could always resolve the ambiguity on the basis of
types: the concatenation is interpreted as application if the first expression
has functional type, as multiplication if both expressions have a type on
which multiplication is defined. This overloading might pose some
difficulties for the type checker, but that part is not clear to me.
I suspect x dx is part of a different grammar, or at least a different
non-terminal.
[I've added comp.lang.ml to the Newsgroups list so that the types experts can
join the thread.]
--Mitch
Mitchell Wand Internet: ····@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
In article <··········@cantaloupe.srv.cs.cmu.edu>,
Mitchell Wand <····@delphi.ccs.neu.edu> wrote:
>·······@peoplesparc.cs.berkeley.edu (Richard J. Fateman) said:
>rjf> sin x has no parentheses, but is usually understood to be function
>rjf> application. Whereas
>rjf> a x is usually thought to be multiplication.
>rjf> The ambiguity is handled more-or-less by context. Mathematicians
>rjf> thrive (sometimes unconsciously) on "abuse of notation", and this
>rjf> is just one example. What does the space between x and d mean in
>rjf> integral x dx ?
>
>In a typed language, you could always resolve the ambiguity on the basis of
>types: the concatenation is interpreted as application if the first expression
>has functional type, as multiplication if both expressions have a type on
>which multiplication is defined. This overloading might pose some
>difficulties for the type checker, but that part is not clear to me.
It is correct that types can handle some of these cases.
A solution, however, may not be that simple.
Multiplication can involve functional types on the arguments.
It is quite often the case that function composition is viewed as
multiplication on functions (the operator o is not very useful if
one works with signatures and functors). This can be extended to powers
(for instance D^n means application of differentiation n times).
On the other hand, one can implement several domains (such as integers
or reals) as functions. Thus, the problem is not solved by this
technique.
Another (but similar) solution, would be to define application for
different types, thus, application of an integer x to an integer y could
call multiplication. There should be a default (built-in) definition
of function application.
This introduces (uncontrolled) overloading and demands explicit
typing in the general case: but even then there should be strategies
for resolving conflicts.
I don't know how useful can such syntactic sugar be for users, given
all the restrictions it involves.
Philip Santas