Niklas Broberg | 20 Aug 10:15 2013
Picon

ANNOUNCE: haskell-src-exts 1.14.0

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
_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Niklas Hambüchen | 20 Aug 10:48 2013

Re: ANNOUNCE: haskell-src-exts 1.14.0

Nice!

I hope that haskell-suite will eventually become awesome and solve most
of our automation-on-Haskell-code needs.

Two questions:

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?

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?

Thanks!
Niklas Broberg | 20 Aug 11:19 2013
Picon

Re: ANNOUNCE: haskell-src-exts 1.14.0

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
_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Niklas Hambüchen | 20 Aug 12:00 2013

Re: ANNOUNCE: haskell-src-exts 1.14.0

On 20/08/13 18:19, Niklas Broberg wrote:
> 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

Oh, I see what you mean.

I guess what I mean instead is:

* A lex list that contains *everything*, including comments and white space

* A full syntax tree of which each node points to (indexes) a position
in the lex list to get the precise original position; comments in
between two nodes can then be determined and more easily played with
because they are between their positions in the lex list

* An abstract syntax tree that has whitespace and comments discarded
(what HSE has now)
Tommy Thorn | 21 Aug 07:09 2013
Picon

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

+1

When I worked on the font-lock support for haskell-mode, the irony
of trying to approximate the classification that the hugs/ghc/whatnot parser
was already doing wasn't lost on me.  I still would like to tap into more
of the knowledge generated and lost in the compiler:

- A list of all tokens (source position, span, classification). Comments are conventionally
  treated as whitespace, but it's not very hard to capture them before dropping
  them.

- All identifiers can be classified into def and use with enough lexical scope information
  to get from use to def and from def to all uses. Take this one step further and type
  information can be stored with the def.

- Tokens should be mapped to the underlying AST if possible, and vice versa.

I'm sure there's more, but with this, one could build an awesome editor, code navigator.

I think it's possible, but I don't have time to work on it, alas. I'd like suggestions as to
to realize this.

Tommy -- ponding hacking the parser combinators to keep this information.

On Aug 20, 2013, at 03:00 , Niklas Hambüchen <mail <at> nh2.me> wrote:

> On 20/08/13 18:19, Niklas Broberg wrote:
>> 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
> 
> Oh, I see what you mean.
> 
> I guess what I mean instead is:
> 
> * A lex list that contains *everything*, including comments and white space
> 
> * A full syntax tree of which each node points to (indexes) a position
> in the lex list to get the precise original position; comments in
> between two nodes can then be determined and more easily played with
> because they are between their positions in the lex list
> 
> * An abstract syntax tree that has whitespace and comments discarded
> (what HSE has now)
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Sean Leather | 20 Aug 12:15 2013
Picon

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

On Tue, Aug 20, 2013 at 11:19 AM, Niklas Broberg wrote:
On Tue, Aug 20, 2013 at 10:48 AM, Niklas Hambüchen wrote:
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.

See:

Nikolaos Bezirgiannis, Johan Jeuring and Sean Leather. Usage of Generic Programming on Hackage - Experience Report. WGP 2013.

Unfortunately, it seems we don't mention which version of haskell-src-exts is used for the article. But I'm certain it's 1.13.*, probably 1.13.5.

Regards,
Sean
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
AlanKim Zimmerman | 20 Aug 13:02 2013
Picon

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

This is not using haskell-src-exts, but the Haskell Refactorer has a structure to keep a parallel tree of tokens indexed by SrcSpan, which attempts to allocate comments to the appropriate point. 

See https://github.com/alanz/HaRe/blob/master/src/Language/Haskell/Refact/Utils/TokenUtils.hs. It does not make use of the AST itself, so may be usable with haskell-src-exts

Alan




On Tue, Aug 20, 2013 at 11:19 AM, Niklas Broberg <niklas.broberg <at> gmail.com> wrote:
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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tommy Thorn | 21 Aug 07:16 2013
Picon

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

On Aug 20, 2013, at 02:19 , Niklas Broberg <niklas.broberg <at> gmail.com> wrote:
> 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

"Theoretically impossible". I wouldn't say so. In fact, a system like this
was implemented for BETA in the mid 1980'es [1].  The comments where
attached to the nearest AST node in an expanded AST.  While not _perfect_,
it worked pretty well. Granted, it likely is much harder to do for Haskell than
BETA, but impossible is a strong word.

Tommy
[1] http://www.cs.au.dk/~beta/doc/mjolner-overview/mjolner-overview.pdf
Johannes Waldmann | 30 Nov 09:15 2006
Picon

Re: [Haskell] ANNOUNCE: Visual Haskell prerelease 0.2


> > Not only the interfaces [Visual Studio vs. Eclipse]
> > are completely different, but an entirely new
> > set of interoperability problems would need to be solved. ...

I still don't see what would be the fundamental difference.

(Except perhaps that the Eclipse interfaces are easily available
and well documented so it is at least possible to describe
the interface problems...)

The main advantage (Visual Haskell  over eclipsefp) at the moment
is that VH uses incremental (on-the-fly) typechecking/compilation
while eclipsefp calls the compiler for whole modules?

