prefix minus and infix resolution
atze at cs.uu.nl
Thu Jul 15 02:54:13 EDT 2010
On 14 Jul, 2010, at 14:22 , Christian Maeder wrote:
> Atze Dijkstra schrieb:
>> I prefer the simplicity of http://hackage.haskell.org/trac/haskell-prime/wiki/NegationBindsTightly over the more involved proposal.
> It's a simple design choice but hard to put into practice for
> compatibility reasons.
It would indeed mean that some programs break, but is that bad? The situation would be similar to the removal of N+K patterns (finding out how many programs are influenced by it, requiring time to phase out, options to turn on/off the feature, etc). Sometimes some cleanup is required to make place for new stuff or to keep things manageable/implementable.
What I want(ed) to emphasize is a concern for the implementability of Haskell as a whole and some sanity checks when considering the addition of feature X:
(1) can some idea not be expressed without X?
In this case 'no' because proper use of parenthesis can express the programmers intention.
(2) can X be explained (and understood) by a 1st year student (or any other language beginner)?
In this case explaining would be more difficult because the student mentally has to perform the same algorithm as the compiler does for X. On top of that the fixity environment must be remembered by the programmer. Using parenthesis is simpler.
Of course such a list can be larger, but this seems relevant here.
> fortran and python have infix power operators that bind more tightly
> than unary minus. The mathematical unusual silent interpretation of "- x
> ^ 2" as "(- x) ^ 2" is the problem (and not that I better should write
> "- (x ^ 2)").
> Other languages i.e. C do not have a power operator!
> Does "- pow x 2" read better? Leave it to users to define "^" and "**"
> as they like?
I like your proposal as it stands, it solves a problem, sure! But like other seemingly innocent and nice solutions it also introduces less evident problems in other areas: for the programmer (must know more), for the implementer (because complexity of the whole is (sort of) quadratic in the number of features). In particular for parsing expressions I believe no compiler fully correctly did implement the (previous, Haskell98) language definition, so from an implementers point of view I prefer to first simplify matters until its implementable.
To make this more concrete, UHC currently implements http://hackage.haskell.org/trac/haskell-prime/wiki/NegationBindsTightly. Not so much as a choice by desire, but out of necessity when debugging the parser for a problem which turned out to be caused by an error in layout parsing triggered by allowing nested do-statements have the same indentation. Simplicity in another part of the language (related to '-') did help to isolate the problem.
> Cheers Christian
> This is also much more clearer, less dependent on context info (i.e.
> the fixity of other operators), thus understandable without inspecting
> the definition of ^ in some other module, and thus also easier to
> explain (to students), and thus lessening the steepness of Haskells
> learning curve somewhat.
>> On 13 Jul, 2010, at 18:38 , Christian Maeder wrote:
>>> I'm asking for support of:
>>> Cheers Christian
>>> Simon Marlow schrieb:
>>>> BTW, here's a related proposal made by Simon PJ earlier this year:
>>>> please consider merging the proposals, or at least clearly identifying
>>>> the differences, if any.
>>> Haskell-prime mailing list
>>> Haskell-prime at haskell.org
>> - Atze -
>> Atze Dijkstra, Department of Information and Computing Sciences. /|\
>> Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
>> Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \
>> Fax : +31-30-2513971 .... | Email: atze at cs.uu.nl ............ / |___\
- Atze -
Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \
Fax : +31-30-2513971 .... | Email: atze at cs.uu.nl ............ / |___\
More information about the Haskell-prime