Also, there is currently no location information for the fun_id for an infix
definition, which can move around depending on the size of the left operand,
and the choices made for whitespace.
Good point. So is the field only needed for an equation in infix form? Can we
get rid of fun_infix, and replace with a mabe_infix field in the Match, used
only for (a) FunBind that is (b) infix?
In ordinary expressions I still don’t understand how you distinguish
map ( +) xs
from
map (+ ) xs
Simon
From: Alan & Kim Zimmerman [mailto:[email protected]]
Sent: 23 December 2014 12:16
To: Simon Peyton Jones
Cc: [email protected]
Subject: Re: API Annotatons in a FunBind
On Tue, Dec 23, 2014 at 1:59 PM, Simon Peyton Jones
<[email protected]<mailto:[email protected]>> wrote:
If you do this
• Please make Match into a record (it ought to be already)
Ok
• Put a Note on the fun_id field, with an example like the one you give
Ok
I’m not really sure if Haskell lets you mix infix and prefix notation for the
same function definition, as you have done. The Report is silent on this
question. I’m inclined to think “no”.
Currently a FunBind has a fun_infix field saying whether the definition uses
infix notation. That is fine if “no” above.
If all are prefix or infix, do you still need the new field in Match? Would it
matter only for operators where you want to know where to put the parens? Even
in normal code, how are you distinguishing (+ ) from ( +) or whatever?
The example I gave is an empirical test, it is currently accepted by GHC. The
function as a whole is infix, it is just the alternate representation can be
used for the individual Match definitions.
There are straightforward rules as to whether a given fun_id needs parens or
backquotes. The problem is that with source-to-source conversions the original
must be reproduced exactly, and the code author has freedom to put arbitrary
whitespace between the surrounding parens/backquotes and the actual identifier.
Hence the original fun_id is needed as an anchor for the API annotations.
Also, there is currently no location information for the fun_id for an infix
definition, which can move around depending on the size of the left operand,
and the choices made for whitespace.
In earlier versions of HaRe we were forced to scan through the rich token
stream for a match to pick up this information.
Alan
Simon
From: ghc-devs
[mailto:[email protected]<mailto:[email protected]>] On
Behalf Of Alan & Kim Zimmerman
Sent: 15 December 2014 21:16
To: [email protected]<mailto:[email protected]>
Subject: API Annotatons in a FunBind
After individual FunBinds have been parsed, they are combined in getMonoBind.
In the process, all the original FunBind fun_id's bar one are discarded,
including its location.
This causes a problem for source-to-source conversions of functions such as the
following
(&&& ) [] [] = []
xs &&& [] = xs
( &&& ) [] ys = ys
Where there are compound RdrNames, and each has different spacing.
I am proposing to add a (Maybe (Located id)) to the Match datatype to deal with
this.
data Match id body
= Match
Maybe (Located id) -- fun_id in subsequent function equations
[LPat id] -- The patterns
(Maybe (LHsType id)) -- A type signature for the result of the match
-- Nothing after typechecking
(GRHSs id body)
Is this a problem?
Alan
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