What source text transformations (refactorings) does VH support?

Best regards,
-- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ----
http://www.imn.htwk-leipzig.de/~waldmann/ -------
Thiago Arrais | 30 Nov 12:58 2006
Picon

Re: Re: [Haskell] ANNOUNCE: Visual Haskell prerelease 0.2

On 11/30/06, Johannes Waldmann <waldmann <at> imn.htwk-leipzig.de> wrote:
> The main advantage (Visual Haskell  over eclipsefp) at the moment
> is that VH uses incremental (on-the-fly) typechecking/compilation
> while eclipsefp calls the compiler for whole modules?

I would say this is one of the greatest advantages of VH, don't know if it is
the main one, but it surely is an advantage. I wonder how VH achieves that.
I imagine it manages to run GHC (it uses GHC, right?) inside the .Net VM
or at least access it through some programmatic interface using some kind
of native/VM data conversion. GHC code (and not VH code) do the
typechecking/compilation tricks. Is that right?

Eclipse is Java and I am pretty sure we can do something similar with it
and we actually did something like the second approach prior to version
0.9.1, but just for source code parsing. What do we need for that?

Cheers,

Thiago Arrais
--

-- 
Mergulhando no Caos - http://thiagoarrais.wordpress.com
Pensamentos, idéias e devaneios sobre desenvolvimento de software e
tecnologia em geral
Krasimir Angelov | 30 Nov 13:41 2006
Picon

Re: Re: [Haskell] ANNOUNCE: Visual Haskell prerelease 0.2

VSHaskell isn't interfacing with .NET but is a COM server written in
Haskell. The VStudio IDE is actually implemented in C but is using COM
as an interface to the various plugins. That way you can implement the
plugin in C++/.NET/Haskell or what ever you want. For Eclipse you need
a bridge between JVM and Haskell. In addition you have find some way
to build .so library for Linux.

Cheers,
  Krasimir

On 11/30/06, Thiago Arrais <thiago.arrais <at> gmail.com> wrote:
> On 11/30/06, Johannes Waldmann <waldmann <at> imn.htwk-leipzig.de> wrote:
> > The main advantage (Visual Haskell  over eclipsefp) at the moment
> > is that VH uses incremental (on-the-fly) typechecking/compilation
> > while eclipsefp calls the compiler for whole modules?
>
> I would say this is one of the greatest advantages of VH, don't know if it is
> the main one, but it surely is an advantage. I wonder how VH achieves that.
> I imagine it manages to run GHC (it uses GHC, right?) inside the .Net VM
> or at least access it through some programmatic interface using some kind
> of native/VM data conversion. GHC code (and not VH code) do the
> typechecking/compilation tricks. Is that right?
>
> Eclipse is Java and I am pretty sure we can do something similar with it
> and we actually did something like the second approach prior to version
> 0.9.1, but just for source code parsing. What do we need for that?
>
> Cheers,
>
> Thiago Arrais
> --
> Mergulhando no Caos - http://thiagoarrais.wordpress.com
> Pensamentos, idéias e devaneios sobre desenvolvimento de software e
> tecnologia em geral
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Bayley, Alistair | 30 Nov 15:07 2006
Picon

RE: Re: [Haskell] ANNOUNCE: Visual Haskell prerelease0.2

(not sure if this is the best place for questions about VisualHaskell)

I've just installed VisualHaskell, and I've noticed that some of the
hierarchical libraries are missing/hidden:
 - Control.Monad.State (and other chunks of the Control.Monad hierarchy,
like Control.Monad.Error/Identity/List/Trans)
 - Test.HUnit (in fact Test.* is gone)

and I'm sure there's plenty more missing.

?

Alistair
*****************************************************************
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*****************************************************************
Krasimir Angelov | 30 Nov 18:07 2006
Picon

Re: Re: [Haskell] ANNOUNCE: Visual Haskell prerelease0.2

Hi Alistair,

Visual Haskell is packaged with just the core libraries.
Control.Monad.* modules are part of mtl and Test.HUnit is part of
HUnit which aren't core libraries and aren't installed. It was long
time ago when I was using the official Windows installer for last
time. Is it still packaged with all libraries?

Krasimir

On 11/30/06, Bayley, Alistair <Alistair_Bayley <at> invescoperpetual.co.uk> wrote:
> (not sure if this is the best place for questions about VisualHaskell)
>
> I've just installed VisualHaskell, and I've noticed that some of the
> hierarchical libraries are missing/hidden:
>  - Control.Monad.State (and other chunks of the Control.Monad hierarchy,
> like Control.Monad.Error/Identity/List/Trans)
>  - Test.HUnit (in fact Test.* is gone)
>
> and I'm sure there's plenty more missing.
>
> ?
>
> Alistair
> *****************************************************************
> Confidentiality Note: The information contained in this message,
> and any attachments, may contain confidential and/or privileged
> material. It is intended solely for the person(s) or entity to
> which it is addressed. Any review, retransmission, dissemination,
> or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient(s) is
> prohibited. If you received this in error, please contact the
> sender and delete the material from any computer.
> *****************************************************************
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Bayley, Alistair | 1 Dec 10:13 2006
Picon

