[Haskell-cafe] 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-extshttp://code.haskell.org/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# (-0x8000##)).
* 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-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] 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! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm on macos
Dominic Steinitz dominic at steinitz.org writes: Thanks for all the help everyone :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] 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-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [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. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] 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)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [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 fuuze...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [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. http://www.cs.uu.nl/research/techreps/repo/CS-2013/2013-014.pdf http://hackage.haskell.org/package/gpah 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [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. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.brob...@gmail.comwrote:
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-extshttp://code.haskell.org/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# (-0x8000##)).
* 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+unsubscr...@googlegroups.com.
To post to this group, send email to haskell-server-pa...@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-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [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.brob...@gmail.comwrote:
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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 fuuze...@fuuzetsu.co.ukwrote: 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-element tuple
adam vogt vogt.adam at gmail.com writes: This preprocessor I just threw together doesn't seem to suffers from those issues http://lpaste.net/91967. This kind of approach probably might let you steal T(..) while still allowing `T (..)' to refer to whatever is the original, though I think that would require working with the messier Annotated syntax tree. wow! Adam, thank you. Even copes with multiple nested parens nested parens instance C ((a, b)) c ... == instance C ((a, b)) (OneT.OneTuple (OneT.OneTuple c)) ... AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] wxHaskell mailinglist
On Mon, 19 Aug 2013 20:18:53 +0200, Nathan Hüsken nathan.hues...@posteo.de wrote: Anyone knows what the proper channel for reporting bugs and asking questions about wxHaskell is? The github page https://github.com/wxHaskell/wxHaskell/wiki seems to have issues disabled, and when I post to the wxHaskell user mailinglist, it tells me that the list is moderated. But my post did not get accepted for the last 2 days. Hello Nathan, Bugs and feature requests can be entered at: http://sourceforge.net/p/wxhaskell/_list/tickets The wxHaskell user mailing list is the right channel for questions; if you subscribe to the mailing list[0], your mails will not be moderated. Regards, Henk-Jan van Tuyl [0] https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] wxHaskell mailinglist
Hey, Then something is wrong. When I try to subscribe here: https://lists.sourceforge.net/lists/listinfo/wxhaskell-users I get a mail: Mailman privacy alert, telling me that I am already subscribed. But when I send a mail to: wxhaskell-us...@lists.sourceforge.net I get a mail: Your message to wxhaskell-users awaits moderator approval The reason it is being held: Post to moderated list I am sure I used the same address. Am I confusing something? Or is something wrong with the list? Regards, Nathan On 08/20/2013 02:49 PM, Henk-Jan van Tuyl wrote: On Mon, 19 Aug 2013 20:18:53 +0200, Nathan Hüsken nathan.hues...@posteo.de wrote: Anyone knows what the proper channel for reporting bugs and asking questions about wxHaskell is? The github page https://github.com/wxHaskell/wxHaskell/wiki seems to have issues disabled, and when I post to the wxHaskell user mailinglist, it tells me that the list is moderated. But my post did not get accepted for the last 2 days. Hello Nathan, Bugs and feature requests can be entered at: http://sourceforge.net/p/wxhaskell/_list/tickets The wxHaskell user mailing list is the right channel for questions; if you subscribe to the mailing list[0], your mails will not be moderated. Regards, Henk-Jan van Tuyl [0] https://lists.sourceforge.net/lists/listinfo/wxhaskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.odenh...@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.brob...@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-extshttp://code.haskell.org/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# (-0x8000##)).
* 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+unsubscr...@googlegroups.com.
To post to this group, send email to
haskell-server-pa...@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+unsubscr...@googlegroups.com.
To post to this group, send email to
Re: [Haskell-cafe] 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-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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
-Xoptions 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.brob...@gmail.comwrote:
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.odenh...@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.brob...@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-extshttp://code.haskell.org/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# (-0x8000##)).
* 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+unsubscr...@googlegroups.com.
To post to this group,
Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)
On Tue, Aug 20, 2013 at 6:37 AM, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: On 20/08/2013, at 3:43 AM, Kyle Miller wrote: On Sun, Aug 18, 2013 at 8:04 PM, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: The argument for twos-complement, which always puzzled me, is that the other systems have two ways to represent zero. I never found this to be a problem, not even for bitwise operations, on the B6700. I *did* find abs x 0 succeeding to be a pain in the posterior. (The B6700 had two different tests: 'are these two numbers equal' and 'are these two bit patterns equal'.) I think a better argument for twos complement is that you're just doing all of your computations modulo 2^n (where n is 32 or 64 or whatever), and addition and multiplication work as expected modulo anything. To me, that's not a better argument. These kinds of argument usually come down to a question of framing -- whether pragmatic, philosophical or pedagogical. Let me start with the philosophical It isn't even a _good_ argument. It amounts to saying if you do things wrong, you can justify it by saying you're really doing something else right, and it's the programmer's fault for wanting the wrong thing. This argument works if 'doing something right' is an available option. What if its not? One great thing about the B6700 was that you were guaranteed EITHER the mathematically correct answer in the numbers you were thinking in terms of OR an exception telling you the machine couldn't do what you wanted. When it comes to *applications* programming, the number of times I have *wanted* arithmetic modulo 2^n (in the last 40 years) can be counted on the fingers of one ear. You may call it multiplication work[ing] as expected when the product of two positive numbers comes out negative; I call it a wrong answer. Prelude let tens = 1 : map (*10) tens :: [Int] Prelude take 19 tens [1,10,100,1000,1,10, 100,1000,1, 10,100, 1000,1,10,100, 1000,1,10,100] Prelude [x * x | x - take 19 tens] [1,100,1,100,1,100, 1,100,1,100, 7766279631452241920,1864712049423024128,2003764205206896640, -2537764290115403776,4477988020393345024,5076944270305263616, -8814407033341083648,4003012203950112768,-5527149226598858752] Yes, I know that Haskell has Integer. If I want to do more arithmetic than a bit of simple counting, I like to use it. The gibberish that Int multiplication spewed out above is why. Roughly speaking, there are three ways to handle integer arithmetic: the Lisp way, the Ada way, and the Java way. Lisp just gets it right (think Haskell's Integer type). Java *defines* wrong answers to be right. Ada recognises that sometimes you want modular arithmetic (so it offers you modular types) and sometimes you don't (so it offers you bounded but non-modular types, where overflow is trapped). This issue is really a specific instance of the question: Are computers finite or infinite? If one says finite then the infinite-taped Turing machine has nothing to do with computers If one says infinite then the abstraction we are talking of is unrelated to the boxes on our desks/palmtops. If one recognises that in juggling between these two views -- dare I say a central project for a programmer?? -- we need to stuff an infinite conceptual object into a finite actual one. And in doing so some corners will be cut willy-nilly. So to say Lisp is 'right' because arithmetic does not overflow at machine word size limits misses the fact that it overflows more unpredictably when the machine memory fills out. Lets look at good ol factorial fact 0 = 1 fact n = n * fact (n-1) Now I ran it as fact 100 with signature Int - Int and with Integer - Integer In the first case I got 0 in about 3 seconds In the second... I thought I'd see what happens but after about 2 minutes of the CPU fans maxing out, firefox started giving me alarms about an 'unresponsive script'; I felt my machine had had enough punishment and gave in with C-c! And if that sounds like a unreal argument, consider representing and storing Graham's number. Of course I am arguing philosophically not pragmatically. Philosophically: Graham's number is 'just' a finite number, though a rather obese one Pragmatically: 32-bits is unwise for a bank-balance, 64 should be a bit more safe So coming to the pragmatic and to lisp... I remember a story (maybe apocryphal) about a robot in the MIT(?) lab that did a lot of clever things and then tumbled down the stairs. When asked, the concerned researcher/academic shrugged it off: It was garbage collecting If the robot had been programmed in C its real-time behavior would have been sturdier though its integer overflow properties would have been flimsier. More pragmatically, its good to remember
Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)
Richard A. O'Keefe o...@cs.otago.ac.nz writes: I think a better argument for twos complement is that you're just doing all of your computations modulo 2^n (where n is 32 or 64 or whatever), and addition and multiplication work as expected modulo anything. To me, that's not a better argument. It isn't even a _good_ argument. It amounts to saying if you do things wrong, you can justify it by saying you're really doing something else right, and it's the programmer's fault for wanting the wrong thing. Not only that, but in Haskell, you don't really know 'n', it is only specified to be at least 23, or something like that. Which basically means that any code that relies on this behaviour without rigorously checking it basically is wrong. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling stringable with GHC 7.0.4
I took the liberty of implementing this fix and uploading
stringable-0.1.1.1 to HackageDB. I tested it on GHC 7.0.4 (you know,
shipped with the cutting-edge Fedora distribution one year ago, but
ancient and no longer to be bothered with by Haskell standards :-) and
on 7.6.2.
-k
Ketil Malde ke...@malde.org writes:
Hi,
---
I don't think FlexibleInstances works with this GHC, I get:
% cabal install --prefix=$G stringable
Resolving dependencies...
Configuring stringable-0.1.1...
Building stringable-0.1.1...
Preprocessing library stringable-0.1.1...
[1 of 1] Compiling Data.Stringable ( Data/Stringable.hs,
dist/build/Data/Stringable.o )
Data/Stringable.hs:54:10:
Illegal instance declaration for `Stringable String'
(All instance types must be of the form (T t1 ... tn)
where T is not a synonym.
Use -XTypeSynonymInstances if you want to disable this.)
In the instance declaration for `Stringable String'
---
I changed the first line of Data/Stringable.hs to:
{-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
and then it compiled. Is there any reason not to retain the TSI pragma?
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] monoids induced by Applicative/Alternative/Monad/MonadPlus?
Dear Haskellers, are these monoids defined somewhere? import Control.Applicativeimport Data.Monoid newtype AppMonoid m a = AppMonoid (m a)instance (Monoid a, Applicative m) = Monoid (AppMonoid m a) where mempty = AppMonoid $ pure mempty mappend (AppMonoid x) (AppMonoid y) = AppMonoid $ mappend $ x * y-- With the () monoid for `a` this becames the monoid of effects. newtype AltMonoid m a = AltMonoid (m a)instance Alternative m = Monoid (AltMonoid m a) where mempty = AltMonoid empty mappend (AltMonoid x) (AltMonoid y) = AltMonoid $ x | y (and similarly for Monad/MonadPlus, until they become subclasses of Applicative?) Best regards, Petr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] wxHaskell mailinglist
On Tue, 20 Aug 2013 15:24:41 +0200, Nathan Hüsken nathan.hues...@posteo.de wrote: Hey, Then something is wrong. When I try to subscribe here: https://lists.sourceforge.net/lists/listinfo/wxhaskell-users I get a mail: Mailman privacy alert, telling me that I am already subscribed. But when I send a mail to: wxhaskell-us...@lists.sourceforge.net I get a mail: Your message to wxhaskell-users awaits moderator approval The reason it is being held: Post to moderated list I am sure I used the same address. Am I confusing something? Or is something wrong with the list? It seems that there is something wrong with the settings of the mailing list; I cc-ed the mailing list owners. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What am I missing? Cycle in type synonym declarations
This file gives me the error Cycle in type synonym declarations Can
anyone tell me why? I'm just trying to write a function to create a
type that is a FooT with the type parameter fixed.
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH (Q, Dec, TypeQ)
data FooT a = FooT a
foo :: TypeQ - Q [Dec]
foo t = [d| type Bar = FooT $t |]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What am I missing? Cycle in type synonym declarations
Hi,
In this case, you have two 'FooT' names: one is the Type and the other
is the Constructor. Perhaps Template Haskell is capturing the wrong
one inside the quote (probably the constructor). When you have name
shadowing, you should always use a lookup function. You can find
these lookup functions in the Template Haskell library.
In the meantime, just for a quick test, you can try to change the name
of the constructor to something else to avoid capturing, and you can
see if the rest of the code works.
Jose
On Tue, Aug 20, 2013 at 02:00:29PM -0700, David Fox wrote:
This file gives me the error Cycle in type synonym declarations Can
anyone tell me why? I'm just trying to write a function to create a
type that is a FooT with the type parameter fixed.
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH (Q, Dec, TypeQ)
data FooT a = FooT a
foo :: TypeQ - Q [Dec]
foo t = [d| type Bar = FooT $t |]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What am I missing? Cycle in type synonym declarations
On Tue, Aug 20, 2013 at 5:00 PM, David Fox d...@seereason.com wrote:
This file gives me the error Cycle in type synonym declarations Can
anyone tell me why? I'm just trying to write a function to create a
type that is a FooT with the type parameter fixed.
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH (Q, Dec, TypeQ)
data FooT a = FooT a
foo :: TypeQ - Q [Dec]
foo t = [d| type Bar = FooT $t |]
Hi David,
That's strange considering you can accomplish the same thing with:
foo t = fmap (:[]) $ tySynD (mkName Bar) [] [t| FooT $t |]
Bugs like http://ghc.haskell.org/trac/ghc/ticket/4230 are a similar
problem. In your case it seems that GHC is too eager to prevent the
cycle you could make with foo (conT (mkName Bar)))
Regards,
Adam
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What am I missing? Cycle in type synonym declarations
On Tue, Aug 20, 2013 at 2:35 PM, adam vogt vogt.a...@gmail.com wrote:
On Tue, Aug 20, 2013 at 5:00 PM, David Fox d...@seereason.com wrote:
This file gives me the error Cycle in type synonym declarations Can
anyone tell me why? I'm just trying to write a function to create a
type that is a FooT with the type parameter fixed.
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH (Q, Dec, TypeQ)
data FooT a = FooT a
foo :: TypeQ - Q [Dec]
foo t = [d| type Bar = FooT $t |]
Hi David,
That's strange considering you can accomplish the same thing with:
foo t = fmap (:[]) $ tySynD (mkName Bar) [] [t| FooT $t |]
Bugs like http://ghc.haskell.org/trac/ghc/ticket/4230 are a similar
problem. In your case it seems that GHC is too eager to prevent the
cycle you could make with foo (conT (mkName Bar)))
Regards,
Adam
Thanks Adam, this must be the answer. And thanks for the equivalent expression.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Looking for ICFP roommate
I'm looking for an ICFP roommate. I plan to attend Sunday through Saturday and stay the nights of Saturday the 21st through Saturday the 28th. I missed the discounted price of $225 (yipes) at the Airport Hilton (sold out). Perhaps someone already has a room reserved with two beds or could switch to one with two beds and would like to reduce their cost by room-sharing for part or all of their stay. If so, please let me know. Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A question about laziness and performance in document serialization.
So I am not entirely clear on how to optimize for performance for lazy bytestrings. Currently I have a (Lazy) Map that contains large BSON values (more than 1mb when serialized each). I can serialize BSON documents to Lazy ByteStrings using Data.Binary.runPut. I then write this bytestring to a socket using Network.Socket.ByteString.Lazy. My question is this, if the Map object doesn't change (no updates) when it serializes the same document to the socket 2x in a row, does it re-evaluate the whole BSON value and convert it to a bytestring each time? Lets say I wanted to have a cache of bytestings so I have another Map object that has the serialized bytestrings that I populate it with every time the original BSON Map changes. Should the map be strict or lazy? Should the bytestrings it stores be strict or lazy? Any help in understanding laziness would be appreciated. -- Kyle Hanson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: posix-paths, for faster file system operations
John Lato and I would like to announce our posix-paths package. https://github.com/JohnLato/posix-paths It implements a large portion of System.Posix.FilePath using ByteString based RawFilePaths instead of String based FilePaths, and on top of that provides a Traversal module with a fast replacement for `getDirectoryContents` and a recursive `allDirectoryContents`. `getDirectoryContents` is (unsurprisingly?) really slow. Our replacement is 11 times faster in the recursive use case [1], and only 20% slower than `find`. Benchmarks are at [2], code is at [3]. We hope that these improvements will eventually make it into base some day. Until then, we propose our package as a base for discussion and further improvements. Contributions are welcome: Some FilePath operations are not in it yet (especially the Windows / drive related ones), and our traversals might not work on Windows. We would also appreciate some thorough looks at their low level implementations. If you find our benchmarks against getDirectoryContents unfair or would like to add another one, please send a pull request. We have been running this on Linux production machines for a few months now, and are pleased by the speed-up. [1] For the recursive version of the original `getDirectoryContents`, we used the implementation given in Real World Haskell: http://book.realworldhaskell.org/read/io-case-study-a-library-for-searching-the-filesystem.html [2] Benchmarks: On a real file system: http://johnlato.github.io/posix-paths/usrLocal.html On tmpfs: http://johnlato.github.io/posix-paths/tmpfs.html (note that here find is slow because of process starting overhead) [3] Code: Github: https://github.com/JohnLato/posix-paths RawFilePath operations: https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/FilePath.hs Traversals: https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/Directory/Traversals.hs Benchmarks: https://github.com/JohnLato/posix-paths/blob/master/benchmarks/Bench.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [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 m...@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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0
On Aug 20, 2013, at 02:19 , Niklas Broberg niklas.brob...@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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hspec-test-framework - Run test-framework tests with Hspec
My answer to this and many similar questions regarding tasty is: - I am probably not going to work on this - but I would be happy to see someone doing it Note that hspec-test-framework is a separate package, and it didn't have to be written or even approved by Simon. Same here — please write more supplementary packages if you feel a need. Roman * Alfredo Di Napoli alfredo.dinap...@gmail.com [2013-08-18 15:18:07+0200] Hi Simon, this is an exciting news! May I ask the question that maybe is lurking in the shadow? Due to the recent announcement of Roman's tasty library, are there plans to basically release something similar to hspec-test-framework and hspec-test-framework-th but targeting tasty instead? Bye :) A. On 18 August 2013 14:50, Simon Hengel s...@typeful.net wrote: Hi, I just released hspec-test-framework[1] and hspec-test-framework-th[2] to Hackage. They can be used to run test-framework tests with Hspec unmodified. This can also be used to work around test-framework's incompatibility with QuickCheck-2.6 and base-4.7.0 ;) Have a look at the README for usage instructions: https://github.com/sol/hspec-test-framework#readme Cheers, Simon [1] http://hackage.haskell.org/package/hspec-test-framework [2] http://hackage.haskell.org/package/hspec-test-framework-th ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)
On 20/08/2013, at 6:44 PM, Kyle Miller wrote: By working as expected I actually just meant that they distribute (as in a(b+c)=ab+ac) and commute (ab=ba and a+b=b+a), That is a tiny fraction of working as expected. The whole modular arithmetic argument would come close to having some virtue, *except* that division just plain does not fit. In particular, it's painfully easy to find x y such that (x*y) div y is not congruent to x modulo 2**n. The existence of division makes the everything's OK because it's modular argument look very sick indeed. The interpretation of any of these numbers being positive or negative is specious, but people still do it because it works reasonably well for small integers. No, they do it because their programming language specifications encourage them to do it, because their introductory courses teach them to do it, and their compilers, on seeing x 0, do not scream at them that is not well defined!, so the idea that it is supposed to work is constantly reinforced. And above all, people still do it because in most programming languages they have no practical alternative. Also, there's the definite advantage that you can use the same instructions for adding/multiplying signed and unsigned integers (for instance, pointer arithmetic). As the user of a programming language, what conceivable advantage is that to me? All the machines I have access to these days have two sets of multiply and divide instructions, and there have been machines with two sets of add and subtract instructions, and it is no big deal. The B6700 had one set of instructions (which actually dealt with both integers and floating point). It didn't have _any_ instructions for unsigned integer arithmetic, and Fortran, COBOL, BASIC, Pascal, Algol, and PL/I programmers didn't miss them. (In particular, to a B6700 programmer familiar with his/her machine's instruction set, the idea that variable access might have anything to do with unsigned operations would have seemed, heck, did seem quite bizarre.) For that matter, IBM mainframes have had, since the 1960s, A signed Add AL unsigned Add Logical S signed Subtract SL unsigned Subtract Logical M signed Multiply \ ML unsigned Multiply Logical | these four D signed Divide | are common DL unsigned Divide Logical / and it never stopped them being fast. I doubt that the presence of these instructions had any significant effect on the complexity of the machines. Even some 1980s single-chip machines did this. You mention that the B6700 trapped on overflows. While this is a nice feature, this has nothing to do with the number format. That's half true. The B6700 number format was such that there was nothing sensible they _could_ do on integer overflow. (Look it up or trust me; truncation would have been violently unnatural on those lovely machines.) One example of a nice thing about doing computations modulo 2^n is that you can do a bit twiddling trick called reciprocal multiplication (maybe sometimes called magic number multiplication). One reference for this is at [1]. Another reference is Hacker's Delight. But maybe you can save this for your ear's fingers. I have a copy of Hacker's Delight within arm's reach. This is not really something that people writing applications want. Usually, what they need is affordable multiplication and division that give right answers when right answers are to be had and don't drive the program insane with rubbish when right answers are not to be had. There are plenty of clever things computer architects can do, up to and including keeping a last divisor cache in the division unit to accelerate divisions that reuse a recent divisor. I can't really say I understand why anyone would actually want to use Int (unless they knew they wanted a modulo 2^n Int). Because they are calling an existing function that requires it. It's just like the question the only integral type in standard C that *cannot* be used safely to hold an 8-bit character is char, so why would anyone want to use char*? Answer: because of all the library functions that demand it. but Integer is actually (if you're using GMP with your ghc): Yes, that's tolerably well known. You only pay the space overhead when you need it (like Lisp or Smalltalk). But you always pay the time overhead. Where are you getting that about C? Do you mean that it's careful to allow implementations to decide to trap overflows? Because as far as I can tell, the C standard just says signed overflows give undefined behavior. The thing is that the standardisers *could* have defined signed int arithmetic to wrap (just like the benighted Java designers did) but they *chose* to leave the effect undefined (just like the Pascal standard) *so that* implementations that trap on overflow (which
