ANNOUNCE: haskell-src-exts 1.14.0

[Niklas Broberg]

Fellow Haskelleers,

I'm pleased to announce the release of haskell-src-exts-1.14.0!

* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via cabal: cabal install haskell-src-exts
* git repo: https://github.com/haskell-suite/haskell-src-exts

There are two primary reasons for this release, and a number of smaller ones.

The first primary reason is technical: haskell-src-exts 1.14 revamps the Extension datatype, among other things to allow turning extensions on and off (similar to what Cabal allows). We also introduce the concept of a Language, separate from a set of extensions. This is the only backwards-incompatible change in this release.

The second reason is structural: haskell-src-exts is now part of a larger context -- the Haskell Suite. The package has a new home on github (see above), alongside its new cool friends: haskell-names and haskell-packages. There is also a really nice issue tracker there - please help me fill it, or better yet, empty it!

What this release does *not* cover is support for the extensions added to GHC in recent time (with the exceptions of CApiFFI and InterruptibleFFI). Work is in progress on many of these, and there will be another major release not far off in the future.

This release owes many thanks to Roman Cheplyaka in particular, as well as Erik Hesselink, Simon Meier and David Fox. Thanks a lot!

Complete changelog:

1.13.6 --> 1.14.0
===============

* Modernize the Extension datatype in L.H.E.Extension, following the lead
  of Cabal, to allow negative and positive extension modifiers (turning
  features on and off). You need to worry about backwards-incompatible
  changes if any of the following pertains to you:
  1) If you use the Extension datatype programmatically - it has changed
     significantly (see documentation).
  2) The ParseMode record now has one more field
     (baseLanguage :: Language), which might give you a type error.
  3) The behavior of the (extensions :: [Extension]) field has changed,
     which could bite you if you pass custom extensions in the ParseMode.
     Previously, the ParseMode defaulted to the list of extensions accepted
     by Haskell2010, and if you set the list explicitly you would override
     this. Now, the defaults are { baseLanguage = Haskell2010, extensions = [] },
     and explicitly setting a list of extensions will be interpreted on top of
     Haskell2010. See further the documentation for L.H.E.Extension.

* Add support for the 'capi' calling convention. It is enabled with the CApiFFI
  extension. It's been included since GHC 7.4, and advertised since 7.6.

* Add support for the 'interruptible' FFI safety annotation, enabled with
  the InterruptibleFFI extension.

* Give better error message when lexing newline fails. In particular, fix the bug
  when the parser would crash if the file didn't end with a newline.

* Support unboxed tuple expressions and patterns.

* Fix bug in lexing of primitive integer literals in hex or octal notation.

* Disallow negative primitive word literals
  (such as W# (-0x8000000000000000##)).

* Allow phase control for SPECIALIZE pragma.

* Derive Foldable and Traversable instances for all annotated AST types.

* Fix bug with pretty-printing WARNING and DEPRECATED pragmas.


Cheers, Niklas

[Niklas Broberg]

Hi Niklas,

1) My most desired feature would be a syntax tree that does not pluck
pluck comments out and make me treat them separately. It looks much
easier to me to have a fully descriptive tree and (filter . concatMap) /
traverse them out in some way than getting a list of comments and having
to insert them back in the right places myself.
Is that possible?

Sadly not - it's theoretically impossible. The fact that you can put comments literally wherever, means that it's impossible to treat them as nodes of the AST. E.g.

  f {- WHERE -} x = -- WOULD

      -- THESE

      do -- COMMENTS

         a {- END -} <- g x -- UP

         return {- ? -} a

What would be theoretically possible is to define a restricted language that allows comments only in certain well-defined places (cf haddock), and ignores any others. That's a lot of work though, and it's not clear how big the gain is. :-\

A different solution could be to improve the support, through better helper functions, for handling a syntax tree and a list of comments together. That's something I think could be worthwhile.

  

2) Have you considered downloading the all-of-Hackage tarball and
running haskell-src-exts over it to get a benchmark of how much HSE can
already parse of the Haskell code out there?