RE: ANNOUNCE: Visual Haskell prerelease0.2

> From: Krasimir Angelov [mailto:kr.angelov <at> gmail.com] 
> 
> Visual Haskell is packaged with just the core libraries.
> Control.Monad.* modules are part of mtl and Test.HUnit is part of
> HUnit which aren't core libraries and aren't installed. It was long
> time ago when I was using the official Windows installer for last
> time. Is it still packaged with all libraries?
> 
> Krasimir

It certainly is. Is it possible to configure VisualHaskell so that it
uses the existing ghc-6.6 installation, rather than it's own?

Or is there some way I can copy over the HS*.o, libHS*.a, and libHS*_p.a
files and register them? Comparing the installations indicates that
ghc-6.6 has the following packages, which Visual Haskell lacks (I'm just
comparing the HS*.o files in c:\ghc\ghc-6.6 and C:\Program Files\Visual
Haskell):

cgi
fgl
GLUT (and GLUT_cbits)
haskell-src
html
HUnit
mtl
network
objectio
OpenGL (and OpenGL_cbits)
QuickCheck
readline
time
xhtml

Alistair
*****************************************************************
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*****************************************************************
shelarcy | 1 Dec 11:43 2006
Picon

Re: ANNOUNCE: Visual Haskell prerelease0.2

Hi Alistair,

On Fri, 01 Dec 2006 18:13:45 +0900, Bayley, Alistair <Alistair_Bayley <at> invescoperpetual.co.uk> wrote:
> It certainly is. Is it possible to configure VisualHaskell so that it
> uses the existing ghc-6.6 installation, rather than it's own?

I think you can install extra libraries by cabal (and
sometime you also need MSYS and MSYS Developer Tool Kit
(autotools) for configuration).

> cgi
> fgl
> GLUT (and GLUT_cbits)
> haskell-src
> html
> HUnit
> mtl
> network
> objectio
> OpenGL (and OpenGL_cbits)
> QuickCheck
> readline
> time
> xhtml

And I proposed to bundle OpenAL and ALUT packages.

http://www.haskell.org/pipermail/glasgow-haskell-users/2006-October/011283.html

These packages are in extra libraries. And I think that -
OpenAL library is LGPL and OpenAL package is BSD3, so
there is no reason avoiding to include this package.

OpenAL site notices that OpenAL can become Creative's
licese when using on Creative Device.

http://www.openal.org/platforms.html

But if you look at Creative's OpenAL SDK header files, you
can find al.h and eft.h are LGPL. So I think we can use
OpenAL library under LGPL on Windows, if we don't use
Creative specific extentions.

http://opensource.creative.com/pipermail/openal/2004-March/007309.html

Best Reagrds,

--

-- 
shelarcy <shelarcy    capella.freemail.ne.jp>
http://page.freett.com/shelarcy/
Krasimir Angelov | 1 Dec 11:54 2006
Picon

Re: ANNOUNCE: Visual Haskell prerelease0.2

I will build these libraries for the final installer.

On 12/1/06, shelarcy <shelarcy <at> gmail.com> wrote:
> Hi Alistair,
>
> On Fri, 01 Dec 2006 18:13:45 +0900, Bayley, Alistair <Alistair_Bayley <at> invescoperpetual.co.uk> wrote:
> > It certainly is. Is it possible to configure VisualHaskell so that it
> > uses the existing ghc-6.6 installation, rather than it's own?
>
> I think you can install extra libraries by cabal (and
> sometime you also need MSYS and MSYS Developer Tool Kit
> (autotools) for configuration).
>
> > cgi
> > fgl
> > GLUT (and GLUT_cbits)
> > haskell-src
> > html
> > HUnit
> > mtl
> > network
> > objectio
> > OpenGL (and OpenGL_cbits)
> > QuickCheck
> > readline
> > time
> > xhtml
>
> And I proposed to bundle OpenAL and ALUT packages.
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2006-October/011283.html
>
> These packages are in extra libraries. And I think that -
> OpenAL library is LGPL and OpenAL package is BSD3, so
> there is no reason avoiding to include this package.
>
> OpenAL site notices that OpenAL can become Creative's
> licese when using on Creative Device.
>
> http://www.openal.org/platforms.html
>
> But if you look at Creative's OpenAL SDK header files, you
> can find al.h and eft.h are LGPL. So I think we can use
> OpenAL library under LGPL on Windows, if we don't use
> Creative specific extentions.
>
> http://opensource.creative.com/pipermail/openal/2004-March/007309.html
>
> Best Reagrds,
>
> --
> shelarcy <shelarcy    capella.freemail.ne.jp>
> http://page.freett.com/shelarcy/
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Peter Verswyvelen | 31 Jan 18:09 2008
Picon

Re: RE: [Haskell] Announce: Yi 0.3

Is YI also an IDE for creating Haskell code? I guess it's not, it's "just" a text editor right?

I mean, if it talks to GHC directly, it could neatly take over some tricks used in Visual Haskell (on the fly
type inference, good completion, etc), only much much easier (without the COM layer, directly in Haskell).
Henrique Ferreiro García | 22 Apr 00:12 2008
Picon

Re: [Haskell] ANNOUNCE: Galois web libraries for Haskell released

