[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
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] 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
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] Retrieving Haddock comments with haskell-src-exts
Hi again, Hmm. I see the difficulty here, and eventually I would want to have support for this, but alas, not yet. If you come up with any solution that doesn't involve GHC (or only marginally so), I'd love to hear it. Cheers, Niklas On Wed, Aug 14, 2013 at 8:57 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: On 14/08/13 19:02, Niklas Broberg wrote: Hi Mateusz, haskell-src-exts is not haddock-aware I'm afraid, so I don't have any real solution for you. The one you mention, i.e. going through the whole parse result and stiching things together manually seems like the best bet if you want to use haskell-src-exts throughout. The main problem with this approach is that we get comments (and their SrcLoc) as a separate list. While it's trivial to check whether the comment starts with a ‘|’ or ‘^’ and it's not even hard to find any lines immediately following it, Haddock comments can appear in weird positions and trail until a line of code is encountered. Right now, it's rather hard to tell -- | Foo -- bar and -- | Foo someCode = undefined -- bar apart. I think this is the only option at the moment if I'm to use haskell-src-exts. In the longer run, it would be nice to have haddock support in haskell-src-exts, so ideas regarding what kind of interface you would like to see are most welcome. :-) For my use, I do not care about anything but Haddock comments. I don't care where or why they appear, what they are attached to c. With my current method, I just throw all this information away (it's given by GHC). For general use, I imagine that it'd be useful for the program to combine multi-line Haddock comments into a single one and attach it to whatever it is documenting. I'm not sure how haskell-src-exts is implemented but I don't think it's plausible to do this without going out to GHC and asking it for the information. Incidentally, this is precisely the problem I'm trying to solve with help of haskell-src-exts. Cheers, Niklas Thanks! -- 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] Retrieving Haddock comments with haskell-src-exts
Hi Mateusz, haskell-src-exts is not haddock-aware I'm afraid, so I don't have any real solution for you. The one you mention, i.e. going through the whole parse result and stiching things together manually seems like the best bet if you want to use haskell-src-exts throughout. In the longer run, it would be nice to have haddock support in haskell-src-exts, so ideas regarding what kind of interface you would like to see are most welcome. :-) Cheers, Niklas On Wed, Aug 14, 2013 at 4:57 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: I'm writing a small tool to help to analyse Haddock comments in Haskell source files to help me to indicate any potential breakage to documentation in existing source files. Currently I'm doing the parsing with the GHC's ‘parser’ function with Opt_Haddock set and I filter out everything I don't need. There are problems with this approach: determining any extensions and options used is vital for valid parsing of the files and a large amount of source files outright fails to parse without this information. Fortunately, haskell-src-exts exists and it can deal with all (or most) of this for me. Unfortunately, there doesn't seem to be any way to get it to recognise Haddock comments and the only option available is all comments or no comments at all. It's not easily possible to stitch these together without analysing the whole parse result. Currently I'm thinking of parsing out extensions and pragmas used using haskell-src-exts and then feeding those to GHC, effectively parsing the second time. Is there a way to avoid this? There's ‘lexTokenStream’ but I believe it has similar problems to ‘parser’, that is, needing to know the extensions beforehand. -- 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
[Haskell-cafe] ANNOUNCE: haskell-src-exts 1.13.5
Fellow Haskelleers,
I'm pleased to announce the release of haskell-src-exts-1.13.5!
* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via cabal: cabal install haskell-src-exts
* Darcs repo: http://code.haskell.org/haskell-src-exts
There are two primary reasons for this release: 1) to add the requested
support for UHC's 'js' FFI calling convention (in 1.13.4), and 2) to export
a stand-alone token stream lexer (in 1.13.5).
NOTE: If after reading the above, you think wow, a token stream lexer,
I'll use that for some kind of refactoring tool, then you're most likely
wrong. Please contact me in that case and I'll tell you why. :-)
A probably unnecessary warning: This release may fail to parse some files
that were previously possible to parse, if they included RULES pragmas
using 'forall' as a varid. I really doubt any such exist, and they would
not have been accepted by GHC if they did, so I sincerely doubt that anyone
will be effected by this.
Changelog:
1.13.4 -- 1.13.5
===
* Expose Language.Haskell.Exts.Lexer, which implements
a standalone token stream lexer. The module is
re-exported both by Language.Haskell.Exts and by
Language.Haskell.Exts.Annotated.
1.13.3 -- 1.13.4
===
* Fix bug where operators starting with # written in
parentheses would not be parsed when UnboxedTuples is
turned on. Now works.
* Allow 'family' and 'forall' as (non-type) varid's. This
adds one more shift/reduce conflict to the parser, and
its resolution means that '{-# RULES name forall = ... #-}'
is not allowed.
* Complete the set of FFI calling conventions from the Haskell
2010 report (even if no compiler implements them). Also
include the 'js' calling convention, supported by UHC.
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal install fails due to recent HUnit
On Wed, Jul 25, 2012 at 12:22 PM, Ross Paterson r...@soi.city.ac.uk wrote: As I understand it, the plan is to modify the following packages in hackage in-situ to remove the test sections (which contain the troublesome conditionals): HUnit-1.2.5.0 bloomfilter-1.2.6.10 codemonitor-0.1 codemonitor-0.2 fixhs-0.1.4 leksah-server-0.12.0.3 leksah-server-0.12.0.4 leksah-server-0.12.0.5 pqc-0.5 pqc-0.5.1 Does anyone object? No objections, but some impatience. ;-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts 1.13.3
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.13.3! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts This release attempts to fix a bunch of long-standing (and a few new) bugs, while still avoiding a new major version bump. Changelog: 1.13.2 -- 1.13.3 === * Fundep premises are now allowed to be empty. * Fix the bug where the lexer would crash on a LINE pragma that did not include a line number. * Fix the bug where the lexer would require the # of a MagicHash-style type constructor to be succeeded by at least one character in the file. * Fix really long-standing bug where the parser would crash with an ugly Internal error error message if encountering an extra }. * Report errors at the right place for function arity mismatches. Earlier they were reported at end of file, now they are reported where the function is declared. * Lexer now properly fails on line-breaks in string literals. * Lexer now handles character escapes up to 0x10 (unicode). Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell source AST zipper with state
On Thu, May 3, 2012 at 2:52 AM, Andrew Seniuk ras...@gmail.com wrote: Note that the Annotated version of the HSE parser/AST will probably not provide enough generality for the sorts of attributes you want to store (it's for source locations, unless something changed in the most recent release). I do hope you're wrong on that! The annotations are fully general (and have been all along), so you can store whatever you like there(*). They are *used* for source locations by the parser, but that's just one possibility. Cheers, /Niklas (*) The only requirement is that you need to store values of the same type throughout the syntax tree - but Either or Maybe should do the trick there. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: hsx-0.10.1, hjscript-0.6.0, hsp-0.7.0
Hi all, I'm pleased to announce the release of the latest versions of the libraries in the Haskell Server Pages suite. Haskell Server Pages enables literal XML syntax to be used mixed with Haskell code (like e.g. PHP), in a sane way (unlike said PHP). In principle the functionality could be used together with any Haskell web framework, but is (currently) best integrated in and supported by Happstack. For this release I owe much to Jeremy Shaw, both for inspiration and for actual patches. There are some grand plans in the pipeline for some more extensive changes to the suite, to shape it up to be worthy of the current exciting state-of-the-art of Haskell web development. Stay tuned! Cheers, /Niklas Specific changes in this release: * In the XMLGen class, the following associated types have been renamed to avoid frequent name clashes, and to better match the intention of those types: XML = XMLType, Child = ChildType, Attribute = AttributeType. * Literal CDATA strings are now given an explicit type signature in the post-processed code. This to avoid ambiguities when OverloadedStrings is enabled. * class XMLGenerator m now has EmbedAsChild m () as another premise. * HSX.Transform now exports a method transformExp :: Exp - Exp, intended to be used with quasi-quotation. * trhsx no longer performs fixity resolution before transforming, allowing the tool to be used on files using operators with (locally) unknown fixity. * hsp and hjscript updated to work with hsx-0.10. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] No email verification token from trac.haskell.org
Hi all, I have problems with my trac for haskell-src-exts. When I log in, I am asked to verify my email address, but no verification token is ever sent to my email address. And before I verify my address, I'm not allowed to do anything on the trac. Help? :-) /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No email verification token from trac.haskell.org
On Mon, Apr 23, 2012 at 5:13 PM, Johan Tibell johan.tib...@gmail.comwrote: On Mon, Apr 23, 2012 at 7:42 AM, Niklas Broberg niklas.brob...@gmail.com wrote: I have problems with my trac for haskell-src-exts. When I log in, I am asked to verify my email address, but no verification token is ever sent to my email address. And before I verify my address, I'm not allowed to do anything on the trac. I've had the same problem for a long time. I assume the Trac instance is broken Certainly sounds plausible - but how to fix it? There are some possible fixes listed on the Trac homepage, but I don't seem to have enough permissions to do anything at all. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts-1.13.2
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.13.2! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts This release contains only a few small tweaks and bug-fixes. Changelog: 1.13.1 -- 1.13.2 === * Fix the bug with the precedence of unary prefix minus. Previously it was resolved as binding more tightly than any infix operator, now it is correctly treated as having the same fixity as binary infix minus. 1.13.0 -- 1.13.1 === * Allow an optional semi before the closing tag of an element. This achieves a similar effect for XmlSyntax in do blocks as DoAndIfThenElse does for the if construct. No more need to indent the closing tag one step further than the opening tag. * Add a dummy 'noLoc :: SrcLoc' to L.H.E.SrcLoc, to use when generating code. It could definitely be done more elegantly, but not without inducing another major version bump, so later. * Fix a regression from 1.11.x where the parser would crash upon encountering non-simple class/data declaration heads, e.g. 'data A [a]'. Now fails with a parse error as intended. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSoC project idea: haskell-type-exts
See ticket here: http://hackage.haskell.org/trac/summer-of-code/ticket/1620 == What? == The haskell-src-exts library (HSE) is very popular for manipulating Haskell source code in a wide range of scenarios, such as (syntactic) preprocessors (e.g. hsx), syntax highlighting, refactoring and code inspection (e.g. hlint), etc. A commonly sought feature, that would enable a multitude of new and improved scenarios, is the ability to type-check the code, and annotate the AST with type information. Type-driven refactoring, type-aware code inspection, type-based preprocessing, ... Lots of pure awesomeness lies in that direction. Sadly, HSE has no type-checking abilities. For those who seek such, we are forced to point in the direction of the dark cave that is the GHC API. While GHC is an utterly awesome compiler, there are several reasons why this is not an ideal situation. First, GHC was designed and built for optimization, which means that even the early stages of the compilation pipeline contain features that cater to later optimization, but that are (at best) unnecessary for a front-end tool. Second, the API into GHC internals is defined as an afterthought. Some good work has been done to make it somewhat palatable, but it remains a fact that GHC's primary purpose is not to be a library for integration in tools, and this shows. Overall, depending on GHC when all you want is front-end capabilities like parsing and typechecking, is really like using the proverbial sledge hammer. Also, at the meta level, GHC deserves competition. Right now GHC is de facto the only implementation of Haskell, and as such it more or less defines the progress of Haskell. Too often this leads to overly pragmatic choices, which lead to inconsistencies and headaches for tool programmers. Having a separate, stand-alone front end library would help set higher standards. So - what we need is a type checker that works on the HSE AST: haskell-type-exts! == How? == I now hear you think: This is too much, an enormous project, surely it can't be done as a GSoC project? Sure it can! By walking in the footsteps of giants, and following GHC's approach. This can be achieved by closely observing the documentation provided by [1] and [2], with a bit of [3] thrown into the mix. I already have a basic library that provides most of the core framework necessary to cover extensions, but at this time it's mostly just scaffolding. It needs a lot of love, to provide cover for all the various available extensions, but I'm confident it can be done satisfactorily as a GSoC project. Still, it would be reasonable to modularize the task. Certain features are more crucial than others to support, simply because they have a more profound impact on the overall type-checking. Higher-rank types, GADTs and type families (and fundeps) are likely the most important ones to get right. There are also some design issues to get right (e.g. using pure substitution vs efficient mutable variables). I (Niklas Broberg) am more than willing to mentor this project. == Further reading: == [1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. [2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) – Modular type inference with local assumptions [3] M. P. Jones. Typing Haskell in Haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts-1.13.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.13.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts It's been a *very short* while since the last update before this, and another (smallish) major release it is. Sorry about that (especially to Neil who was quick to update). The main update of this release is to add support for DoAndIfThenElse, which means haskell-src-exts at long last is compliant with Haskell2010. This is also the cause for the backwards-incompatible change: default parse mode is now to use Haskell2010 mode. In particular this means that NPlusKPatterns is no longer recognized by default. No old code using haskell-src-exts should fail to compile (unless really unlucky with clashing imports from L.H.E.Extension), but it may now fail to work on some Haskell98-compliant source files. Changelog: 1.12.0 -- 1.13.0 === * Add extensions DoAndIfThenElse and NPlusKPatterns to Language.Haskell.Exts.Extensions. * DoAndIfThenElse is now supported, at long last, making HSE compatible with Haskell2010 * Introduce haskell98 and haskell2010 extension groups, exported from Language.Haskell.Exts.Extensions. * Backwards-incompatible change: default parse mode is now to use haskell2010, which means the following features are recognized by default: DoAndIfThenElse, PatternGuards, ForeignFunctionInterface, EmptyDataDecls. NPlusKPatterns is no longer recognized by default. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts-1.12.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.12.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts It's been a long while since the last update before this, but it is my definite hope that I will once again be able to update regularly. This major release primarily enables the (relatively) new quasi-quoter syntax. The major version bump is questionable, but better safe than sorry. The only backwards incompatible change is that pretty- and exact-printing now use the new quasi-quoter syntax, which makes the round-tripping 'exactPrint . parse' cycle fail for code using the old syntax. There are more changes in the pipeline, some larger and some smaller. Stay tuned! Changelog: 1.11.1 -- 1.12.0 === * Move from old [$...| quasi-quote syntax to the new [...| one. The old syntax is still recognized while parsing. * Allow symbols as variables when TypeOperators is enabled. * Rename ExplicitForall in ExplicitForAll, to be consistent with GHC and the Haskell' process. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generating parens for pretty-printing code in haskell-src-exts
Hi Conal, On Sun, Jan 15, 2012 at 6:45 AM, Conal Elliott co...@conal.net wrote: I'm using haskell-src-exts together with SYB for a code-rewriting project, and I'm having difficulty with parenthesization. I naïvely expected that parentheses would be absent from the abstract syntax, being removed during parsing and inserted during pretty-printing. It's easy for me to remove them myself, but harder to add them (minimally) after transformation. Rather than re-inventing the wheel, I thought I'd ask for help. It's not at all straight-forward to properly insert minimal parentheses during pretty-printing, since minimal is a semantic notion. For that to work, we would need the pretty-printer to take a set of known fixities as an argument, just like the parser currently does. I'm not opposed to the idea in principle, but it's not how it currently works. Has anyone written automatic minimal parens insertion for haskell-src-exts? ... or we could do it this way, in a two-stage modular process which gives even more flexibility. I'm not aware of any such functionality, currently, but if it exists (or happens to come into existence) then I would be interested in including it in haskell-src-exts. Best regards, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)
On Thu, Dec 15, 2011 at 5:33 PM, Sean Leather leat...@cs.uu.nl wrote: On Thu, Dec 15, 2011 at 11:07, Niklas Broberg wrote: Envisioned: The function you ask for can definitely be written for haskell-src-exts, which I know you are currently using. I just need to complete my type checker for haskell-src-exts first. Which is not a small task, but one that has been started. That's good to know! I presume it's something like Haskell98 to start with? I'd be even more impressed (and possibly also concerned for your health) if you were going to tackle all of the extensions! Actually, no. Starting with Haskell98 would just lead to great pains later on, since many of the extensions require very invasive changes compared to a H98 checker. My starting point has been to identify the core structural and algorithmical requirements for a type checker that would indeed tackle all of the extensions. My current checker (which I wouldn't even call half-complete) is based on a merge of the algorithms discussed in [1] and [2]. Between the two, they give, on the one hand, the bidirectional inference needed to handle arbitrary-rank types, and, on the other hand, the power of local assumptions needed to handle GADTs and type families. I thank you for your concerns for my health. However, I assure you they are quite misplaced. Typing Haskell-with-extensions in Haskell is not only a far smaller beast than what it's made out to be, when walking in the well-documented footsteps of giants. It is also lots of fun. :-) I've been trying to find a student to write a haskell-src-exts type checker for me. It should use a particular kind of mechanism though, using constraints similar to [1]. Then, I want to adapt that to do transformations. What approach are you using? Maybe I can somehow steal your work... ;) As you note from my starting references, I'm using the same approach and base algorithms as GHC does. I looked at some alternatives briefly, including the work you reference, but I discarded them all since none of them had support for everything I wanted to cover. In particular, it is not at all clear how these systems would merge with bi-directional inference or local assumptions. Tackling *that* problem would be a large and very interesting research topic I'm sure, but not one I have time to dig into at the current time. Indeed, the feasibility of my project (and thus the sanctity of my health) relies very heavily on the footsteps-of-giants factor... So as not to give anyone false hopes, I should point out that I currently have next to no time at all to devote to this, and the project has been dormant since August. I'll return to it for sure, but at the moment cannot tell when. Cheers, /Niklas [1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. [2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) – Modular type inference with local assumptions ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)
On Thu, Dec 15, 2011 at 6:24 PM, Thomas Schilling nomin...@googlemail.comwrote: What exactly are the hopes for such a type checker? I can understand it being interesting as a research project, but as a realistic tools there are two huge issues: 1. It's going to take a LOT of time to reach feature parity with GHC's type checker. 2. Assuming that can be done, how is it going to be maintained and kept up to date with GHC? If it is going to be used as a development tool, both of these are a major requirement. I haven't looked into the issues, but I'd expect it would be more realistic (although definitely not trivial) to translate from GHC's internal AST into an annotated haskell-src-exts AST. With all due respect, the sentiments you give voice to here are a large part of what drives me to do this project in the first place. Haskell is not GHC, and I think that the very dominant position of GHC many times leads to ill thought-through extensions. Since GHC has no competitor, often extensions (meaning behavior as denoted and delimited by some -X flag) are based on what is most convenient from the implementation point of view, rather than what would give the most consistent, logical and modular user experience (not to mention third-party-tool-implementor-trying-to-support-GHC-extensions experience). As such, I'm not primarily doing this project to get a development tool out, even if that certainly is a very neat thing. I'm just as much doing it to provide a Haskell (front-end) implementation that can serve as a better reference than GHC, one that very explicitly does *not* choose the convenient route to what constitutes an extension, and instead attempts to apply rigid consistency and modularity between extensions. Also, just like for haskell-src-exts I hope to build the type checker from the roots with the user interface as a core design goal, not as a tacked-on afterthought. Mind you, in no way do I intend any major criticism towards GHC or its implementors. GHC is a truly amazing piece of software, indeed it's probably my personal favorite piece of software of all times. That does not mean it comes free of quirks and shady corners though, and it is my hope that by doing what I do I can help shine a light on them. Answering your specific issues: 1) Yes, it's a lot of work. Probably not half as much as you'd think though, see my previous mail about walking in the footsteps of giants. But beyond that, I think it's work that truly needs to be done, for the greater good of Haskell. 2) Well, I think I've done a reasonably good job keeping haskell-src-exts up to date so far, even if the last year has been pretty bad in that regard (writing a PhD thesis will do that to you). I'll keep doing it for the type checker as well. But I am but one man, so if anyone else feels like joining the project then they are more than welcome to. Sort-of-3) Yes, both implementation and maintenance are likely going to be far more costly than the alternative to do a translation via the GHC API. I'm not interested in that alternative though. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typechecking Using GHC API
Currently: Your only option is to use GHC API if you want type checking. I can't help you with that, sorry. Envisioned: The function you ask for can definitely be written for haskell-src-exts, which I know you are currently using. I just need to complete my type checker for haskell-src-exts first. Which is not a small task, but one that has been started. I doubt it will be done in time for your project though, sorry. Best regards, /Niklas On Tue, Dec 13, 2011 at 6:16 PM, Sh NJP shayan@gmail.com wrote: Hi, I do some pre-processing on a normal Haskell code ( -F ). The pre-processor needs to know the type of each expression. What are the possibilities to do so? Can I use GHC API to employ GHC type checker? If yes, any good tutorial? Is it too naive to think of a function, f :: String - AnnotatedAST , that takes Haskell code and returns its corresponding abstract syntax tree annotated with types? Thanks, /shayan ___ 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-src-exts should depend on happy
On Thu, Aug 25, 2011 at 6:17 PM, Brent Yorgey byor...@seas.upenn.eduwrote: On Thu, Aug 25, 2011 at 04:47:30PM +0100, Ozgur Akgun wrote: Hi, cabal installing haskell-src-exts fails, because of an unlisted dependency to the happy executable. It does list a dependency on happy: Build-Tools: happy = 1.17 If I understand correctly, the problem is that cabal does not track packages which only install executables. So all it can do is give an error if a 'happy' executable is not found; there is no way to have it automatically install happy if it is not. This is a well-known limitation of cabal-install rather than a problem with the haskell-src-exts package in particular. Yep, what Brent said. See this ticket: http://trac.haskell.org/haskell-src-exts/ticket/59 Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts 1.11.1
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.11.1! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts This major release fixes some long-standing bugs in the fixity handling. Many thanks for Lennart Augustsson for the patches! Changelog: 1.10.2 -- 1.11.1 === * API change: the fixities field in ParseMode is now of type Maybe [Fixity]. If the field is Nothing the parsing will not try to do any fixity resolution whatsoever, otherwise it behaves as before. * API change, bug fix: The Fixity type contains a QName rather than an Op to name the operator. The operator must match the given QName exactly (i.e., unqualified names only match unqualified names, and qualified names only match qualified names) for applyFixities to perform fixups. * Bug fix: End-of-file inside an OPTIONS pragma no longer loops. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal upload failure
Yep, works fine now, thanks! /Niklas On Tue, May 24, 2011 at 2:52 PM, Ross Paterson r...@soi.city.ac.uk wrote: Version skew problem -- I hope it's fixed 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] code review?
On Tue, May 24, 2011 at 7:18 PM, Neil Mitchell ndmitch...@gmail.com wrote: Before doing a code review I always demand that the author runs over the code with HLint (http://community.haskell.org/~ndm/hlint) - they Very good point. In fact you just inspired me to finally download it and run it on my own code. Thanks for the great tool! Glad you like it. While I'm on the topic, I recently wrote a tool that wanted to traverse deep data structures as produced by haskell-src-exts. I wound up with about 50 lines of case expressions and around the time my hands were literally beginning to hurt decided that enough was enough and I should try a generic approach. I heard uniplate was pretty easy to use, and was pretty pleased to turn the entire thing into a single line. It took me a little longer to figure out I needed to use universeBi since all the examples were monotyped, but once I did it Just Worked. Amazing. So thanks again! And maybe you could mention universeBi in the instant introduction? Yes, I probably should - I'll try and get to that. Of course, I'd also happily accept a patch against http://community.haskell.org/~ndm/darcs/uniplate I use Uniplate inside HLint, and it's invaluable - there are a lot of times when List Comp + universeBi really hits the spot. +1 on that, I use uniplate for pretty much all my haskell-src-exts tasks these days, works like a charm! I'd love to include some standard traversal functionality in haskell-src-exts that depends on uniplate, but hesitate to do so because of HP aspirations for haskell-src-exts. Neil, what do you reckon the chances of getting uniplate in the HP are? :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage internal server error
nibro@nibro-laptop:~/src/haskell-src-exts$ cabal sdist Building source dist for haskell-src-exts-1.11.1... Preprocessing library haskell-src-exts-1.11.1... Source tarball created: dist/haskell-src-exts-1.11.1.tar.gz nibro@nibro-laptop:~/src/haskell-src-exts$ cabal upload dist/haskell-src-exts-1.11.1.tar.gz Hackage username: NiklasBroberg Hackage password: Uploading dist/haskell-src-exts-1.11.1.tar.gz... Error: dist/haskell-src-exts-1.11.1.tar.gz: 500 Internal Server Error 500 Internal Server Error stdin: hWaitForInput: invalid argument (Invalid or incomplete multibyte or wide character) nibro@nibro-laptop:~/src/haskell-src-exts$ Hackage's fault, cabal's fault, or (*gasp*) mine? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal upload failure
On 24 May 2011 19:48, Emil Axelsson e...@chalmers.se wrote: Hello! I'm trying to upload a new version of syntactic, but Hackage gives the error: 500 Internal Server Error stdin: hWaitForInput: invalid argument (Invalid or incomplete multibyte or wide character) In fact, I get the same error if I use the Check functionality on the earlier version that is already on Hackage. Any idea what causes this? I have the exact same issue, I mailed about it some 10 minutes before you. So I believe this is Hackage's fault. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wanted: composoable parsers from haskell-src-exts
I already export a partial parser for top-of-file pragmas, I see. What I don't see is how such a parser would return the rest of input. Hmm. I see. And I see that you are correct in not seeing it, since it appears it cannot be done with Happy, which I believed. It would then be down to the parser/lexer to pass on unconsumed input, which seems a daunting and disruptive task, seeing how the lexer typically would tokenize some input in advance before the parser discovers that it cannot consume what has been lexed... Hmm. I still find it a highly desirable feature, and at some point I would like to give it some further thought, to see if a way can be found. In the mean time, would you mind filing a feature request at http://trac.haskell.org/haskell-src-exts ? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wanted: composoable parsers from haskell-src-exts
Hi Johannes, The answer is: A) You can't, the way haskell-src-exts is built. You need to specify the %partial directives in the happy grammar, so without editing haskell-src-exts there's no way you could tack on partiality to the existing parsing primitives. B) It's a great feature request (to the point where I wonder why I haven't thought of it before), that should be quite easy to implement. I already export a partial parser for top-of-file pragmas, there's no reason why I couldn't export partial parsers for all the other entry points as well. I hope I can implement it shortly, but if you want it really fast and certain - patches are most welcome! Cheers, /Niklas On Mon, Mar 14, 2011 at 6:55 PM, J. Waldmann waldm...@imn.htwk-leipzig.dewrote: Hi. I want to use parsers from haskell-src-exts as sub-parsers, which does not seem to work since they insist on consuming the input completely. I would need them to parse a maximal prefix, and return the (unconsumed) rest of input as well (cf. http://hackage.haskell.org/packages/archive/parsec/3.1.1/doc/html/Text-Parsec-Prim.html#v:getInput ) I figure that happy has the %partial directive for that, but the description http://www.haskell.org/happy/doc/html/sec-directives.html#sec-partial-parsers does not really tell me how to obtain the rest of the input. Any hints (or code samples) appreciated. Thanks - J.W. ___ 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
[Haskell-cafe] trac.haskell.org problem
Ah, I suppose that's to do with the trac server itself, that's beyond me. Moving to café: Does anyone know what's up with trac.haskell.org not sending out verification emails? Cheers, /Niklas From: Jurriaan Hage [j...@cs.uu.nl] Sent: Monday, February 28, 2011 8:41 AM To: Niklas Broberg Subject: Re: Again a question about haskell-src-exts. On Feb 28, 2011, at 8:39 AM, Niklas Broberg wrote: I suppose I do - to the extend I can. What's the issue? :-) The system does not send out verification e-mails, so I can not really register completely and submit new issues. I have tried it with two different e-mail accounts, and somebody else has tried too. They also do not show up in spam folders. Jur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for children? Any experience?
Ye gods! A B D [1] language for kids? At least give them a fighting chance [2] at becoming future developers. Haskell's immutability is good for mathematics but doing anything else takes a great deal of up-front patience and perseverance, two very rare qualities in that demographic if my own childhood is any indication. Begone, disbeliever! And listen to the gospel of Matthias Felleisen preaching the truth: http://vimeo.com/6631514 (presentation from ICFP 2009) The paper is A Functional I/O System - or, Fun for Freshman Kids: http://www.ccs.neu.edu/scheme/pubs/icfp09-fffk.pdf Alas, it's about Scheme, but I am sure it would be both interesting and useful regardless. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-src-exts 1.10.1
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.10.1! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts Unless you are using the XmlSyntax extension, this major version bump should behave just like a minor version bump. Changes: 1.10.0 -- 1.10.1 === * Enable the unicode version of DoubleColon (x2237). Thanks to Andrés Sicard-Ramírez for the patch! 1.9.6 -- 1.10.0 === * Ensure that implied extensions are always picked up, not only when using the parseFile* family of functions as previously. * Add the newly devised %.../% syntax to the XmlSyntax support. This causes changes to pretty much everything, including adding a case to the AST which prompts the major version bump. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Add haskell-src as an official machine-readable component of the Haskell standard
(Moving to Café) (Examples of controversies possible in haskell-src: we have the Hs prefix on constructors everywhere, we can't provide fixity information (and the haskell-src-exts implementation of this is unsatisfactory in several important ways) ... What ways? http://trac.haskell.org/haskell-src-exts/ :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
What changed between GHC 6.12 and GHC 7.0? Is there a some solution besides using IncoherentInstances in every module that imports XMLGenerator? I just want to point out that IncoherentInstances is NOT a solution. It would probably make the files compile, but not at all with the semantics we want. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: language-java-0.1.0
Hi café, I found myself in need of a source manipulation suite for Java code. A hackage search turned up nothing, so I wrote one: http://hackage.haskell.org/package/language-java I'm sure there are a number of bugs waiting to be discovered, my own testing hasn't been overly extensive. I'm setting up a trac, will follow up with its location once it's up. Known short-coming: Annotations are not yet supported. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: language-java-0.1.0
I'm sure there are a number of bugs waiting to be discovered, my own testing hasn't been overly extensive. I'm setting up a trac, will follow up with its location once it's up. http://trac.haskell.org/language-java Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How to make cabal pass flags to happy?
Thanks for the answers, all. :-) Since this doesn't seem to be the common knowledge I expected it to be, I'll try to work out how it's done properly and blog about it. And hopefully generate some much needed documentation for cabal along the way. What I want specifically is to have happy produce a GLR parser from my .ly file, and I want this to happen during 'cabal install'. Which in turn means I want cabal to pass the --glr flag to happy during setup. My best guess is that I might want to use 'ppHappy' [1], or something in the vicinity, but there's no documentation for the combinator and it's far from obvious how to pass arguments to it. I think the right solution is for the happy source file to specify what kind of grammar it is / should be produced. Yes, that would mean modifying happy. Hmm, I agree with you in this particular case, regarding the grammar, since it really only makes sense for any given happy grammar to generate either kind of parser. But such a solution still wouldn't answer the general question about passing flags to preprocessors. Certainly not all such use cases are best fixed by pushing the flags into the pre-processed files. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to make cabal pass flags to happy?
On Fri, Oct 8, 2010 at 4:55 PM, Niklas Broberg niklas.brob...@gmail.com wrote: Hi all, I want to do something I thought would be quite simple, but try as I might I can't find neither information nor examples on how to achieve it. What I want specifically is to have happy produce a GLR parser from my .ly file, and I want this to happen during 'cabal install'. Which in turn means I want cabal to pass the --glr flag to happy during setup. My best guess is that I might want to use 'ppHappy' [1], or something in the vicinity, but there's no documentation for the combinator and it's far from obvious how to pass arguments to it. ... help? :-) ... anyone? ... please? :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to make cabal pass flags to happy?
Hi all, I want to do something I thought would be quite simple, but try as I might I can't find neither information nor examples on how to achieve it. What I want specifically is to have happy produce a GLR parser from my .ly file, and I want this to happen during 'cabal install'. Which in turn means I want cabal to pass the --glr flag to happy during setup. My best guess is that I might want to use 'ppHappy' [1], or something in the vicinity, but there's no documentation for the combinator and it's far from obvious how to pass arguments to it. ... help? :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: alex-meta-0.1.1 and happy-meta-0.1.1
2010/9/22 Jonas Almström Duregård jonas.dureg...@chalmers.se: I'm pleased to announce alex-meta and happy-meta! These libraries provide quasi-quoter frontends and Template Haskell backends to the Alex lexer generator and the Happy parser generator respectively. Awesome! /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts 1.9.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.9.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts 1.8.2 -- 1.9.0 === * OptionPragma is renamed to the more descriptive ModulePragma, and adds a constructor AnnModulePragma for handling ANN pragmas preceding module header. * Add instances for Eq/Ord/Data/Typeable for Fixity. * Add 'parseFileWithComments' and 'parseFileContentsWithComments' to L.H.Exts . * More informative error messages when HSX tags are mismatched (thanks Gracjan Polak for the patch!) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-src type inference algorithm?
On Fri, Feb 12, 2010 at 10:14 AM, Lennart Augustsson lenn...@augustsson.net wrote: Well, something like such a tool exists, but I can't give it away. I know. :-) /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-src type inference algorithm?
Anyone know of a type inference utility that can run right on haskell-src types? or one that could be easily adapted? This is very high on my wish-list for haskell-src-exts, and I'm hoping the stuff Lennart will contribute will go a long way towards making it feasible. I believe I can safely say that no such tool exists (and if it does, why haven't you told me?? ;-)), but if you implement (parts of) one yourself I'd be more than interested to see, and incorporate, the results. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Anyone up for Google SoC 2010?
On Fri, Feb 5, 2010 at 8:55 PM, Edward Kmett ekm...@gmail.com wrote: You can add me to the list of voices that were unwilling to use it before the summer-of-code project due to the random incompatibilities caused by the huge supply of extensions it supported out of the box, but who were happy to switch to it after the changes were made to make them configurable. This was indeed the main priority of the project, and the reason why even I would not have recommended anyone to use haskell-src-exts in production before the project. The rest is just gravy that happens to permit a number of applications such as refactoring browsers that were impossible with the previous implementation. And, as I recall, the fairly radical exploratory pretty print . parse = id goal was explicitly listed merely as a secondary goal on the original application. Indeed it was, and I am not aware of any major applications that actually use the exact-print functionality yet (please, tell me if you have one!). I do know of several that make very good use of the new Annotated syntax tree, though, which was introduced as a step towards exact-printing. The benefits of that, together with the configurable extensions, is more than enough to now make me happily recommend haskell-src-exts to anyone working with Haskell source code in any application. The rest is, as you accurately put it, just gravy. I must admit I'm a bit sad to have the value of my project questioned in this way, a project that I myself was more than pleased with, both with the actual work achieved and the significant positive feedback I have received after its conclusion. If haskell-src-exts was indeed popular even before the project, that's all well and good to me. But it doesn't mean that the library offered to the users then was satisfactory, nor does it mean that the project failed to deliver something that those same users needed and/or could make good use of. Even if the number of direct users did not rise dramatically as a consequence of the project, why would it not be valid use of a project slot to greatly improve a library that was already popular? Browsing the numbers [1] posted by Don Stewart in September last year (the Haskell Symposium figures, which is the latest I could find) suggests a substantial increase of downloads of the package both before, during and after the project, but I can only speculate why. And since the project concluded late August, figures for September and onwards would have been more telling. I'm at a loss as to what criteria is actually used to judge success here. It seems to me a bit like the eternal discussion between basic research and applied research. Just because something (research/library/project) doesn't have an immediate, palpable impact and/or delivers a visible tool, that certainly doesn't imply that it doesn't have merit or won't have as profound an impact on the domain, if more diffuse than a tool (or other palpable deliverable) would. /Niklas [1] http://www.galois.com/~dons/hackage/september-2009/total-downloads.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Anyone up for Google SoC 2010?
There may be an eternal discussion on it, but it seems pretty clear to me which side SoC comes down on: http://code.google.com/soc/ I'm really not sure what you're getting at. How do the points you list not relate to my project? And how does my analogy contradict any of those points? If the goal is to have more source code [..] created and released for the use and benefit of all, how does my project fail to achieve this? /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts-1.8.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.8.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts For users of hsx, the latest version 0.6.1 works unchanged with this release. 1.7.2 -- 1.8.0 === * Add an instance Show Fixity (derived). * Support for the new ANN and INLINE_CONLIKE pragmas. * Remove support for CFILES and INCLUDE pragmas. The support wasn't correct anyway, as it assumed the pragmas appeared at the top of files. As CFILES/INCLUDE pragmas can (and do) appear anywhere, there's no hope to support them in the AST. Better to remove the support altogether. Files with CFILES/INCLUDE pragmas can still be parsed of course, but those pragmas will be handled as comments. * Parsing with ignoreLinePragmas = False now correctly updates the file name. * Allow the whole SPECIALISE/INLINE family of pragmas in instance declarations. The InsInline constructor is removed, and is now represented by 'InsDecl (InlineSig ...)'. * Fix a bug with line numbering and quasi quotes, and a similar one with line numbering and CDATA. * Fix a few minor bugs in the exactPrinter. * Fix the strange handling of so called strings in LINE pragmas. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts-1.8.0
1.7.2 -- 1.8.0 === ... and one more I forgot: Export 'knownExtensions' from .Extension. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts 1.7.0
Fellow Haskelleers, As I was asked to start spamming again, I'm hereby pleased to announce the release of haskell-src-exts-1.7.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts For users of hsx, this version works fine with hsx-0.6.1. Since I haven't sent out one of these announcements in a while, here's the complete CHANGELOG since the previous announcement: ** 1.7.x 1.6.1 -- 1.7.0 === * Operators defined on the form (a `op` b) c = ... could not be handled by the (annotated) AST, nor the parser. I had to change the definition of the AST node for InfixMatch to allow a list of right-hand subpatterns, i.e. InfixMatch l (Pat l) (Name l) (Pat l) ... has become InfixMatch l (Pat l) (Name l) [Pat l] ... I also had an epiphany and fixed the issue that would arise with exact printing of prefix definitions including parentheses (e.g. (foo x) y = ...), so that now works too! ** 1.6.x 1.6.0 -- 1.6.1 === * UnicodeSyntax now works not only for identifiers, but also for -, - and =, as well as Arrows arrows and kind stars. (And before you send me bug reports for this one, do check that your version of readFile is Unicode aware, i.e. you use GHC 6.12 or the utf8-string version). 1.5.3 -- 1.6.0 === * (=~=) turns out to be too general at Functor (for intuitive and not technical reasons), so is specialised to Annotated to closer mirror the original intention. * applyFixities is hoisted to a monad, and now fails on ambiguous infix expressions. ** 1.5.x 1.5.2 -- 1.5.3 === * Several small bug fixes in the exact printer, and fail more gracefully if the number of srcInfoPoints doesn't match the needs of the node. 1.5.1 -- 1.5.2 === * Fix a bug in the exact printer that made it always print the first token at position (0,0). * In fixing the above, Annotated is now a superclass of ExactP. It was already a superclass in spirit, and nothing can break from this since ExactP is only exported abstractly. 1.5.0 -- 1.5.1 === * The pretty printer now introduces parentheses for non-atomic arguments to function application. Note that infix applications are left untouched, no parentheses will be inserted there, as it is assumed that fixities are already properly resolved. * Fix a bug in the pretty printer where view patterns and n+k patterns were not properly parenthesised. 1.4.0 -- 1.5.0 === * Add support for acting on LINE pragmas while parsing, i.e. updating the source position according to info given in LINE pragmas. This is done conditionally based on a new flag ignoreLinePragmas in the ParseMode, hence the need to increase the major version. ** 1.4.x 1.3.5 -- 1.4.0 === * The AST node for Proc in the simple AST is changed to include a SrcLoc argument, to make it consistent with similar nodes e.g. Lambda. This is specifically needed for transformation of patterns in HSX. ** 1.3.x 1.3.4 -- 1.3.5 === * Added an entry point in the parser for statements, and an instance Parseable Stmt to go with it. * Ensured that .Annotated exports all relevant parseXXX(WithYYY) functions. 1.3.3 -- 1.3.4 === * Operator fixities are now resolved in patterns. 1.3.2 -- 1.3.3 === * Fixes a bug where qualified keywords are rejected even if the extension that enables the keyword in question is not turned on. 1.3.0 -- 1.3.2 === (Let's forget 1.3.1 ever existed.) * Fix a bug where declarations of infix operators were not properly merged as FunBinds. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haddock question: hiding internal instances
Hi all, The question I have is this: How can I get Haddock to omit listing instances of package-internal data types for exported classes? Here's an example of what I mean: http://hackage.haskell.org/packages/archive/haskell-src-exts/1.6.0/doc/html/Language-Haskell-Exts-Pretty.html#t%3APretty At the very end of the rather extensive list of instances, you'll find the following: SrcInfo loc = Pretty (PAsst loc) SrcInfo loc = Pretty (PType loc) SrcInfo loc = Pretty (PContext loc) SrcInfo loc = Pretty (ParseXAttr loc) SrcInfo loc = Pretty (PFieldUpdate loc) SrcInfo loc = Pretty (PExp loc) All these data types are internal to the package, and the module they live in is marked with 'hide'. As expected no links are generated to any documentation for these data types, but I want them removed from this list entirely. They are internal after all, so what's the point of listing them? How can I achieve this? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock question: hiding internal instances
The question I have is this: How can I get Haddock to omit listing instances of package-internal data types for exported classes? You currently can't, unfortunately. See: http://trac.haskell.org/haddock/ticket/37 Roger that, cc added. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: haskell-src-exts 1.7.0
* UnicodeSyntax now works not only for identifiers, but also for does this mean that unicode identifiers are allowed only when UnicodeSyntax enabled? ghc allows them anyway Well spotted, that was poorly worded of me. haskell-src-exts works like GHC, allowing Unicode identifier always and Unicode keywords/keysymbols when UnicodeSyntax is enabled. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 1.7.0
* UnicodeSyntax now works not only for identifiers, but also for -, - and =, as well as Arrows arrows and kind stars. (And before you send me bug reports for this one, do check that your version of readFile is Unicode aware, i.e. you use GHC 6.12 or the utf8-string version). ... and with the newly released 1.7.1, UnicodeSyntax now also enables the fancy ∀ to mean forall. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
Since you can define operators in Haskell, would it make sense to include '=', '--', ':', ',' etc. as reserved names since those can't be used as operator names? They are indeed reserved operators in the report. 11 of those: .. : :: = \ | - - @ ~ = To be fair, _ is also a reserved identifier, so 22 and not 21 as I said previously. So a total of 33 reserved names. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] on Happstack - embedded HTML
[1] http://www.cs.chalmers.se/~d00nibro/hsp/ Oops. Seeing this link was a rather painful reminder that I ought to update that page. Last update was 2005, HSP has evolved quite a lot since then... The best way to get info on HSP in its current state is probably to check out some of the stuff that Jeremy Shaw has written. I'm sure he can give you better pointers than me. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
Haskell '98 apparently features 25 reserved words. (Not counting forall and mdo and so on, which AFAIK are not in Haskell '98.) 21 actually. case, class, data, default, deriving, do, else, if, import, in, infix, infixl, infixr, instance, let, module, newtype, of, then, type, where. There's also three special words that can still be used as identifiers, so aren't reserved: as, qualified, hiding. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: SourceGraph-0.6.0.2
On another note, anyone know why Niklas Broberg hasn't been making any release statements recently to say what the changes are, etc. for haskell-src-exts? Because it's been so many relatively small releases of late that I haven't wanted to spam the lists. :-) If you want to keep up to date, the changes can be found here: http://code.haskell.org/haskell-src-exts/CHANGELOG Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Happstack 0.4.1
GHC 6.12 currently requires a minor patch to HJScript. Details here: HJScript-0.4.5 is now on hackage, fixing this problem. Thanks for the heads-up. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-src-exts Question
Hi Dominic, On Fri, Nov 13, 2009 at 9:49 AM, Dominic Steinitz domi...@steinitz.org wrote: I would have expected the prettyprinter to produce this: pay tPD (a (length tOD + -1)) Do I have to write my own prettyprinter? Do I have to put in explicit parentheses? The latter seems unsatisfactory as my generated AST is unambiguous and bracketing ought to be part of the prettyprinter. The former would be quite a lot of code as there are many cases to consider. I will start by admitting that the prettyprinter is something of the black sheep of HSE, simply because it's been completely inherited from haskell-src and I've hardly messed with at all (except for adding new cases of course). I'm not surprised that it doesn't (yet) work satisfactorily in all cases. Looking at your example, what you want is brackets to be inserted whenever the right subexpression in an application is non-atomic. That certainly seems reasonable to me. Would you file a ticket for it please? http://trac.haskell.org/haskell-src-exts :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-src-exts Question
Surely you do want this. It's the biggest problem with the original haskell-src package, that it cannot print out any useful Haskell code obtained from the parser, because it forgets all the brackets. I should point out that haskell-src-exts already fixes this for code obtained from the parser, by making the parser and AST remember the brackets. Or as you put it: It probably wants to be a combination of the parser, AST and pretty printer. Yes indeed. But the problem at hand here is auto-generated AST code, where we cannot rely on the parser to do the right thing. There's help in the AST such that it's possible to explicitly insert brackets where needed, but I agree with Dominic that it shouldn't really be necessary in his case. Neil's point is well taken though - to do it correctly (or rather, minimally) for infix application, the pretty printer would need to be aware of the respective fixities involved. However, that doesn't mean we can't do better than what it is now, but be conservative about it. Only insert brackets where it's clear that brackets must be inserted, which would be the case for Dominic's example. If the argument to an application is non-atomic, it needs brackets, there's nothing ambiguous about that. Nothing can be said so categorically for infix applications, so there we should assume that the fixities are already done in the correct way, or that brackets are inserted manually where needed. Does that sound reasonable? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts-1.3.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.3.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts Version 1.3.0 is a new major release, following the PVP, as it contains a few backwards-incompatible changes, making the 1.2.x branch a very short parenthesis in history. There are two main new things in 1.3.0: fixity application is now handled uniformly regardless of which AST you use, simple or annotated, and the parser now supports multiple modules in the same source file. haskell-src-exts-1.3.0: * The *.Fixity modules now export the same Fixity type (incidentally the one previously used by the simple un-annotated parsing) and the same helper functions. If you've done all your Fixity handling using the helper functions (infix_, infixl_, infixr_), or if you've only used fixities for the un-annotated AST, you're safe. Only if you've manually created values of the annotated Fixity type will you need to pay attention. * A new entry point in the parser allows multiple modules to be parsed from the same source file ( parseModules[With[Mode|Comments]] ). * SpecialCon is now an instance of Pretty (don't ask me why it wasn't before). * fromParseResult now displays the filename in case of a failed parse. * A few bug fixes to the exact-printer (that not many seem to be using just yet). Please help me test and report! Grab a darcs version, put your source files in the Test/examples dir, and go cabal test (in the top dir). Any failing cases not due to CPP or literate source files (for the exact-printer), please report to the trac: http://trac.haskell.org/haskell-src-exts Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts-1.2.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.2.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts Version 1.2.0 is a new major release, following the PVP, as it contains a few backwards-incompatible changes, as well as some major changes that are supposedly backwards-compatible in theory, but as much of it is new and untested in practice there may be some regressions (bugs). The main new thing in 1.2.0 is the integration of the Annotated machinery into the package proper, for instance all parsing is now handled by the fully location-aware parser. haskell-src-exts-1.2.0: * Language.Haskell.Exts.Annotated.Simplify provides translation from an annotated AST to the old simple AST. * Behind-the-scenes integration of the new exact parser and lexer to do all parsing (using the above mentioned simplifier if the old AST version is requested). * All syntactic nodes now derive Eq, Ord and Show. * Pretty instance for SrcSpan. * Top-level expressions are now treated as implicit TH splice declarations (as per GHC HEAD). Note that this incurs a non-backwards-compatible change to the AST. * Empty data declarations may now have explicit kind annotations. * AST (and Pretty/Exact) support for kind variables (not yet parser support). * Error messages now extensively use prettyPrint instead of show for AST elements and locations, leading to way neater messages. * Bug fix to not crash ungracefully when encountering type equality predicates in proper types. * Liberalise line comments (as per GHC) to allow a line comment on the last line of a source file. Please help me test and report! Grab a darcs version, put your source files in the Test/examples dir, and go cabal test (in the top dir). Any failing cases not due to CPP or literate source files (for the exact-printer), please report to the trac: http://trac.haskell.org/haskell-src-exts Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts-1.2.0
* On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts Actually, it seems something went awry. I got a 500 Internal Server Error on my cabal upload, the package is there on hackage but it seems it was never added to the list of packages. This means cabal update doesn't know about it, nor is it listed on the What's New page. Anyone know what's up with that, and how it can be fixed? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pretty printing with comments
I'll see when I can get to fixing it, hopefully it won't be long. Two fairly easy bugs to fix, darcs repo is updated. It's probably high time I did another release, stay tuned. I just can't believe I didn't have a single class declaration in my test suite to catch the first one! Or that no one else triggered it before (I guess no one has actually started using exactPrint in their code yet). Thanks again for reporting! :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pretty printing with comments
Hi Pasqualino, I am looking at the haskell-src-ext library. It can parse files with comments and it can pretty print but, for what I can see it cannot do both :-) (prettyPrint won't work on the structure returned by parseFileWithComments). What you want is exactPrint, defined in Language.Haskell.Exts.Annotated.ExactPrint. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pretty printing with comments
Hi again,
However:
- The source code produced was incorrect:
class Dir d where
was rewritten as:
class Dir dwhere{
That's weird, I'll look into it, thanks.
instance Dir Directory where
localDir (Local f) = return f
type URL= String
was rewritten as:
instance Dir Directory where
localDir (Local f) = return f
typeURL= String
Sorry, I don't see the difference between these two. Did you write the
correct one twice by mistake?
Are these known bugs?
No, there are no known bugs so please report everything you find!
exactPrint is new and most likely sparsely used as of yet. I'd expect
there to be a few bugs lying around here and there, and I appreciate
all reports!
- Also, the printing is a bit too exact :-), I would like to keep my
comments AND get the code nicely reformatted.
Is there a way?
No. Like Lennart points out that's a really difficult problem, not to
say impossible, where do you place the comments after reformatting?
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pretty printing with comments
instance Dir Directory where localDir (Local f) = return f typeURL= String Sorry, I don't see the difference between these two. Did you write the correct one twice by mistake? In case Pasqualino doesn't see your mail real soon... Maybe the difference is the missing space between type and URL. Ah, of course, I see it now, thanks! Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pretty printing with comments
Hi again, I attach a source fragment and another file with the pretty printed output containing these three errors. Thanks, I've opened a ticket for this issue here: http://trac.haskell.org/haskell-src-exts/ticket/65 I'll see when I can get to fixing it, hopefully it won't be long. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can type be changed along a = chain?
On Mon, Oct 12, 2009 at 6:37 PM, michael rice nowg...@yahoo.com wrote:
transform :: IO ()
transform = putStrLn What is your digit string?
getLine
= \str - return ('9':str)
= \str - return (read str :: Int)
= \i - putStrLn $ The number is ++ show i
This code works perfectly for me. What problem are you seeing specifically?
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need some help with Alex macros
Hi all,
I'm going crazy trying to get Alex to do what I want. I have the
following regexp macros:
@octEscape = [0123]? $octdig{1,2}
@hexEscape = 'u' $hexdig{4}
@charEscape = '\\' (@octEscape | @hexEscape | b | t | n | f | r | \ | \')
and the following rules:
\' (. # [\'\\] | @charEscape) \' { \p s - CharTok (readCharTok s) }
\ (. # [\\\] | @charEscape)* \{ \p s - StringTok
(readStringTok s) }
I've tried a lot of variations on where to put the backslashes and
quotes to get it to do what I want, what you see above is just one
variation, but no matter what I try I can't get it to work.
alexScanTokens $ show '\n'
*** Exception: lexical error
Can anyone help shed some light on this for me? Why can't I get alex
to recognize escapes inside character literals?
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alex problem, help needed!!!!!!!!! ASAP :)
$digit+ { \p s - TokenEntero p (read s) }
\' [$alpha $digit \_]* \' { \p s - TokenString p (read s)}
[$digit]+\.[$digit]+ { \p s - TokenDouble p (read s) }
$alpha [$alpha $digit \_]*{ \p s - TokenVar p (read s) }
You are using 'read' in slightly strange ways here. What read does is
to take a string of characters that supposedly represents a value of
some type, and tries to create a value of said type from the string.
On the first and third lines you read a sequence of digits to an
integer resp double, which is fine, the strings you pass to 'read' are
representations of integers and doubles resp.
On the second line you're trying to read something of the form
'hello', i.e. surrounded by single-quotes, as a Haskell String. But
this doesn't represent a Haskell String, which is what 'read' expects.
Haskell Strings have double-quotes, so there will be no proper 'read',
if you want single-quotes you need to define your own function to do
the conversion (hint: init . tail).
On the last line, which is the one giving you the error here, you're
again trying to 'read' a string of characters into a String. And
again, Haskell Strings are surrounded by double-quotes, so 'read' will
not find a representation. This time the fix is even simpler. :-)
Prelude read hello :: String
*** Exception: Prelude.read: no parse
Prelude read \hello\ :: String
hello
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting data and function declarations over multiple files
Hi Peter, sounds to me you want to have a look at Open Data Types and Open Functions by Andres Löh and Ralf Hinze: http://people.cs.uu.nl/andres/OpenDatatypes.pdf Cheers, /Niklas On Wed, Sep 30, 2009 at 5:54 PM, Peter Verswyvelen bugf...@gmail.com wrote: I guess this is related to the expression problem. Suppose I have a datatype data Actor = Ball ... | Paddle ... | Wall ... and a function move (Ball ...) = move (Paddle ...) = move (Wall ...) = in Haskell one must put Actor and move into a single file. This is rather cumbersome if you work with multiple people or want to keep the files small and readable. Surely it is possible to use type classes, existentials, etc to split the data type into multiple ones, but that's already advanced stuff in a sense. But wouldn't it be possible to allow these to be put into multiple files, and let the compiler merge them back into one? A bit like C#'s partial keyword: in file Ball.hs: partial data Actor = Ball ... move (Ball ...) = in Paddle.hs partial data Actor = Paddle ... move (Paddle ...) = The compiler would then merge all partial data types and functions into one. As far as no overlap exists in the pattern matches in move, so that the order of the pattern matches does not matter at all, the partial trick should be possible no? Cheers, Peter ___ 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
[Haskell-cafe] ANN: haskell-src-exts-1.1.4
Fellow Haskelleers,
I'm pleased to announce the release of haskell-src-exts-1.1.4!
* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via cabal: cabal install haskell-src-exts
* Via darcs: darcs get http://code.haskell.org/haskell-src-exts
* Report bugs: http://trac.haskell.org/haskell-src-exts
haskell-src-exts is a package for Haskell source code manipulation. In
particular it defines an abstract syntax tree representation, and a
parser and pretty-printer to convert between this representation and
String. It handles (almost) all syntactic extensions to the Haskell 98
standard implemented by GHC, and the parsing can be parametrised on
what extensions to recognise.
haskell-src-exts-1.1.4 follows version 1.1.3 in being a mostly
experimental release. From a PVP perspective, the version number
indicates that no incompatible changes have been made to the *stable*
portion of the package, i.e. anything that doesn't contain Annotated
in its module name. The experimental stuff in
Language.Haskell.Annotated{.*} has changed quite a lot, but those of
you who depend on it already must obviously know what you're doing.
;-)
haskell-src-exts-1.1.4:
===
* For the stable part, the only new thing in haskell-src-exts-1.1.4 is
a bug fix that allows declaration headers surrounded by parentheses to
be parsed, e.g. data (a : b) =
* For the experimental part, the new and cool feature is a full
exact-printer, allowing full round-tripping of parsing plus printing.
In other words, using the parser and the exact-printer in conjunction
gives the same result back: exactPrint . parse == id . (Well, that's
half a lie since you need to use parseWithComments and some uncurrying
if you want to so easily compose, but that's the gist of it anyway.
:-))
* There have also been a number of further changes to the (annotated)
AST to allow it to retain enough source information to allow for said
exact-printing. In particular there have been changes to the way
contexts and declaration heads are treated, and literals have been
embellished to remember just how they were given (e.g. did we use 0xFF
or 255? \BEL or \a?).
* With a few small caveats, the round-tripping works over the full
(alas somewhat small) test suite that comes with (the darcs version
of) haskell-src-exts:
- Trailing whitespace on a line is not retained. (The test suite
uses reverse . dropWhile (isSpace) . reverse on each line to disregard
that issue.)
- Tab characters in the source are converted to (8) spaces (except
when they appear inside comments or literals). (The test suite doesn't
contain tabs.)
- Exact specification of literals is only remembered for literals
used as literals :-). What I mean is, source literals appearing in
other positions in the source than as Haskell literals will be
converted to a basic form. E.g. 'infixl 0x02 %%' will become 'infixl 2
%%'. Apart from infix declarations (tell me you never considered
writing them that way!) this mostly matters for various pragmas.
- Parentheses used around the function symbol in a function
declaration will not be remembered (I can't figure out how to make a
non-outrageous change to the AST to cope with them). E.g. '(foo a) b =
...' will be printed as 'foo a b = ...'. If anyone has an idea for a
neat (or at least non-outrageous) AST fix that could handle these
cases, drop me a line.
- Literate source files are not handled by the exact-printer (can't
re-literate them).
Please, help me test this on your source code! If you grab a darcs
version of the package from the repository, you can put any and all
source files you want to test in the haskell-src-exts/Test/examples
directory and then just run 'cabal test'. Please report any failing
cases to my trac! :-)
Cheers and Happy Haskelling,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: haskell-src-exts-1.1.4
Roundtrip is an important milestone for automated refactoring tools. Nice work! Thanks a lot! Refactoring was indeed the 'killer app' in mind when writing the exact-printer. For instance I don't expect it to be hard to get HLint to apply suggestions automatically now, instead of just suggesting them. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: haskell-src-exts-1.1.3
Oops, please consider this the announcement of the release of haskell-src-exts-1.1.3.1, since I stupidly forgot to add the new SrcLoc module to the list of exposed modules in cabal (why doesn't cabal warn about that? *grumble*). So those of you who already tried 1.1.3 it will have noticed that it failed to compile, sorry about that! On Sat, Aug 22, 2009 at 10:34 PM, Jeremy Shawjer...@n-heptane.com wrote: Does this mean that in the near future trhsx won't strip out all the haddock comments? That would be great. I can't promise about the *near* future, there's that little matter of time, but it's definitely the plan to turn trhsx over to the new cool machinery at some point, which will indeed allow it to retain all comments. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts-1.1.3
Fellow Haskelleers,
I'm pleased to announce the release of haskell-src-exts-1.1.3.
* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via darcs: darcs get http://code.haskell.org/haskell-src-exts
* Report bugs: http://trac.haskell.org/haskell-src-exts
haskell-src-exts is a package for Haskell source code manipulation. In
particular it defines an abstract syntax tree representation, and a
parser and pretty-printer to convert between this representation and
String. It handles (almost) all syntactic extensions to the Haskell 98
standard implemented by GHC, and the parsing can be parametrised on
what extensions to recognise.
haskell-src-exts-1.1.3 is a highly experimental release, which (apart
from a small bug fix, see below) doesn't do anything at all to the
current stable part of haskell-src-exts. But the release is far from
as boring as all that may sound, as it includes a whole new set of
modules implementing a new and more accurate syntax tree where all
nodes are adorned with annotations. Together with this comes a parser
that retains exact source information, stored in the aforementioned
annotations. There is also support for various precision for source
information, including SrcSpans. The new modules mirror the ones in
the stable part of haskell-src-exts but instead live in
Language.Haskell.Exts.Annotated{.Syntax,.Parser,...} (except that
SrcLoc and friends now have their own module).
The point of this release is that those of you that for one reason or
other are waiting for these features can help me look, feel, test and
comment these things in isolation, and hopefully report a lot of bugs,
before I integrate this stuff with the main haskell-src-exts body of
code. Note that that coming integration is intended to be
backwards-compatible, but a lot of the behind-the-scenes will be
switched over to the new and more general machinery.
Feature-wise, with this accurate source tree in hand, the next step is
to write a printer that uses the full location information to allow
full and exact round-tripping, i.e. (print . parse == id).
== haskell-src-exts-1.1.3 ==
* Adds support for more accurate, and fully annotated, abstract
syntax, see above.
* Fixes a bug that forced 'rec' statement groups to end with a
qualifier (like 'do').
Cheers and Happy Haskelling,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell code pretty printer ?
Hi Paul, is there a pretty printer for haskell code somewhere ? I've googled and caballisted for this without success. I've written some small script using Language.Haskell.Pretty and Language.Haskell.Parser but the result isn't that 'pretty'. I mean, it outputs readable code but supercombinator's definitions aren't separated by a blank line for instance (despite having put 'spacing' to 'True'). Do you know of such a tool ? haskell-src-exts [1] is probably as pretty as you get, but it doesn't differ much at all from haskell-src in its output. I'd be happy to have any specific complaints about it reported on my trac [2] though, I'm always keen to improve the product, and if you make your voice heard then chances are quite good that you get your wish. :-) Cheers, /Niklas [1] http://hackage.haskell.org/package/haskell-src-exts [2] http://trac.haskell.org/haskell-src-exts ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts-1.1.0
Fellow Haskelleers,
I'm pleased to announce the release of haskell-src-exts-1.1.0,
bringing you tuple sections, comments, and a few bug fixes.
haskell-src-exts is a package for Haskell source code manipulation. In
particular it defines an abstract syntax tree representation, and a
parser and pretty-printer to convert between this representation and
String. It handles (almost) all syntactic extensions to the Haskell
98 standard implemented by GHC, and the parsing can be parametrised on
what extensions to recognise.
haskell-src-exts 1.1.0:
===
* Adds rudimentary support for retaining comments while parsing a
source document. The support currently comes in the following form:
- The module Language.Haskell.Exts.Comments defines a datatype Comment
with two constructors denoting single-line (--) and multi-line ({- -})
comments.
- The Parseable class is extended with a function 'parseWithComments
:: Parseable ast = ParseMode - String - ParseResult (ast,
[Comment])' which simply returns all comments as a list alongside the
AST. There are also specialised versions for the usual suspects.
Example run:
HSE parseExpWithComments defaultParseMode 1 + {- comment -} 4 -- end\n
ParseOk (InfixApp (Lit (Int 1)) (QVarOp (UnQual (Symbol +))) (Lit (Int 4)),[Mu
ltiLine (SrcLoc {srcFilename = unknown.hs, srcLine = 1, srcColumn = 3}) co
mment ,SingleLine (SrcLoc {srcFilename = unknown.hs, srcLine = 1, srcColumn
= 19}) end])
This first release of comment support is as seen very rudimentary, but
I'm releasing it early in the hope that people who need features tied
to this will start looking at what's there and send me comments on
what further support they would like to see and consider missing.
* Support for TupleSections: http://hackage.haskell.org/trac/ghc/ticket/3377
* Fixes a bug where the statements of a list comprehension were
returned in the wrong order (oops!).
* Fixes a bug where function definitions were printed incorrectly when
using PPOffsideRule - thanks to Mathieu Boespflug for the patch.
* Fixes the broken 'cabal test' - thanks to Robin Green for the entire
test runner support!
Cheers and Happy Haskelling,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: haskell-src-exts-1.0.0
Hi Maurício, How far is Unicode from beeing parsed? It doesn't seem to be a huge step (from my ill-informed viewpoint), and it would not let behind those who are happy to be able to declare names in their own native language. (Oh, and sorry for resorting to politically correct blackmail...) Unicode in identifiers and symbols actually already works, assuming you don't use the non-Unicode-aware parseFile, parseFileWithExts or parseFileWithMode (which all use Prelude.readLine). What doesn't work is to use the Unicode versions of special symbols like -, = etc. I'm waiting for a stable and blessed unicode-aware text package to replace utf8-string, before we have one of those then my support would only be half-hearted at best. But in the mean time you can use the readLine provided by utf8-string, and then parseFileContents on that, which should give you the politically correct names. ;-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system trickery
Not nearly as annoying as this: data Foobar a where Foo :: X - Y - Foobar NoZoo Bar :: X - Y - Foobar NoZoo Zoo :: Foobar NoZoo - Foobar Zoo For some reason, if I do this I get endless type check errors. I have to change the top two back to Foobar a before it will work. *sigh* Well, that means something very different obviously. It means Zoo constructors can never take Zoo arguments, so you could only have at most one Zoo constructor at the outermost level, having either a Foo or a Bar inside it. Why would that give you type check errors? If it does, you're doing something else wrong. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts-1.0.0
Fellow Haskelleers, It is with great pleasure I hereby announce the first stable release of the haskell-src-exts package, version 1.0.0! haskell-src-exts is a package for Haskell source code manipulation. In particular it defines an abstract syntax tree representation, and a parser and pretty-printer to convert between this representation and String. It handles (almost(*)) all syntactic extensions to the Haskell 98 standard implemented by GHC, and the parsing can be parametrised on what extensions to recognise. I wish to thank the glorious Haskell community, for giving me the chance to work on this project as part of Haskell.org's GSoC programme, but also for simply being such a nice place to be! Special thanks to everyone who helped me with testing and bug reports during the final stretch of release candidates, in particular the many excellent reports from Ganesh Sittampalam, Sebastian Fischer, and Neil Mitchell who is also mentoring the project. You're all awesome! haskell-src-exts-1.0.0: = Via cabal: cabal install haskell-src-exts-1.0.0 Via darcs: darcs get http://code.haskell.org/haskell-src-exts On hackage: http://hackage.haskell.org/package/haskell-src-exts-1.0.0 Changes from 0.5.7, the last release candidate: == * CPP lines are no longer ignored, which means haskell-src-exts will now invariably give a parse error on files with CPP pragmas in them. CPP is not supported by haskell-src-exts, and this is more intuitive than parsing e.g. all branches of an #if pragma, which is invariably give unintended results. * Fixed a stupid introduced bug where extensions passed int he parse mode were ignored. * fromParseOk is now exported, not just defined (doh). * ScopedTypeVariables now implies TypeOperators, as per GHC. I'm sure there are more implications that are missing from haskell-src-exts, I will add them as I find out about them. Thanks once again, and Happy Haskell Hacking to all! Cheers, /Niklas (*) The only two exceptions are NewQualifiedOperators and UnicodeSyntax. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system trickery
On Sun, Jun 21, 2009 at 9:24 PM, Andrew Coppinandrewcop...@btinternet.com wrote: I have a datatype with about a dozen constructors. I'd like to find a way to use the type system to prevent one of the constructors from being used in certain places. But I can't think of a way to do that. data Foobar = Foo Foobar | Bar Foobar | Zoo Foobar I want the type system to track whether or not Zoo has been used in a specific value. Sure, you can check for it at runtime, but I'd be happier if the type system can guarantee its absence when required. That's what GADTs are for: data Flag = HasZoo | NoZoo data Foobar a where Foo :: Foobar a - Foobar a Bar :: Foobar a - Foobar a Zoo :: Foobar a - Foobar HasZoo f :: Foobar NoZoo - Int f foobar = ... -- foobar cannot be Zoo here Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system trickery
That's what GADTs are for: data Flag = HasZoo | NoZoo Eh, I wrote this a bit fast obviously (no dependent types here). Like Daniel Fischer wrote, these should rather be separate data types, i.e. data HasZoo data NoZoo The rest is still correct though. data Foobar a where Foo :: Foobar a - Foobar a Bar :: Foobar a - Foobar a Zoo :: Foobar a - Foobar HasZoo ...so I use Foobar x to mean any kind of value, Foobar NoZoo for a value that definitely doesn't contain Zoo, and Foobar HasZoo for... one that definitely does? Or maybe does? (Not that I care about this, but for completeness I'd like to know.) Yep, you are correct. Actually, you don't have to use NoZoo, you could use e.g. Foobar () or Foobar (Maybe Bool) if you like. Anything that isn't HasZoo. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Dear all, I'm pleased to announce to you haskell-src-exts-0.5.7, which is truly the first *real* release candidate for 1.0.0. By real, I mean that I could consider releasing it in this state. It is feature complete, fully documented, and has no remaining known bugs. But before I do, I'd like to run it past you all one final time. Please help me test it! Via cabal: cabal install haskell-src-exts Via darcs: darcs get http://code.haskell.org/haskell-src-exts On hackage: http://hackage.haskell.org/package/haskell-src-exts-0.5.7 Changes from 0.5.6: = Two small bug fixes: * Fixed a bug in the parser productions that made SCC pragmas virtually unusable. Note that this fix includes a change in the AST for expressions. * Fixed a bug in the fixity mangler where some subexpressions were left out. Three new features: * The partial 'unParseOk' is removed in favor of the total 'fromParseOk', which throws an error if the parse failed. * Defined 'glasgowExts' as the set of extensions enabled by GHC's -fglasgow-exts. You might typically want to use it together with 'parseFileWithExts', to get -fglasgow-exts as a default (since haskell-src-exts doesn't take OPTIONS_GHC pragmas into account). * Complete haddock documentation for the whole package. Please, help me one last time! :-) Cheers and thanks, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Hi all, Another day, another release candidate. Please see haskell-src-exts-0.5.5, 1.0.0 rc3. Thanks a lot to all reports, and please keep up the good work! Here we go again. Please have a look at haskell-src-exts-0.5.6, or 1.0.0 rc4. Thanks again for the reports, they're all truly invaluable. Changes in 0.5.6: === One major addition: * Support for relaxed layout in do-blocks! Yes, I caved in, after I got enough reports about it. Two stupid bugs fixed: * MagicHash ConId lexemes can now be followed by things other than space characters (like closing brackets: foo :: (Int#)). * ctypes (i.e. types with contexts and forall-quantifiers) can now appear inside tuples and lists if the proper extensions are on. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
I have just uploaded haskell-src-exts-0.5.4 to hackage, which is 1.0.0 rc2. Thanks a lot to those who tested the previous version, and please continue to test and report! Another day, another release candidate. Please see haskell-src-exts-0.5.5, 1.0.0 rc3. Thanks a lot to all reports, and please keep up the good work! Changes in 0.5.5: * BangPatterns are now correctly handled everywhere (I think - tricksy little imps they are). I would like to put out a special call for tests of files that use bang patterns, in particular if they appear in strange locations inside patterns. * TypeFamilies now implies KindSignatures, as in GHC. * Chained contexts, e.g. foo :: Eq a = Show a = a, are now handled correctly. * . is no longer considered a reserved operator but a special operator when explicit forall is enabled, which means Prelude.. now parses correctly. * Parenthesised patterns inside list patterns no longer require RegularPatterns enabled. * List expressions are no longer translated to tuple expressions by the fixity mangler (yes, it did that)... Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Hi Sebastian, This script may even simplify testing of large code bases: Thanks a lot, very useful! I'll add that to the darcs repository if you don't mind. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Hi all,
This means I feel ready to take that scary leap that means to drop the
safe 0.x version numbering (experimental) and finally make the first
stable release, version 1.0.0. But before I take that leap I want the
library to be thoroughly tested, so I can with confidence say that it
truly *is* stable. Therefore, I hereby announce the release on hackage
of haskell-src-exts-0.5.2, which I consider (almost) a release
candidate for 1.0.0.
I have just uploaded haskell-src-exts-0.5.4 to hackage, which is 1.0.0
rc2. Thanks a lot to those who tested the previous version, and please
continue to test and report!
Changes in 0.5.4:
==
Three fixed bugs:
* BangPatterns are now parsed correctly in function bindings.
* Single-item class contexts are now accepted with parenthesis around
them (doh!).
* The haddock documentation (paltry as it is) can now be built. Thanks
a lot to Brian Lewis for the patch, which rearranges my commented
guard clause. Haddock apparently didn't like the '{- | guard = ...'
line...
One new feature:
* The parseFileX family of functions now all recognize and act on
LANGUAGE pragmas (previously only parseFile did). There is now also an
extra field in the ParseMode called 'ignoreLanguagePragmas', which
defaults to False. Set it to True if you really want parseFile et al
to disregard LANGUAGE pragmas. (Note that you can always use the
simple 'parse' function that doesn't try to be clever at all.)
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Fellow Haskelleers, I'm pleased to report that I feel I have now completed the first milestone in my GSoC project for haskell-src-exts: Full Code Support. This means I feel ready to take that scary leap that means to drop the safe 0.x version numbering (experimental) and finally make the first stable release, version 1.0.0. But before I take that leap I want the library to be thoroughly tested, so I can with confidence say that it truly *is* stable. Therefore, I hereby announce the release on hackage of haskell-src-exts-0.5.2, which I consider (almost) a release candidate for 1.0.0. * Via cabal: cabal install haskell-src-exts * On Hackage: http://hackage.haskell.org/package/haskell-src-exts-0.5.2 * Via darcs: darcs get http://code.haskell.org/haskell-src-exts I would be delighted if as many as possible would consider testing it on their code, even those of you who feel that you may not have any immediate use of the library, just to cover as much code base as possible in the hunt for potential bugs and misfeatures. Testing it is really easy, four simple steps: cabal install haskell-src-exts [...] ghci [...] Prelude :m Language.Haskell.Exts Prelude Language.Haskell.Exts parseFile YourFileHere.(l)hs If you get a parse error on a file that you feel should have been accepted, let me know! If the parser gives you an AST result for a file that you feel it shouldn't have accepted, let me know! Here's the bug tracker: http://trac.haskell.org/haskell-src-exts/report/1 The reason I say it is almost a release candidate is that while I consider the functionality to be in place, I will tidy up the exports, add a few more convenient functions to export, and add a lot of documentation, before I make the actual release. If you have a request for a particularly conventient function to add to the list of exports from the package, it's thus not too late to get it into 1.0.0. :-) What's cool in haskell-src-exts-0.5.2: * Support for all syntactic extensions supported by GHC, with two exceptions: UnicodeSyntax and NewQualifiedOperators. These will likely be added in the next feature release. Exclusive support for the newly registered XmlSyntax and RegularPatterns extensions. No support (yet) for Hugs-specific extensions (RestrictedTypeSynonyms, ExtensibleRecords, HereDocuments). No support for CPP. Also does not support the GHC-specific relaxation of layout in do-blocks, which is an unregistered extension (that should be registered!). * Support for parametrising the parsing on what extensions it should recognise. With no extensions given, it assumes Haskell98. Note that 'parseFile' will look for language pragmas in your source file to decide what extensions to use when parsing. If you want to be explicit, you can use 'parseFileWithExts', or 'parseFileWithMode' that lets you set a few other things as well. I intend to add some convenient names of extension groups, such as 'ghcExtensions' and 'glasgowExts', this is one area where I would particularly welcome suggestions. * Support for correct fixities of infix operators. By default it uses the fixities defined in the Prelude, as well as in the current document (including local let-bound fixities). Use 'parseFileWithMode' to set a different set of fixities. Language.Haskell.Exts.Fixity defines preludeFixities and baseFixities (all fixities defined in the base package), as well as combinators for defining your own sets. Much thanks to Neil Mitchell for the meat of this code. * No (known) bugs! :-) Special note for users of HaRP/HSP: I've uploaded a new version of hsx, hsx-0.5.0, that works with haskell-src-exts-0.5.2. There is one known bug in this version though, it cannot handle 'proc' entities from the Arrows extensions, I'm still considering how to fix that. In the mean time you can use it just fine, as long as your files don't contain any 'proc' blocks (which the old version couldn't handle anyway). Cheers and happy Haskelling, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
* Via cabal: cabal install haskell-src-exts Thanks a lot to Brian Lewis for catching the first bug - cabal install doesn't even work for 0.5.2! The problem is that the cabal test machinery can't find the Language.Haskell.Exts modules, unless haskell-src-exts is already installed first... At any rate: I'm pleased to announce haskell-src-exts-0.5.3! Everything else from above still applies. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FlexibleContexts and FlexibleInstances
Hi Claus, What you describe is exactly how I would *want* things to work. It's nice to hear my wishes echoed from a user perspective. :-) On Wed, Jun 10, 2009 at 4:43 PM, Claus Reinkeclaus.rei...@talk21.com wrote: just a few comments from a user (who would really, really, like to be able to define pragma collections, so that he doesn't have to switch on half a dozen separate extensions every time;-). The following toy program requires MultiParamTypeClasses OR FlexibleContexts in order to be accepted by GHC(i): f :: (T a b) = a - Int f _ = 0 This of course assumes that we import the definition of T, we *must* have MultiParamTypeClasses enabled if we want to declare T. Both extensions thus enable classes with more than one argument to appear in contexts. Only MultiParamTypeClasses does (and neither extension is needed in the module defining 'f', if 'T' is imported, which suggests that MultiParamTypeClasses is propagated to importers - this isn't true for most other extensions). The documentation still points to -fglasgow-exts, so it doesn't seem to answer these questions.. Right you are - which seems very strange to me. GHC accepts the module defining 'f' with no flags at all, even though it is clearly not Haskell 98. I'd go so far as to say that's a bug (as opposed to just unwanted/unexpected behavior). f :: (T a ()) = a - Int f _ = 0 i.e. changing the second argument to T to () instead, means we now *must* have FlexibleInstances, in order to allow the non-tyvar argument. This is nothing surprising, this is what FlexibleInstances are supposed to do. You mean FlexibleContexts. Indeed I do. Now, FlexibleInstances *also* lifts the restriction on contexts, just like FlexibleContexts - but *only* for the contexts of instance declarations. No. FlexibleInstances is about instance *heads*, FlexibleContexts is about contexts everywhere (in practice, there are some bugs;-). Right, this is exactly what I *want* should happen, both as a user and as an implementor, but that's not how GHC does it. FlexibleInstances do enable FlexibleContexts for contexts in instance declarations - which I think is a wart. class T a b -- requires MultiParamTypeClasses instance T a a -- requires FlexibleInstances instance Eq () = T a [b] -- requires FlexibleContexts instance Eq [a] = T a b -- requires UndecidableInstances Agreed - but here you avoid the tricky cases like my 'f' above. ;-) What I would want, and what I believe you want as well, is the following: ** MultiParamTypeClasses: Enables more than one parameter in class declarations, instance heads and more than one argument to class assertions in contexts everywhere. Formally, it would mean the following changes to the Haskell 98 syntax: topdecl - class [scontext =] tycls tyvar1 ... tyvarn [where cdecls] (n =1) | instance [scontext =] qtycls inst1 ... instn [where idecls] (n =1) context - class | ( class1 , ... , classn ) (n=0) class - qtycls cls1 ... clsn(n=1) cls - tyvar | ( tyvar atype1 ... atypen ) (n=1) scontext- simpleclass | ( simpleclass1 , ... , simpleclassn ) (n=0) simpleclass - qtycls scls1 ... sclsn(n=1) scls - tyvar ** FlexibleContexts: Enables the use of non-tyvar (or tyvar applied to types) arguments to class assertions in contexts everywhere (orthogonal to whether there can be several arguments or just one). Formally it means the following syntactic changes to Haskell 98: fcontext- fclass | ( fclass1 , ... , fclassn ) (n=0) fclass - qtycls atype1 ... atypen (n=1) topdecl - data [fcontext =] simpletype = constrs [deriving] | newtype [fcontext =] simpletype = newconstr [deriving] | class [fcontext =] tycls tyvar [where cdecls] | instance [fcontext =] qtycls inst [where idecls] gendecl - vars :: [fcontext =] type for the single-argument case. (Note that I wrote type in my proposal in the OP, but it should of course be atype.) ** FlexibleInstances: Enables the use of arguments other than type constructors (possibly applied to tyvars) in instances *heads* (orthogonal to whether there can be one or more arguments, and what the context may look like). Formally it means the following syntactic changes to Haskell 98: topdecl - instance [scontext =] qtycls inst [where idecls] inst - atype for the single-parameter standard-context case. (Note again that it should be atype and not type as I wrote in the OP.) This of course only touches the syntactic part. It doesn't attempt to track things like 'instance (T a a) = R a b' that would be enabled by FlexibleContexts, nor does it attempt to track things like
[Haskell-cafe] FlexibleContexts and FlexibleInstances
Dear all, This post is partly a gripe about how poor the formal documentation for various GHC extensions is, partly a gripe about how GHC blurs the lines between syntactic and type-level issues as well as between various extensions, and partly a gripe about how the Haskell 98 report is sometimes similarly blurred where syntax is concerned (or not). All these things make the life of a poor parser implementor quite miserable at times. All in good jest of course, but with an edge of truth, especially regarding (lack of) formal documentation. The issue at hand which has caused my frustration is the FlexibleContexts [1] and FlexibleInstances [2] extensions, which lift restrictions imposed by Haskell 98 on the forms of contexts and instances that may be defined. Great extensions both of them - but what do they do, really really? The following toy program requires MultiParamTypeClasses OR FlexibleContexts in order to be accepted by GHC(i): f :: (T a b) = a - Int f _ = 0 This of course assumes that we import the definition of T, we *must* have MultiParamTypeClasses enabled if we want to declare T. Both extensions thus enable classes with more than one argument to appear in contexts. Changing the program to f :: (T a ()) = a - Int f _ = 0 i.e. changing the second argument to T to () instead, means we now *must* have FlexibleInstances, in order to allow the non-tyvar argument. This is nothing surprising, this is what FlexibleInstances are supposed to do. But the question is, is this a syntactic issue or a typing issue? In GHC proper this doesn't really matter much, as long as it is caught *somewhere* then all is dandy. GHC's parser lets everything pass, and it's the type checker that balks at this program. But for someone like me with *only* a parser, this is a question that needs a clear answer. Looking at the online report, the productions regarding contexts are context - class | ( class1 , ... , classn ) (n=0) class - qtycls tyvar | qtycls ( tyvar atype1 ... atypen ) (n=1) qtycls - [ modid . ] tycls tycls - conid tyvar - varid Ok, so clearly the () is a syntactic extension enabled by FlexibleContexts, as it is not a tyvar nor a tyvar applied to a sequence of types. So this is something that a parser should handle. FlexibleContexts also enables similar parses of contexts in other places, for instance in class declarations, for which the Haskell 98 report says topdecl - class [scontext =] tycls tyvar [where cdecls] scontext- simpleclass | ( simpleclass1 , ... , simpleclassn ) (n=0) simpleclass - qtycls tyvar The difference here is that the simpleclass doesn't allow the tyvar applied to a sequence of types bit. FlexibleContexts lifts that restriction too, so there should be no difference between the two kinds of contexts. So the new formal productions for flexible contexts should be something like fcontext- fclass | ( fclass1 , ... , fclassn ) (n=0) fclass - qtycls type1 ... typen (n=1) topdecl - data [fcontext =] simpletype = constrs [deriving] | newtype [fcontext =] simpletype = newconstr [deriving] | class [fcontext =] tycls tyvar [where cdecls] | instance [fcontext =] qtycls inst [where idecls] gendecl - vars :: [fcontext =] type Does this seem correct? Now let's turn to FlexibleInstances, which similarly lifts restrictions, only to instance declarations instead of contexts. The Haskell 98 report says on instance declarations: topdecl - instance [scontext =] qtycls inst [where idecls] inst- gtycon | ( gtycon tyvar1 ... tyvark )(k=0, tyvars distinct) | ( tyvar1 , ... , tyvark ) (k=2, tyvars distinct) | [ tyvar ] | ( tyvar1 - tyvar2 )(tyvar1 and tyvar2 distinct) Note the re-appearance of scontext, which is the same as above. The instance head must be a type constructor, possibly applied to a number of type variables, or one of three built-in syntactic cases. This is where I consider the Haskell 98 report blurry - the fact that the tyvars must be distinct, is that truly a syntactic issue? It might be, it's certainly something that could be checked syntactically. But when you take into account that with the proper extensions, they no longer need to be distinct, at what level would we expect such a check to happen? My gut feeling is that this check for distinctness is something that a type checker might do better than a parser, though it's not clear cut by any means. But since I don't do any other kind of name resolution or checking in my parser even if it would be possible (e.g. multiple declarations of the same symbol), I would find it a bit anomalous to check this too. Turning on FlexibleInstances, we shouldn't need to follow any of the above restrictions on
[Haskell-cafe] Re: ANN: New repository and trac for haskell-src-exts
Do you want people to cc bugs they want to vote for - like the GHC people do? Absolutely. Seeing the relative interest in various features would definitely be helpful in steering my (and others') efforts. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: New repository and trac for haskell-src-exts
Hi all, In preparation for my GSoC project, I've set up some new infrastructure for the haskell-src-exts package. Instead of residing with the HSP packages, it's now old enough to be allowed to live on its own. The new repository is darcs get http://code.haskell.org/haskell-src-exts I've also finally set up a bug tracker for all things big and small, found at http://trac.haskell.org/haskell-src-exts I've added all issues from my old TODO list, but I'm sure there's more stuff that I've missed. Please help me by reporting anything you come across, or by requesting new and cool features. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and braces
Hi Conor, Conor McBride: The trouble is, the production I've added causes a reduce/reduce conflict in the grammar, but I don't get any more precise complaint than that. To get more precise complaints, you should give the -i flag to happy, that will cause happy to print the whole parser table into a file named Parser.info. It also tells you in which states the conflicts occur, allowing you to track 'em down. I guess what I'd like to know is whether I just need to debug my grammar extension, or whether the notation I'm proposing actually introduces a serious ambiguity that I'm too dim to notice. I'm mostly sending this in the hope that I have one of those d'oh moments you sometimes get when you articulate a stupid question in public. I don't immediately see what the clash in that context would be - I *think* what you propose should be doable. I'd be interested to know what you come up with, or I might have a look at it myself when I find a few minutes to spare. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in HLint or haskell-src-exts?
Hi Martin, both of your problems are due to known deficiencies in haskell-src-exts, and I'm working on solving them. The first comes from its subpar handling of newtype deriving for MPTCs, the second from a weird case where you (currently) need spaces around -, i.e. in your example write (x - y) and HLint/haskell-src-exts will accept it. Thanks for reporting, /Niklas ps. I really ought to get myself a bug tracker... On Thu, Feb 26, 2009 at 10:49 PM, Martin Huschenbett hus...@gmx.org wrote: Hello again, I found another problem I dont understand: evalOp :: Op - (Integer - Integer - Integer) evalOp op = case op of Plus - (+) Minus - \x y - max 0 (x-y) Times - (*) brings a parse error, too: Interpreter.hs:92:3: Parse failure, Parse error in expression: DVar [Ident x,Ident ... The mentioned position is the T of Times in the last line. Regards, Martin. ___ 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] ANN: HDBC v2.0 now available
So in the next cabal-install release (which should be pretty soon now) configure will do the same thing and pick base 3 unless you specify build-depends base = 4. ... and so there will never be any incentive for these many packages to migrate to base-4, which also has consequences for packages that do want to use base-4, but also want to depend on such packages. And so base-3 will live on in eternity, and there was never any point in doing that new base release at all. I really really think this is the wrong way to go. Occasional destruction is desperately needed for progress, else things will invariably stagnate. I would suggest as a less stagnating approach to issue a warning/hint when a package with no explicit version dependency for base fails to build. The hint could suggest to the user trying to build the package that they can use 'cabal instal --package=base-3'. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HDBC v2.0 now available
I really really think this is the wrong way to go. Occasional destruction is desperately needed for progress, else things will invariably stagnate. I disagree. Having everything fail (we measured it as ~90% of hackage) when people upgraded to ghc-6.10 would have been a disaster. Do you recall the screaming, wailing and gnashing of teeth after the release of ghc-6.8 when most of hackage broke? We (I mean ghc and cabal hackers) got a lot of flak for not making the upgrade process easier and needlessly breaking everyone's perfectly good packages. 90%? That sounds like an awful lot for the relatively minor changes with base-4. I guess a number of packages will use exceptions, and others with use Data and Typeable, but 90%? I don't doubt you when you say that you measured it though, just marvelling. If 90% of hackage would truly break, then I agree that we might need more caution than my radical approach. But I'm not fully convinced there either. After all, unlike with the ghc-6.8 release, all that's needed for a package to work again is to upload a new .cabal that makes the dependency on base-3 explicit, if an author really doesn't want to update the codebase. And even for those packages where library authors don't do that simple step, all that's needed of the user of the library is to specify the base-3 constraint when running cabal-install. My main complaint is really that there is currently no incentive whatsoever for library authors to migrate. If we make base-4 the default, it will require just a little bit of work to make packages that depend on base-3 work anyway, as seen above. It's not so much work that it should incur any screaming, wailing and teeth gnashing. But it should be just enough work to encourage action in one way or another, either truly migrating the code or just making the dependency explicit as I noted above. I think it would be hard to find a more accurate, and non-intrusive, incentive. :-) I definitely agree with your suggestion to make hackage require an upper bound on base. But that's to make us future proof, it won't solve the issue here and now. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HDBC v2.0 now available
Thanks for the hint for folks. Why would cabal-install select a different base than running Setup manually? Someone thought it was a good idea to make base-3 the preferred selection for cabal-install, to make the transition from base-3 to base-4 as smooth as possible. It may have worked for that, but it's causing a lot of problems now instead. Time for a new policy/version for cabal-install? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I still think existential quantification is a step too far though. :-P Seriously, existential quantification is a REALLY simple concept, that you would learn week two (or maybe three) in any introductory course on logic. In fact, I would argue that far more people probably know what existential quantification is than that know what a monoid is. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sat, Jan 17, 2009 at 12:14 AM, Anton van Straaten
an...@appsolutions.com wrote:
I still think existential quantification is a step too far though. :-P
Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
on logic. In fact, I would argue that far more people probably know
what existential quantification is than that know what a monoid is.
:-)
Andrew's core objection here seems reasonable to me. It was this:
{-# LANGUAGE ExistentialQuantification #-} is an absurd name and
should be changed to something that, at a minimum, tells you it's
something to do with the type system.
But I suspect I part company from Andrew in thinking that something like
ExistentiallyQuantifiedTypes would be a perfectly fine alternative.
Well, I definitely agree to that, but that's not what he wrote in the
post I answered. My point was that existential quantification is
nowhere near scary.
But yes - making the Types part explicit is certainly not a bad idea.
+1 for ExistentiallyQuantifiedTypes.
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
