[Haskell-cafe] Automatic fixity allocation for symbolic operators

[Brian Hulley]

Jim Apple wrote:
> On 10/14/06, Brian Hulley <brianh at metamilk.com> wrote:
>> User defined fixities are an enormous problem for
>> an interactive editor
>
> This is the second or third time you've proposed a language change
> based on the editor you're writing. I don't think this is a fruitful
> avenue.


Bertram Felgenhauer wrote:
> Brian Hulley wrote:
>>    infixr 9  .    !!                               9    9.9
> Ouch.
>
> As far as editors go I have little sympathy.


Nicolas Frisby wrote:
> I think it's unreasonable to tie programmers' hands for the sake of
> off-loading rather trivial tasks to editors.


J. Garrett Morris wrote:
> On 10/14/06, Nicolas Frisby <nicolas.frisby at gmail.com> wrote:
>> Perhaps the editor could assume a default precedence ...
> I agree that changing the language in such an unintuitive way -
> breaking existing code in the process - to suit an editor is
> counterproductive and ridiculous.


I feel that the example I used of an interactive editor has somewhat 
eclipsed the purpose of my post, which was basically to see if there is some 
way to arrive at an agreed association of operator precedences with symbolic 
ops such that this would include the current Prelude operators and have some 
kind of intuitive extension to all other possible symbolic ops which would 
respect one's expectations that <*> and <+> should be similar to * and + in 
terms of relative precedence and absolute associativity. After all, if a 
library writer decided to make <*> bind more loosely than <+> one might 
justifiably be frustrated at the apparent inconsistency therefore why not 
just make all this systematic and fixed down to remove these problems?

I had thought perhaps someone might have already made such a "global" 
operator table suitable for functional programming, or some suitable 
algorithm hence the inclusion of my first stumbling attempt at one to try 
and set the ball rolling and at least save someone else several hours of 
hard work going down the same dead end if such it is.

Jim Apple wrote:
>
> There are three ways to change Haskell's lexical structure:
>
> 1. DIY on an open-source compiler/interpreter of your choice.
> 2. Write your own compiler/interpreter.
> 3. Get the change into Haskell''.
>
> If the Haskell'' procedure is like the Haskell' procedure, you'll have
> to do 1 or 2 before you do 3.
>
> It's possible that you will convince someone that your syntax changes
> are worth doing, and that this person will do step 1 or step 2 for
> you, but I don't think so. I haven't done the research myself, but I
> think if you look at the source control logs for Your Favorite Haskell
> Compiler/interpreter and the HCAR, you will find very few
> commits/projects devoted to syntax. I think this is because Haskellers
> are much more interested in semantics.

Afaiu the whole concept of type classes arose because of the desire to avoid 
having to think up different names for related functions and MPTCs were 
suggested by the syntax for single parameter TCs (though I can't remember 
the reference where I think I remember reading this latter point).

>
> Proposing changes that break existing code or segment the Haskell code
> base just doesn't seem like a win.

Since all syntactic and many semantic changes necessarily break existing 
code or segment the code base this would seem to imply that the language 
should not be changed at all or that everything must be backwards 
compatible, so that we have to drag the Achilles heel of original mistakes 
around for all eternity. I'd have thought a solution would be to just use a 
tool to automatically convert existing code to whatever new syntax is found 
to be better, thus allowing the language to be gradually perfected as more 
and more issues are brought to light.

Still I agree with you that a more sensible approach in terms of someone 
like me writing an editor is simply for me to take Haskell as an inspiration 
and incorporate my ideas in it so that any changes can later be seen in 
relation to a (hopefully facilitated and enjoyable) programming experience 
rather than trying to share my ideas piecemeal and insufficiently 
contextualized as they arise.

Thanks to all who replied,
Brian.
-- 
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com