>   * feed
>         Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds

Great! I had planned to make a feed reader using gtk2hs and this was
exactly what I was waiting for.

I have just seen that it is released as BSD3. Anyone knows if is there
any problem in making use of it to develop a GPLv3 application?

--

-- 
Henrique Ferreiro García <hferreiro <at> udc.es>
Don Stewart | 22 Apr 00:29 2008

Re: Re: [Haskell] ANNOUNCE: Galois web libraries for Haskell released

hferreiro:
> >   * feed
> >         Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds
>         
> Great! I had planned to make a feed reader using gtk2hs and this was
> exactly what I was waiting for.
> 
> I have just seen that it is released as BSD3. Anyone knows if is there
> any problem in making use of it to develop a GPLv3 application?

They're simply BSD licensed, as most Haskell libraries are, meaning you
can freely mix the code with GPLd works.

-- Don
Alberto G. Corona | 2 Nov 15:02 2008
Picon

Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1

I uploadad RefSerialize  to  Hackage .

Read, Show and Data.Binary do not check for repeated references to the same data address. As a result, the data is serialized multiple times when serialized. This is a waste of space in the filesystem  and  also a waste of serialization time. but the worst consequence is that, when the serialized data is read, it allocates multiple copies in memory for the same object referenced multiple times. Because multiple referenced data is very typical in a pure language such is Haskell, this means that the resulting data loose the beatiful economy of space and processing time that referential transparency permits.
                    
This package allows the serialization and deserialization of large data structures without duplication of data, with
the result of optimized performance and memory usage. It is also useful for debugging purposes.
                    
There are automatic derived instances for instances of Read/Show, lists and strings. the deserializer contains a almos complete set of Parsec.Token parsers for deserialization.
                    
 Every instance of Show/Read is also a instance of Data.RefSerialize
                    
 The serialized string has the form "expr( var1, ...varn) where  var1=value1,..valn=valueN " so that the
string can ve EVALuated.
                    
 See demo.hs and tutorial. I presumably will add a entry in haskell-web.blogspot.com
                    
                     To develop: -derived instances for Data.Binary
                                 -serialization to/from ByteStings

I wrote this module because I needed to serialize lists of verisions of the same data with slight modifications between each version.


This is a short tutorial (in tutorial.txt)



runW applies showp, the serialization parser of the instance Int for the RefSerialize class

Data.RefSerialize>let x= 5 :: Int
Data.RefSerialize>runW $ showp x
"5"

every instance of Read and Show is an instance of RefSerialize.

rshowp is derived from showp, it labels the serialized data with a variable name

Data.RefSerialize>runW $ rshowp x
" v8 where {v8= 5; }"

Data.RefSerialize>runW $ rshowp [2::Int,3::Int]
" v6 where {v6= [ v9,  v10]; v9= 2; v10= 3; }"

while showp does a normal show serialization

Data.RefSerialize>runW $ showp [x,x]
"[5, 5]"

rshowp variables are serialized memory references: no piece of data that point to the same addrees is serialized but one time

Data.RefSerialize>runW $ rshowp [x,x]
" v9 where {v6= 5; v9= [ v6, v6]; }"

This happens recursively

Data.RefSerialize>let xs= [x,x] in str = runW $ rshowp [xs,xs]
Data.RefSerialize>str
" v8 where {v8= [ v10, v10]; v9= 5; v10= [ v9, v9]; }"

the rshowp serialized data is read with rreadp. The showp serialized data is read by readp

Data.RefSerialize>let xss= runR rreadp str :: [[Int]]
Data.RefSerialize>print xss
[[5,5],[5,5]]

this is the deserialized data

the deserialized data keep the references!! pointers are restored! That is the whole point!

Data.RefSerialize>varName xss !! 0 == varName xss !! 1
True


rShow= runW rshowp
rRead= runR rreadp

Data.RefSerialize>rShow x
" v11 where {v11= 5; }"


In the definition of a referencing parser non referencing parsers can be used and viceversa. Use a referencing parser
when the piece of data is being referenced many times inside the serialized data.

by default the referencing parser is constructed by:

rshowp= insertVar showp
   rreadp= readVar readp
but this can be redefined. See for example the instance of [] in RefSerialize.hs

This is an example of a showp parser for a simple data structure.

data S= S Int Int deriving ( Show, Eq)      

instance  Serialize S  where
    showp (S x y)= do
                    xs <- rshowp x  -- rshowp parsers can be inside showp parser
                    ys <- rshowp y
                    return $ "S "++xs++" "++ys
      
      

    readp =  do
                    symbol "S"     -- I included a (almost) complete Parsec for deserialization
                    x <- rreadp   
                    y <- rreadp
                    return $ S x y

there is a mix between referencing and no referencing parser here:    
 
Data.RefSerialize>putStrLn $ runW $ showp $ S x x
S  v23 v23 where {v23= 5; }    


(I corrected some errors in this file here)


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bulat Ziganshin | 2 Nov 15:48 2008
Picon

Re: Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1

Hello Alberto,

Sunday, November 2, 2008, 5:02:10 PM, you wrote:
> Read, Show and Data.Binary do not check for repeated references to
> the same data address.

