From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 15 Oct 92 10:24:06 GMT
	<1992Oct12.200914.22158@CS.ORST.EDU>
	<SPACKMAN.92Oct13190142@disco-sun6.dfki.uni-sb.de>
	<1992Oct14.040754.14470@CS.ORST.EDU>
Reply-To: stephen@acm.org
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken

In article <1992Oct14.040754.14470@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
|In article <SPACKMAN.92Oct13190142@disco-sun6.dfki.uni-sb.de>
|stephen@acm.org writes:
|>In article <1992Oct12.200914.22158@CS.ORST.EDU>
|>crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
|>|[In reference to the Sigma notation]
|>|Any good high school student knows what to do with this.  The problem
|>|is that a good college student will ask "which + operation?"  Since you
|>|didn't specify, I can assume you meant integer addition modulo 17.  See
|>|what I mean by ambiguity?
|>
|>But you're barking up a horse of a different tree here! *That* kind of
|>ambiguity (namely overloading) exists in most programming languages and
|>is handled by type inference, a fairly well explored area by now.
|
|Overloading is _not_ ambiguity.  Overloading in one manner in which a
|context-free language becomes a context-sensitive language.  My point
|is that in a (good) programming language, constructs have a clearly
|defined meaning, and are unambiguous.  Programming languages can handle
|overloading unambiguously because they have formal rules for
|interpreting context.  Mathematical notation has no formal rules for
|resolving ambiguity.  Formal languages are a necessity in programming,
|but are not in mathematics.

Then let's put it this way: this kind of "ambiguity" is perfectly well
formalis*able* as overloading, and thus doesn't count as an outstanding
problem wrt (a) mathematical notation, (b) programming notation, or (c)
programming notations that reflect mathematical convention. The bigger
problem arises in higher-order cases when the type of the type of an
object is in question: these distinctions are too cumbersome to write
out (and too "obvious" in context for a mathematician to care much) and
yet there's no clean apparent way to resolve them.

Suppose for instance you want :sum (sigma) to perform multiplication
instead of addition, over the integers (not too unrespectable a choice
of notation, so long as we multiply by superscripting :-). What are we
going to write,

	... :sum i +> ((*): (+); 1: 0; x i)

??? That looks like total gibberish - * and 1 get declared are
superficially not used (in fact the idea is that they are passed to :sum
implicitly in a manner rather like Common Lisp "special" variables,
except of course that the binding is licensed by the fact that :sum
imposes algebraic restrictions on the range of its range), but is there
any other option? Listing out algebraic models at callpoints is
excessively cumbersome, for sure....
------------------------------------------------------------------------
stephen p spackman                                       stephen@acm.org
------------------------------------------------------------------------