Jim Apple wrote:
On 10/14/06, Brian Hulley <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