afair, SerTH does it, using GHC's internal address compare function

what way to check for copies you use?

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
Alberto G. Corona | 3 Nov 22:03 2008
Picon

Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1

actualized to  0.2.3 due to some errors in the cabal description. Sorry, some needed module was not exported.

2008/11/2 Alberto G. Corona <agocorona <at> gmail.com>
I uploadad RefSerialize  to  Hackage .

Read, Show and Data.Binary do not check for repeated references to the same data address. As a result, the data is serialized multiple times when serialized. This is a waste of space in the filesystem  and  also a waste of serialization time. but the worst consequence is that, when the serialized data is read, it allocates multiple copies in memory for the same object referenced multiple times. Because multiple referenced data is very typical in a pure language such is Haskell, this means that the resulting data loose the beatiful economy of space and processing time that referential transparency permits.
                    
This package allows the serialization and deserialization of large data structures without duplication of data, with
the result of optimized performance and memory usage. It is also useful for debugging purposes.
                    
There are automatic derived instances for instances of Read/Show, lists and strings. the deserializer contains a almos complete set of Parsec.Token parsers for deserialization.
                    
 Every instance of Show/Read is also a instance of Data.RefSerialize
                    
 The serialized string has the form "expr( var1, ...varn) where  var1=value1,..valn=valueN " so that the
string can ve EVALuated.
                    
 See demo.hs and tutorial. I presumably will add a entry in haskell-web.blogspot.com
                    
                     To develop: -derived instances for Data.Binary
                                 -serialization to/from ByteStings

I wrote this module because I needed to serialize lists of verisions of the same data with slight modifications between each version.


This is a short tutorial (in tutorial.txt)



runW applies showp, the serialization parser of the instance Int for the RefSerialize class

Data.RefSerialize>let x= 5 :: Int
Data.RefSerialize>runW $ showp x
"5"

every instance of Read and Show is an instance of RefSerialize.

rshowp is derived from showp, it labels the serialized data with a variable name

Data.RefSerialize>runW $ rshowp x
" v8 where {v8= 5; }"

Data.RefSerialize>runW $ rshowp [2::Int,3::Int]
" v6 where {v6= [ v9,  v10]; v9= 2; v10= 3; }"

while showp does a normal show serialization

Data.RefSerialize>runW $ showp [x,x]
"[5, 5]"

rshowp variables are serialized memory references: no piece of data that point to the same addrees is serialized but one time

Data.RefSerialize>runW $ rshowp [x,x]
" v9 where {v6= 5; v9= [ v6, v6]; }"

This happens recursively

Data.RefSerialize>let xs= [x,x] in str = runW $ rshowp [xs,xs]
Data.RefSerialize>str
" v8 where {v8= [ v10, v10]; v9= 5; v10= [ v9, v9]; }"

the rshowp serialized data is read with rreadp. The showp serialized data is read by readp

Data.RefSerialize>let xss= runR rreadp str :: [[Int]]
Data.RefSerialize>print xss
[[5,5],[5,5]]

this is the deserialized data

the deserialized data keep the references!! pointers are restored! That is the whole point!

Data.RefSerialize>varName xss !! 0 == varName xss !! 1
True


rShow= runW rshowp
rRead= runR rreadp

Data.RefSerialize>rShow x
" v11 where {v11= 5; }"


In the definition of a referencing parser non referencing parsers can be used and viceversa. Use a referencing parser
when the piece of data is being referenced many times inside the serialized data.

by default the referencing parser is constructed by:

rshowp= insertVar showp
   rreadp= readVar readp
but this can be redefined. See for example the instance of [] in RefSerialize.hs

This is an example of a showp parser for a simple data structure.

data S= S Int Int deriving ( Show, Eq)      

instance  Serialize S  where
    showp (S x y)= do
                    xs <- rshowp x  -- rshowp parsers can be inside showp parser
                    ys <- rshowp y
                    return $ "S "++xs++" "++ys
      
      

    readp =  do
                    symbol "S"     -- I included a (almost) complete Parsec for deserialization
                    x <- rreadp   
                    y <- rreadp
                    return $ S x y

there is a mix between referencing and no referencing parser here:    
 
Data.RefSerialize>putStrLn $ runW $ showp $ S x x
S  v23 v23 where {v23= 5; }    


(I corrected some errors in this file here)



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jamie | 16 Feb 15:19 2009

Re: [Haskell] ANNOUNCE: first Grapefruit release

On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote:

> [redirecting to haskell-cafe]
> 
> Am Samstag, 14. Februar 2009 23:13 schrieben Sie:
>> Great, does it run well on Windows and Mac platforms in addition to Linux
>> platform which should run fine?
> 
> Actually, I have no idea. ;-)
> 
> Well, Grapefruit is a pure Haskell library without any own binding to C 
> libraries or whatever. For GUI stuff, Grapefruit relies completely on 
> Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t 
> tested it so far. Earlier Grapefruit code was successfully executed on 
> the Windows box of my co-developer.
> 
> On the other hand, Grapefruit is designed to be implemented on top of 
> different toolkits, although currently there is only the Gtk2Hs backend. 
> So if you want to write a backend based on the Win32 API or Cocoa, this 
> would be very welcome. :-)

