Sam Hughes wrote:
Brian Hulley wrote:
... For example, with the prefix definition of a function with
multiple clauses, the function name at the start of each clause is
already lined up since it must appear at the margin of the current
layout block ...
Or you could have everything be backwards, and use an editor that
right aligns things.
(a -> b) -> [a] -> [b] :: map
[] = [] _ map
x f : xs f map = (x:xs) f map
There is still a reversal here between the order of arguments in the
type signature and the order in the clauses.
Henning Thielemann wrote:
Curried functions like
f :: a -> b -> c
suggest a swapped order of arguments for (->), since 'f' must be
called this way
b a f
Maybe it should be
f :: c <- b <- a
Which would fix this reversal. However there are 2 other kinds of
reversal with postfix notation:
1) Declarations start with a keyword followed by some content whereas
function definitions start with the args followed by the function name
2) Special constructs like "case" or "let" have to start with the
keyword (so the parser knows what kind of thing it is supposed to parse
next and so that the editor knows how to highlight what the user is
typing before the user has finished typing the whole construct), again
making a reversal between built-in constructs and constructs you can
define using higher order functions (eg consider "if" as a user-defined
construct in a postfix language)
I've come to the conclusion that whereas postfix notation is extremely
neat for simple stack-based languages like Forth and PostScript it would
not play well with languages which have a structured syntax since
structured syntax + left to right reading order implies each syntactic
element must start with a "head" followed by content appropriate to that
element, or else recursive descent parsing and/or as-you-type
grammatical highlighting would be impossible, and therefore in terms of
function application, the "head" must of course be the function itself
hence Prefix is the only solution.
Jonathan's comparison to natural languages made me think of it this way:
x `plus` y === [Subject] [Verb] [Object]
x .plus(y) === [Subject] [Verb Object]
plus y x === [Verb Object] [Subject]
plus x y === [Verb Subject] [Object]
which illustrates why infix notation feels natural (corresponds to SVO
in English etc), why OOP notation feels natural, why prefix notation is
natural for a functional language (since we are interested primarily in
the transformation not the things being transformed hence we put [VO]
first), and why the desuraging of infix in Haskell/ML is quite simply
just wrong, since the object is now separated from the verb.
ok wrote:
Binary operators have two arguments. That's why sections are needed.
What's wrong with just using (flip)?
I am a bear of very little brain, and I would find it VERY confusing
if the order of arguments in an operator application did not match
the order of arguments in a function call. I can live with
x @ y = (op @)(x, y) (* SML *)
x @ y = (@) x y -- Haskell
but making the orders different would guarantee that I would *always*
be in a muddle about which argument was which. Living with
inconvenient argument orders is vastly easier than with inconsistent
ones.
If you inwardly parse x @ y as [x] [@ y] then the prefix notation is
naturally formed just by putting the "specialized verb" before the
subject instead of after it ie [@ y] [x].
Therefore I think this desugaring, though different from the usual one,
would seem natural as soon as the reason for it was understood (of
course, only if you agree with the reason ;-) ), and the great advantage
of it is that we could write library functions without having to decide
in advance whether or not they should be used with infix sugar.
(Regarding Henning's point about ((->) a) being needed for Reader monads
we could define "type Fun a b = a -> b" and then use (Fun a))
In any case, thanks to all who replied. I've found the discussion very
illuminating and it's certainly helped a lot to clarify the issues for me,
Brian.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
