On 21/07/2009 09:14, Simon Peyton-Jones wrote:
Yes, but a lot of the API remains somewhat accidental... so I don't want to tie
us in to full backward compat.
Whenever possible, let's retain a deprecated old type or function; but if it's
difficult or inconvenient, let's not.
Agreed.
Concerning SrcLoc etc, we did indeed start with SrcLoc, and then moved to
SrcSpan later. I would be fine with expunging all SrcLocs in favour of
SrcSpans.
There are a few places where we are using SrcLoc and we should really be
using SrcSpan (search for nameSrcLoc). However, we probably don't want
to get rid of it completely: a SrcLoc is useful in the sense that it is
the beginning and end point of a SrcSpan.
We could rename SrcLoc to SrcPoint, perhaps.
Cheers,
Simon
Simon
| -----Original Message-----
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
| Behalf Of Simon Marlow
| Sent: 21 July 2009 09:05
| To: Isaac Dupree
| Cc: cvs-ghc@haskell.org
| Subject: Re: SrcLoc/SrcSpan/Located naming
|
| We're at the stage where the GHC API is beginning to settle down a bit,
| so it might be a good idea to keep backwards compatibility where
| possible. If we rename things, we can leave the old names in, but
| DEPRECATED, for one release.
|
| Cheers,
| Simon
|
| On 20/07/2009 19:51, Isaac Dupree wrote:
|> Do we make any attempt to keep the GHC API consistent between major
|> releases, or is the policy generally just to make any naming changes
|> that we find fitting for GHC's purposes?
|>
|> -Isaac
|>
|>
|> Thomas Schilling wrote:
|>> I think the inconsistencies are mostly because SrcSpan was added
|>> later. Patches to improve the problematic cases would (most likely)
|>> be welcome.
|>>
|>> 2009/7/20 Isaac Dupree<m...@isaac.cedarswampstudios.org>:
|>>> is a confusing mess!
|>>> The most important module is named SrcLoc, which is acceptable.
|>>> It contains three types,
|>>> SrcLoc,
|>>> SrcSpan, which approximately is two SrcLocs (begin and end),
|>>> and Located, which combines a SrcSpan (not a SrcLoc!) with an arbitrary
|>>> other type.
|>>>
|>>> In practice (well, in my case at least) you almost always want a
|>>> SrcSpan and
|>>> not a SrcLoc.
|>>> Many of the functions on SrcLoc have "srcLoc" in their names, which
|>>> is good.
|>>>
|>>> However, so do many of the functions on Located-and-SrcSpan, which is
|>>> terrible. It gets a little worse when you combine with the (fairly
|>>> sensibly
|>>> named functions) at Name.NamedThing
|>>> noLoc, getLoc, addCLoc, combineLocs work on Locateds.
|>>> noSrcLoc, getSrcLoc, work on SrcLocs. Instead, noSrcSpan and
|>>> getSrcSpan are
|>>> the ones you want.
|>>>
|>>> Okay it's not quite as bad as I thought. You want to avoid a function
|>>> iff
|>>> it contains the whole phrase "srcLoc". But I still got confused a lot of
|>>> times. I wonder if we could rename something so that SrcLoc and Located
|>>> don't have the same word-part in them, because they aren't really
|>>> closely
|>>> enough related? Even if it's just renaming "SrcLoc" to "SrcSpot" or
|>>> something.
|>>>
|>>> It's also annoying that Name.getSrcSpan doesn't work on Locateds
|>>> (inevitable
|>>> I guess since it's type-different from NamedThing), but the function you
|>>> have to use instead is called getLoc, even though it also produces a
|>>> SrcSpan
|>>> (only the argument-type is different). Hmm.
|>>>
|>>> -Isaac
|>>>
|>>> _______________________________________________
|>>> Cvs-ghc mailing list
|>>> Cvs-ghc@haskell.org
|>>> http://www.haskell.org/mailman/listinfo/cvs-ghc
|>>>
|>>
|>>
|>>
|>
|> _______________________________________________
|> Cvs-ghc mailing list
|> Cvs-ghc@haskell.org
|> http://www.haskell.org/mailman/listinfo/cvs-ghc
|
| _______________________________________________
| Cvs-ghc mailing list
| Cvs-ghc@haskell.org
| http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