Great. Well thought out design :)

Other possible backends would be FLTK, GLUI, XBMC/Boxee (for set-top box 
apps) as well Qt and wxWidgets.

I guess backends using Win32 API/Cocoa and FLTK would be the least bloated 
ones.

>> I am planning to create video phone software and I was looking for good 
>> GUI toolkit that supports FRP so it looks like it is right time to use 
>> Grapefruit :)
> 
> This would be really great. Writing applications with Grapefruit gives 
> me useful feedback and pressure for improvement. Note that currently the 
> set of supported widgets is very low but this is likely to change during 
> the next weeks and it should often be very easy to port Gtk2Hs widgets 
> to Grapefruit.

Awesome! I'll be looking forward start using Grapefruit soon! :)

>> Thanks
>>
>>  	Jamie
> 
> Best wishes,
> Wolfgang

         Jamie Clark
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Simon Peyton-Jones | 30 Jun 11:36 2005
Picon

RE: Re: [Haskell] ANNOUNCE: GHC survey results


| If anything I would like to see the Haskell community produce a
Haskell
| front end which was compiler neutral. That would facilitate many
| interesting projects, and that might even help with the need to
support
| new extensions as they come along. There are already some candidates
| floating around, but it seems they are not widely adopted.

Well, "ghc -c -fext-core Foo.hs" is a Haskell front end that produces
System F code ("External Core"), in a file Foo.hcr.  I'm not sure
whether that was what you meant.

However, External Core doesn't seem to have really caught on.   Only 5%
said it was essential, with another 16% saying "nice to have".  I'm sure
there's room to improve the ExtCore route.

Simon
Bernard Pope | 30 Jun 12:10 2005
Picon
Picon

RE: Re: [Haskell] ANNOUNCE: GHC survey results

On Thu, 2005-06-30 at 10:36 +0100, Simon Peyton-Jones wrote:
>  | If anything I would like to see the Haskell community produce a
> Haskell
> | front end which was compiler neutral. That would facilitate many
> | interesting projects, and that might even help with the need to
> support
> | new extensions as they come along. There are already some candidates
> | floating around, but it seems they are not widely adopted.
> 
> Well, "ghc -c -fext-core Foo.hs" is a Haskell front end that produces
> System F code ("External Core"), in a file Foo.hcr.  I'm not sure
> whether that was what you meant.

That is one option, but it wasn't really what I meant. I was thinking of
plain old Haskell library code that implements Lexer, Parser, Desugar,
Type Inference etc. All the bits that happen at the front of a Haskell
compiler. This is what hatchet was supposed to be, and may one day
become.

I've tried in the past to pull the front end off ghc and nhc98 without
much luck. Though it looks like ghc-as-a-library might be just what the
doctor ordered. 

There is also the Programmatica project which seems to do a lot of what
I'm thinking of already. 

> However, External Core doesn't seem to have really caught on.

One problem is that different tools will want different views of the
code. External Core is probably too far away from the original source
for something like hat. 

> Only 5% said it was essential, with another 16% saying "nice to have".  

I would hazard a guess that fewer than 5% of GHC's users are writing
source transformation tools :)

> I'm sure there's room to improve the ExtCore route.

You are right, and to be honest I haven't really given much thought to
that route until now. 

Thanks for the pointer.

Cheers,
Bernie.
Christian Maeder | 30 Jun 12:58 2005
Picon

programatica and haddock

Hi,

Bernard Pope wrote:
> There is also the Programmatica project which seems to do a lot of what
> I'm thinking of already. 

Yes, programatica does a good job. We have switch from using Hatchet to
Programatica (and we may switch to the ghc frontend promised for ghc-6.6
that we would need to extend by formulas for specifications)

Programatica has an alternative way for producing html documentation
from Haskell sources. browse
http://www.cse.ogi.edu/~hallgren/Programatica/tools/pfe.cgi

I would like to see the advantages of both, programatica's documentation
generation and haddock, to be united. (programatica sources don't go
through haddock and have few type signatures that haddock could exploit,
and haddock comments are useless for programatica.)

Unfortunately, the markup used by both programs is different. "{-+" in
programatica and "{- |" in haddock.

Is there any chance that both documentation approaches could be streamlined?

Christian
Thomas Hallgren | 2 Jul 00:54 2005
Picon

Re: programatica and haddock

Hi,

Christian Maeder wrote:

>I would like to see the advantages of both, programatica's documentation
>generation and haddock, to be united. (programatica sources don't go
>through haddock and have few type signatures that haddock could exploit,
>and haddock comments are useless for programatica.)
>
>Unfortunately, the markup used by both programs is different. "{-+" in
>programatica and "{- |" in haddock.
>
>Is there any chance that both documentation approaches could be streamlined?
>  
>

Yes, adding support for Haddock style comment markup to the current HTML 
renderer in the Programatica tools shouldn't be hard, so I might do 
that. If I also add support for generating Haddock style documentation, 
I could take advantage of the fact that the Programatica tools can infer 
types, to compensate for the lack of explicit type signatures in source 
code.

--