Considered, yes. Done, no. Would love to see the results :-). The crew at OdHac (Roman, Erik, Simon) ensured that the current version handles all of 'base', which is a good start.

Cheers, Niklas

[Dag Odenhall]

Good stuff!

Is there any way, or plans for a way, to parse a file based on its LANGUAGE pragmas? Last I checked e.g. HSP simply enabled all extensions when parsing, which can cause code to be parsed incorrectly in some cases.

--
You received this message because you are subscribed to the Google Groups "Haskell Server Pages" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-server-p...@googlegroups.com.
To post to this group, send email to haskell-se...@googlegroups.com.
Visit this group at http://groups.google.com/group/haskell-server-pages.
For more options, visit https://groups.google.com/groups/opt_out.

[Niklas Broberg]

HSE parses based on pragmas by default. This can be configured through the ParseMode [1].

But your question regards HSP, Haskell Server Pages, which indeed just enables most extensions by default. Right now there's no way to configure that, but it shouldn't be hard for a skilled programmer to fix. Patches most welcome.  :-)

Cheers, Niklas

[1] http://hackage.haskell.org/packages/archive/haskell-src-exts/1.13.5/doc/html/Language-Haskell-Exts-Parser.html#t:ParseMode

[Niklas Broberg]

> The first primary reason is
> technical: haskell-src-exts
> 1.14 revamps the Extension
> datatype, among other things
> to allow turning extensions on
> and off (similar to what Cabal
> allows). We also introduce the
> concept of a Language,
> separate from a set of
> extensions. This is the only
> backwards-incompatible
> change in this release.

Heads-up: as was pointed out to me, the above is not true. The constructors of the Tuple type have also changed, which means greater risks for breakage. Proceed with this in mind.

Cheers, Niklas

[Dag Odenhall]

Wouldn't it be better to only enable Haskell2010 and XmlSyntax and then rely on LANGUAGE pragmas? I guess optimally we want to add support for -X options to hsx2hs but in the mean time…

BTW I think hsx2hs is in fact affected by these backwards-incompatible changes, and lacks an upper bound on its HSE dependency!

Is hub.darcs.net the official location of the hsx2hs repository these days?

[Niklas Broberg]

On 20 Aug 2013 16:59, "Dag Odenhall" <dag.od...@gmail.com> wrote:
>
> Wouldn't it be better to only
> enable Haskell2010 and
> XmlSyntax and then rely on
> LANGUAGE pragmas? I guess
> optimally we want to add
> support for -X options to
> hsx2hs but in the mean time…

Sounds reasonable to me. Jeremy, any objections?

> BTW I think hsx2hs is in fact
> affected by these backwards-
> incompatible changes, and
> lacks an upper bound on its
> HSE dependency!

Ouch. Will fix then, pending discussion on the above.

> Is hub.darcs.net the official
> location of the hsx2hs
> repository these days?

Yup.

Cheers, Niklas

[Jeremy Shaw]

On Tue, Aug 20, 2013 at 12:42 PM, Niklas Broberg <niklas....@gmail.com> wrote:

On 20 Aug 2013 16:59, "Dag Odenhall" <dag.od...@gmail.com> wrote:
>
> Wouldn't it be better to only
> enable Haskell2010 and
> XmlSyntax and then rely on
> LANGUAGE pragmas? I guess
> optimally we want to add
> support for -X options to
> hsx2hs but in the mean time…

Sounds reasonable to me. Jeremy, any objections?

For the executable hsx2hs that sounds good. Not sure about the hsx quasi-quoter..

- jeremy 

[Dag Odenhall]

Ah, that's a good point. A hack could be to use location :: Q Loc and scan the containing source file for LANGUAGE pragmas. If HSE is used for that part it would mean the QQ doesn‘t let you work around issues when HSE fails to parse the full source file, though. Also, it would still need to fall back to some default if the file can’t be read (such as when used from ghci). It's a rather gross hack all together, but no worse than what QuickCheck does in its All module.