-- 
Thomas H
Malcolm Wallace | 30 Jun 12:09 2005
Picon

Re: Re: [Haskell] ANNOUNCE: GHC survey results

"Simon Peyton-Jones" <simonpj <at> microsoft.com> writes:

> | If anything I would like to see the Haskell community produce a Haskell
> | front end which was compiler neutral. That would facilitate many
> | interesting projects, and that might even help with the need to support
> | new extensions as they come along. There are already some candidates
> | floating around, but it seems they are not widely adopted.
> 
> Well, "ghc -c -fext-core Foo.hs" is a Haskell front end that produces
> System F code ("External Core"), in a file Foo.hcr.  I'm not sure
> whether that was what you meant.

External Core is great for some purposes - if you want to play
with new optimisation techniques for instance.  A tracing system
like Hat however wants to have lots of direct linkage back to the
original source code.  External core doesn't bear a terribly close
resemblence to the source - it would require a significant amount
of re-sugaring for presentation to the user of Hat.  It also loses
the actual location of expressions (line/column), although perhaps
GHC-as-library would be better in this respect.

The ideal front-end for a syntax-directed tool like Hat consists solely
of a lexer/parser to an abstract syntax tree, with no desugaring
whatsoever, and no typechecking.  This is essentially what we have
at the moment, but based on nhc98's front-end.  For better coverage
of language extensions, ghc's parser might be preferable.  One can
imagine that other tools would want to plug into the pipeline at
differents points (after desugaring but before type-checking; after
type-checking; etc.)

Regards,
    Malcolm
John Goerzen | 6 Jul 16:59 2005

Re: [Haskell] ANNOUNCE: GHC survey results

On 2005-06-30, Malcolm Wallace <Malcolm.Wallace <at> cs.york.ac.uk> wrote:
> The ideal front-end for a syntax-directed tool like Hat consists solely
> of a lexer/parser to an abstract syntax tree, with no desugaring
> whatsoever, and no typechecking.  This is essentially what we have

This sounds suspiciously like camlp4 in the ocaml world:

  http://pauillac.inria.fr/caml/camlp4/

camlp4 is, for an ocaml tool, a very nice program.  I wish extending
Haskell syntax could be as easy as extending OCaml syntax is.

camlp4 has a separate frontend/backend system.  Standard frontends
include a full standard OCaml parser and a "new syntax" OCaml parser.
The OCaml distribution also includes a Scheme frontend.  Backends
include a binary AST representation and pretty-printed OCaml syntax.

camlp4 can be integrated into the compilation (ocamlc) phase, and is
very slick in many ways.

Learning curve is not one of them.

-- John
Simon Marlow | 13 Sep 15:00 2005
Picon

RE: [Haskell] ANNOUNCE: ghc-src version 0.2.0

On 30 August 2005 12:05, Arthur Baars wrote:

> Daan is right, I wrote a parser for GHC using Doaitse Swierstra's
> parsing combinator library
> (http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/index.html).
> I needed a drop-in replacement for GHC's Happy parser, to make a
> prototype for syntax macros. Syntax Macros allow a programmer to
> extend a language with new syntax. Combinator based parsers parsers
> can be dynamically extended, making them suitable for implementing
> syntax macros.  Unfortunately, I never had time to really finish the
> syntax macro implementation.
> 
> But I did finish the combinator based parser for GHC. I tested it by
> having GHC( with combinator parser) compile itself and all the
> libraries. This took about 10% longer than with the original GHC, so
> in practice its speed is acceptable.

With all due respect, a 10% increase in compile time isn't acceptable at
all!

And when you consider that parsing is less than 10% of compile time
overall (probably much less), a 10% increase represents at least a
factor of 2 in the parser.

I'm not criticising the work at all - far from it, just the notion that
we would consider adding 10% to GHC's compile times "acceptable".  I've
recently  been struggling to shave a few percent off GHC's compile
times, BTW :-)

Cheers,
	Simon
Bulat Ziganshin | 15 Sep 19:36 2005

Re: RE: [Haskell] ANNOUNCE: ghc-src version 0.2.0

Hello Simon,

Tuesday, September 13, 2005, 5:00:17 PM, you wrote:

>> But I did finish the combinator based parser for GHC. I tested it by
>> having GHC( with combinator parser) compile itself and all the
>> libraries. This took about 10% longer than with the original GHC, so
>> in practice its speed is acceptable.

SM> With all due respect, a 10% increase in compile time isn't acceptable at
SM> all!

ability to extend/change Haskell syntax will be very interesting. i
will be glad to see it in some Haskell compiler, at least as
alternative front-end. for example, this give us ability to implement
automatic lifting with `borrow` keyword, dicussed now in Haskell ML

--

-- 
Best regards,
 Bulat                            mailto:bulatz <at> HotPOP.com
Mateusz Kowalczyk | 20 Aug 11:21 2013
Picon

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

On 20/08/13 09:48, Niklas Hambüchen wrote:
> Nice!
> 
> I hope that haskell-suite will eventually become awesome and solve most
> of our automation-on-Haskell-code needs.
> 
> Two questions:
> 
> 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?
> 
+1 for this. There was a small discussion relevant to this on café
recently, if anyone is interested:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/106768

> 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?
> 
> Thanks!
> 

--

-- 
Mateusz K.
Attachment (0x2ADA9A97.asc): application/pgp-keys, 5619 bytes
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
JP Moresmau | 20 Aug 12:02 2013
Picon

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

BuildWrapper has some code that tries to link back the comments to the declaration from the AST generated by haskell-src-exts and the comments. See https://github.com/JPMoresmau/BuildWrapper/blob/master/src/Language/Haskell/BuildWrapper/Src.hs. The unit tests provide some samples: https://github.com/JPMoresmau/BuildWrapper/blob/master/test/Language/Haskell/BuildWrapper/CMDTests.hs#L572-L638. Maybe this can help you.

JP


On Tue, Aug 20, 2013 at 11:21 AM, Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> wrote:
On 20/08/13 09:48, Niklas Hambüchen wrote:
> Nice!
>
> I hope that haskell-suite will eventually become awesome and solve most
> of our automation-on-Haskell-code needs.
>
> Two questions:
>
> 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?
>
+1 for this. There was a small discussion relevant to this on café
recently, if anyone is interested:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/106768

> 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?
>
> Thanks!
>


--
Mateusz K.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
JP Moresmau
http://jpmoresmau.blogspot.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 20 Aug 12:21 2013
Picon

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

On 20/08/13 11:02, JP Moresmau wrote:
> BuildWrapper has some code that tries to link back the comments to the
> declaration from the AST generated by haskell-src-exts and the comments.
> See
> https://github.com/JPMoresmau/BuildWrapper/blob/master/src/Language/Haskell/BuildWrapper/Src.hs.
> The unit tests provide some samples:
> https://github.com/JPMoresmau/BuildWrapper/blob/master/test/Language/Haskell/BuildWrapper/CMDTests.hs#L572-L638.
> Maybe this can help you.
> 
> JP
It certainly look like I might be able to learn from this.

Thank you.
--

-- 
Mateusz K.
Attachment (0x2ADA9A97.asc): application/pgp-keys, 5619 bytes
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dag Odenhall | 20 Aug 12:56 2013
Picon

Re: ANNOUNCE: haskell-src-exts 1.14.0

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.



On Tue, Aug 20, 2013 at 10:15 AM, Niklas Broberg <niklas.broberg <at> gmail.com> wrote:
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

--
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-pages+unsubscribe <at> googlegroups.com.
To post to this group, send email to haskell-server-pages <at> 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.

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Mateusz Kowalczyk | 20 Aug 13:06 2013
Picon

Re: ANNOUNCE: haskell-src-exts 1.14.0

On 20/08/13 11:56, Dag Odenhall wrote:
> 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.
> 
> 

Can you give any examples of such cases? I had recently been asked about
this and could not come up with much at all.

--

-- 
Mateusz K.
Attachment (0x2ADA9A97.asc): application/pgp-keys, 5619 bytes
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dag Odenhall | 20 Aug 14:03 2013
Picon

Re: ANNOUNCE: haskell-src-exts 1.14.0

Well if you enable TemplateHaskell then code like foo$bar gets a new meaning and if you enable Arrows then proc is a reserved keyword, etc etc.



On Tue, Aug 20, 2013 at 1:06 PM, Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> wrote:
On 20/08/13 11:56, Dag Odenhall wrote:
> 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.
>
>

Can you give any examples of such cases? I had recently been asked about
this and could not come up with much at all.


--
Mateusz K.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Broberg | 20 Aug 16:49 2013
Picon

Re: ANNOUNCE: haskell-src-exts 1.14.0

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

On 20 Aug 2013 12:57, "Dag Odenhall" <dag.odenhall <at> gmail.com> wrote:

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.



On Tue, Aug 20, 2013 at 10:15 AM, Niklas Broberg <niklas.broberg <at> gmail.com> wrote:
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

--
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-pages+unsubscribe <at> googlegroups.com.
To post to this group, send email to haskell-server-pages <at> 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.

--
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-pages+unsubscribe <at> googlegroups.com.
To post to this group, send email to haskell-server-pages <at> 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.
_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Dag Odenhall | 20 Aug 16:58 2013
Picon

Re: ANNOUNCE: haskell-src-exts 1.14.0

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?



On Tue, Aug 20, 2013 at 4:49 PM, Niklas Broberg <niklas.broberg <at> gmail.com> wrote:

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

On 20 Aug 2013 12:57, "Dag Odenhall" <dag.odenhall <at> gmail.com> wrote:

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.



On Tue, Aug 20, 2013 at 10:15 AM, Niklas Broberg <niklas.broberg <at> gmail.com> wrote:
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

--
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-pages+unsubscribe <at> googlegroups.com.
To post to this group, send email to haskell-server-pages <at> 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.

--
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-pages+unsubscribe <at> googlegroups.com.
To post to this group, send email to haskell-server-pages <at> 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.

--
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-pages+unsubscribe <at> googlegroups.com.
To post to this group, send email to haskell-server-pages <at> 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.

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Niklas Broberg | 20 Aug 16:54 2013
Picon

Re: ANNOUNCE: haskell-src-exts 1.14.0


> 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

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Gmane