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

[Niklas Broberg]

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

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

Cheers, Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

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

[Niklas Broberg]

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

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

Cheers, Niklas

[1]
http://hackage.haskell.org/packages/archive/haskell-src-exts/1.13.5/doc/html/Language-Haskell-Exts-Parser.html#t:ParseMode
On 20 Aug 2013 12:57, "Dag Odenhall"  wrote:

> Good stuff!
>
> Is there any way, or plans for a way, to parse a file based on its
> LANGUAGE pragmas? Last I checked e.g. HSP simply enabled all extensions
> when parsing, which can cause code to be parsed incorrectly in some cases.
>
>
> On Tue, Aug 20, 2013 at 10:15 AM, Niklas Broberg  > wrote:
>
>> Fellow Haskelleers,
>>
>> I'm pleased to announce the release of haskell-src-exts-1.14.0!
>>
>> * On hackage: http://hackage.haskell.org/package/haskell-src-exts
>> * Via cabal: cabal install haskell-src-exts
>> * git repo: 
>> https://github.com/haskell-suite/haskell-src-exts<http://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

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

[Niklas Broberg]

Hi Niklas,

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

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

  f {- WHERE -} x = -- WOULD
  -- THESE
  do -- COMMENTS
 a {- END -} <- g x -- UP
 return {- ? -} a

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

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


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

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

Cheers, Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 1.14.0

[Niklas Broberg]

Fellow Haskelleers,

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

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

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

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

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

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


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


Complete changelog:

1.13.6 --> 1.14.0
===

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

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

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

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

* Support unboxed tuple expressions and patterns.

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

* Disallow negative primitive word literals
  (such as W# (-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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 1.13.5

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 1.13.3

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts-1.13.2

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts-1.13.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts-1.12.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 1.11.1

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 1.10.1

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts 1.9.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: ANN: haskell-src-exts-1.8.0

[Niklas Broberg]

> 1.7.2 --> 1.8.0
> ===

... and one more I forgot: Export 'knownExtensions' from .Extension.

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts-1.8.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: ANN: haskell-src-exts 1.7.0

[Niklas Broberg]

> * 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] ANN: haskell-src-exts 1.7.0

[Niklas Broberg]

>> * 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts 1.7.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: Functional Programming Bibliography

[Niklas Broberg]

>  > > Allow (registered?) users to submit links to papers that are missing?
>  >
>  > Yeah, I've certainly been thinking about that.
>  > First, I will somehow have to overcome being a complete control freak.
>  >
>  > The very first thought that crosses my mind is
>  > "how will I ensure that author names are well normalized?"
>  >
>  > Sad, isn't it?
>
> Not at all.  It takes a compulsive control freak to assemble a good
> bibliography.   Besides, I *want* the names to be well normalized.
> (If you'd seen the BibTeX entries that I get from my coauthors, you
> would know why...)

+1

However, I still think you should let users submit links. There are
really two different issues here, one is to suggest a completely new
paper, another is to provide a link to an already listed paper where
there's currently no link provided. A lot of the papers only have a
DOI link currently. Submitting such links won't need any name
normalization, as the paper is already listed.

For papers not already in your database, maybe have a two-tier system
where not-yet-checked entries are marked as such when they are shown?

Providing bibtex entries would be nice as well.

Cheers,

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: Functional Programming Bibliography

[Niklas Broberg]

> I am pleased to announce the Functional Programming Bibliography
> at http://www.catamorphism.net/

Awesome indeed!

> I am eager for suggestions as to how the site could be made more
> useful.

Allow (registered?) users to submit links to papers that are missing?

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] ANNOUNCE: SourceGraph-0.6.0.2

[Niklas Broberg]

> 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] ANN: Happstack 0.4.1

[Niklas Broberg]

>   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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts-1.3.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts-1.2.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] ANN: haskell-src-exts-1.1.4

[Niklas Broberg]

> 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts-1.1.4

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] ANN: haskell-src-exts-1.1.3

[Niklas Broberg]

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 Shaw 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts-1.1.3

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts-1.1.0

[Niklas Broberg]

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 = ".hs", srcLine = 1, srcColumn = 3}) " co
mment ",SingleLine (SrcLoc {srcFilename = ".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: 

* 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] Re: ANN: haskell-src-exts-1.0.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts-1.0.0

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)

[Niklas Broberg]

> 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)

[Niklas Broberg]

> * 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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)

[Niklas Broberg]

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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 0.4.8

[Niklas Broberg]

Fellow Haskelleers,

it is my pleasure to announce the new release of the haskell-src-exts
package, version 0.4.8:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.8
darcs get http://code.haskell.org/HSP/haskell-src-exts

This is a bug-fix release in the wake of the flurry of bug reports I
received due to Neil Mitchell's release of hlint. Not all bugs have
been squashed, but all the ones that I could handle with fairly small
changes to the library should be. Those include deriving for MPTCs,
importing constructor symbols, inline pragmas in instance
declarations, scoped type variables, and a few more. There are some
minor non-backwards compatible changes to the abstract syntax, but
nothing too serious. The most pervasive is that the Match and PatBind
constructors have an extra argument of type Maybe Type, representing
an optional type signature. Derivings also are no longer just a list
of class names, since those classes can now have extra parameters.

Four things remain on the bug list:
- Support for explicitly kinded arguments to type families. Shouldn't
be too hard, but will require changes to the AST that I will leave for
the next release.
- Support for (un-parenthesised) higher-ranked types as arguments.
haskell-src-exts supports e.g. foo :: b -> (forall a . [a]) -> b
but not foo :: b -> forall a . [a] -> b. Supporting the latter is
simply a parser issue, but a rather tricky one.
- Correct handling of hyphened vars (an artifact of HSX/HSP) vs minus
operators. This one is nasty.
- Support for Unicode symbols for e.g. ->. Fixing that would require
me to have a Unicode-compliant editor, which it appears I don't. And I
couldn't have someone else submit a patch either, since then I
couldn't open the file anymore in my editor. So unless someone can
point out a good Unicode-aware editor for Windows, I'm afraid this is
a feature that won't be implemented.

If you find anything else that haskell-src-exts fails on, please report it.

Cheers and Happy Haskelling,

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANN: HLint 1.0

[Niklas Broberg]

> Another parse error:
>
> newtype CodeGenModule a = CGM (StateT CGMState IO a)
>deriving (Monad, MonadState CGMState, MonadIO)

Thanks Lennart, another one on my plate, shouldn't be hard to fix.

Neil, your tool seems to be gold for finding bugs in HSE. :-)

Cheers,

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 0.4.4

[Niklas Broberg]

Fellow Haskelleers,

it is my pleasure to announce the new release of the haskell-src-exts
package, version 0.4.4:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.4
darcs get http://code.haskell.org/HSP/haskell-src-exts

The new feature in this release is support for pragmas.
haskell-src-exts-0.4.4 supports all pragmas supported by GHC, with the
exception of option-level pragmas (LANGUAGE, OPTIONS_GHC etc) that
appear before the module header. The reason these are not yet
supported is simply time, there's no real difficulty involved in
supporting them too and I will surely get there eventually.

0.4.4 is backwards incompatible with 0.4.3 for two constructors:
* The Module constructor (:: Module) now has an extra argument of type
'Maybe WarningText', used for deprecated modules.
* The ImportDecl constructor (:: ImportDecl) now has an extra argument
of type Bool, stating whether the SOURCE pragma has been used for the
import.

The full list of pragmas supported by 0.4.4 is: SOURCE, RULES,
DEPRECATED, WARNING, INLINE, NOINLINE, SPECIALISE, CORE, SCC,
GENERATED and UNPACK.

Cheers and Happy Haskelling,

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: haskell-src-exts 0.4.1

[Niklas Broberg]

Fellow Haskelleers,

it is my pleasure to announce the new release of the haskell-src-exts
package, version 0.4.1:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.1
darcs get http://code.haskell.org/HSP/haskell-src-exts

This is a new "major" release, the first of the 0.4 branch, and as
such it is not backwards compatible with the releases in the 0.3
branch. This is due to two major changes to the design of the library:

1) The AST has been cleaned up, by splitting Haskell expressions in
the AST from the "expressions" used while parsing to represent both
expressions and patterns. This means that the datatype for expressions
will no longer contain constructors for things like wildcards and
irrefutable patterns. It now only contains constructors for actual
Haskell expressions. If you have been using haskell-src-exts
previously, this change should not bite you at all unless you have
abused these ugly hacks in the AST, so it is *almost* backwards
compatible. However...

2) ... I've finally decided to take the plunge and get rid of the ugly
prefixes on all datatypes in the AST. I am of the firm conviction that
disambiguation between datatypes and functions with the same name
should be handled through the module hierarchy and qualified imports,
not by adding prefixes. And the longer I wait, the harder the switch.
So now the datatypes that make up the AST are called things like Exp,
Pat, Module (the former Module is now ModuleName), Type, QOp etc
instead of HsExp, HsPat... .

The migration from 0.3.x to 0.4.1 should be really simple:
i) replace all occurences of Module with ModuleName
ii) remove all occurences of Hs

This release also contains a number of smaller, fully backwards
compatible bug fixes. These are available for the 0.3 branch in the
0.3.12 release that will mark the end of that branch:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.12

No further bug fixes or features will be implemented for it, and I
urge you to migrate as early as possible, it really isn't hard. :-)

Cheers and Happy Haskelling,

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell

[Niklas Broberg]

> This could be a game changer.
>
>  Great work Andrew!!

Totally agreed, on both accounts. Really interesting to see.

>  -- Don

What, no Arch Linux port? :-)

Cheers,

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: Haskell Server Pages v 0.4

[Niklas Broberg]

Greetings fellow Haskelleers,

I am very pleased to announce a new chapter in the Haskell Server
Pages saga. After a two-year long hiatus, while we in the team have
been busy with Other Stuff, we have resumed work on Project HSP, and
this release marks the first milestone.


=
===  Project HSP  ===
=

Haskell Server Pages (HSP) is a programming model for writing dynamic
web pages in Haskell, both server-side and client-side. One of its
core features is the use of literal XML syntax mixed with ordinary
Haskell code.

* Project HSP home (with bug/feature tracker): http://code.google.com/p/hsp
* Project HSP mailing list: [EMAIL PROTECTED]
* Project HSP darcs repos: http://code.haskell.org/HSP

For flavor, here is a simple Hello World application written in HSP:
-
module HelloWorld where

import HSP
import HSP.HJScript
import HJScript
import HJScript.DOM

-- A simple HTML page holding a button with onClick action.
page :: HSP XML
page =
  

  Hello World


  <% click `onClick`
   (window # alert (string "Hello World !")) %>

  
-

Note that literal XML elements are first class expressions in HSP,
unlike languages like PHP. Also note that using literal XML syntax is
by no means required, if you don't feel like writing the XML manually
(I sure don't!). There are combinators for building XHTML pages
(although they are currently missing from version 0.4, will be added
shortly, but release early and all that...).


The most interesting new feature in version 0.4 is that literal XML
syntax (or the equivalent combinators) can now be used to create XML
elements both server-side and client-side, with the same code. Here is
another short example script showing this feature:
--
module AddParagraph where

import HJScript hiding (test)
import HJScript.DOM
import HSP
import HSP.HJScript

makeP x = <% x %>

page :: HSP XML
page =
  
Add paragraph
<% do
  (r,b) <- ref <%
 makeP "Paragraph created Server-side!"
%>
  let fun = do
   let x = document # getElementById (string r)
   x <: makeP "Paragraph created Client-side!"
   return ()
  b <: (Click Me! `onClick` fun)
 %>
   


Project HSP v 0.4 consists of a set of packages with related functionality:

== package hsx ==

Haskell Source with XML (HSX, hsx) is a package that contains
everything pertaining to literal XML syntax. In particular it contains
a) the trhsx preprocessor that translates hsx source files into
vanilla Haskell, and b) modules defining the functions that are
injected by trhsx. It also nominally contains generic combinators for
creating values of the same types as the literal XML syntax, though
these modules are not present in 0.4.

darcs get --partial http://code.haskell.org/HSP/hsx
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsx-0.4

== package hsp ==

The core HSP package defines the datatypes and functions for writing
server-side dynamic web pages. Also defines how to use the HJScript
functionality in HSP pages, to allow for client-side dynamics as well.

darcs get --partial http://code.haskell.org/HSP/hsp
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsp-0.4

== package HJavaScript ==

This package defines an abstract syntax and (not-so-)pretty printer
for a large subset of JavaScript, as Language.HJavaScript. However, a
significant difference from JavaScript is that HJavaScript is typed,
even on the abstract syntax level using GADTs. The subset of
JavaScript that is supported is those parts that lend themself to
typing (i.e. no prototyping of classes).

darcs get --partial http://code.haskell.org/HSP/hjavascript
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HJavaScript-0.4

== package HJScript ==

HJScript is a DSL built on top of HJavaScript, for writing client-side
dynamic web pages. The programming model is fairly low-level,
resembling the actual JavaScript code quite a lot, but should be easy
to extend with higher-level functionality. Notable is that HJScript
supports the use of literal XML syntax for creating DOM ElementNodes.
Also notable is that HJScript supports Ajax functionality.

HJScript and HJavaScript can be used independently of HSP, for
creating JavaScript code.

darcs get --partial http://code.haskell.org/HSP/hjscript
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HJScript-0.4

== package hsp-cgi ==

Run HSP pages as CGI scripts.

darcs get --partial http://code.haskell.org/HSP/hsp-cgi
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsp-cgi-0.4

(Note: Earlier versions of HSP have come with a server application,
hspr, providing the runtime environment for HSP. As of 0.4, this
server has been discontinued and should be considered deprecated.)

=

[Haskell] Re: ANN: haskell-src-exts 0.3.2

[Niklas Broberg]

>  I'm pleased to announce a new release for the haskell-src-exts package.

Twice in two days even. :-)

haskell-src-exts 0.3.3 - now with support for type equality constraints.

cabal sdist: 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.3
darcs repo: http://code.haskell.org/HSP/haskell-src-exts

Cheers,

/Niklas

>
>  haskell-src-exts 0.3.2
>  ===
>
>  haskell-src-exts is a package for handling and manipulating Haskell
>  source code. It is based on the haskell-src package that is part of
>  the standard libraries, but extends this to support a number of
>  syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is
>  intended as a drop-in replacement for the standard haskell-src
>  package, and exports the same functions and data types, plus some
>  more.
>
>  Apart from the more standard extensions supported by e.g. GHC,
>  haskell-src-exts also provides support for HaRP (Haskell Regular
>  Patterns) and HSX (Haskell Source with XML) syntax.
>
>  Note that as of 0.3, haskell-src-exts /= HSX.
>
>  * cabal sdist: 
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.2
>  * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts
>
>
>  === Changes from 0.2: ===
>
>  * Added support for
>   - Indexed type families (including associated types/datatypes)
>   - Explicit kind signatures
>   - Standalone deriving
>
>  * haskell-src-exts is now decoupled from hsx/trhsx and harp.
>   - Modules renamed to Language.Haskell.Exts.*
>   - Module Transform is removed from the package (now in package hsx)
>
>  * New repository (i.e. darcs pull in an old repo won't work, use darcs
>  get), containing only the haskell-src-exts package (no hsx or harp).
>
>  * Builds with 6.8.2 (thanks Duncan Coutts)
>
>
>  === Complete list of supported extensions ===
>
>  * Multi-parameter type classes (MPTCs)
>  * Functional dependencies
>  * Associated types, indexed type families
>  * Liberal class and instance heads
>  * Implicit parameters
>  * Explicit kind signatures
>  * Pattern guards
>  * Generalized algebraic data types (GADTs)
>  * Template Haskell (TH)
>  * Universal and existential quantification (forall)
>  * Empty data type declarations
>  * Unboxed tuples (# #)
>  * Standalone deriving
>  * Regular patterns
>  * Haskell XML, HSX style
>
>
>  === Build Requirements ===
>
>  * happy >= 1.17
>   - It might work with 1.16 though I haven't tested. In that case
>  change the cabal file.
>   - It would work with older versions as well, though they insert a
>  dependency on Array (haskell98) instead of Data.Array. If that's all
>  you have to work with, update the cabal file with a dependency on
>  haskell98.
>
>  * Cabal >= 1.2
>
>
>  Patches are more than welcome. :-)
>
>  Cheers,
>
>
>  /Niklas
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANN: haskell-src-exts 0.3.2

[Niklas Broberg]

Hi all,

I'm pleased to announce a new release for the haskell-src-exts package.

haskell-src-exts 0.3.2
===

haskell-src-exts is a package for handling and manipulating Haskell
source code. It is based on the haskell-src package that is part of
the standard libraries, but extends this to support a number of
syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is
intended as a drop-in replacement for the standard haskell-src
package, and exports the same functions and data types, plus some
more.

Apart from the more standard extensions supported by e.g. GHC,
haskell-src-exts also provides support for HaRP (Haskell Regular
Patterns) and HSX (Haskell Source with XML) syntax.

Note that as of 0.3, haskell-src-exts /= HSX.

* cabal sdist: 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.2
* darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts


=== Changes from 0.2: ===

* Added support for
  - Indexed type families (including associated types/datatypes)
  - Explicit kind signatures
  - Standalone deriving

* haskell-src-exts is now decoupled from hsx/trhsx and harp.
  - Modules renamed to Language.Haskell.Exts.*
  - Module Transform is removed from the package (now in package hsx)

* New repository (i.e. darcs pull in an old repo won't work, use darcs
get), containing only the haskell-src-exts package (no hsx or harp).

* Builds with 6.8.2 (thanks Duncan Coutts)


=== Complete list of supported extensions ===

* Multi-parameter type classes (MPTCs)
* Functional dependencies
* Associated types, indexed type families
* Liberal class and instance heads
* Implicit parameters
* Explicit kind signatures
* Pattern guards
* Generalized algebraic data types (GADTs)
* Template Haskell (TH)
* Universal and existential quantification (forall)
* Empty data type declarations
* Unboxed tuples (# #)
* Standalone deriving
* Regular patterns
* Haskell XML, HSX style


=== Build Requirements ===

* happy >= 1.17
  - It might work with 1.16 though I haven't tested. In that case
change the cabal file.
  - It would work with older versions as well, though they insert a
dependency on Array (haskell98) instead of Data.Array. If that's all
you have to work with, update the cabal file with a dependency on
haskell98.

* Cabal >= 1.2


Patches are more than welcome. :-)

Cheers,

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: GADT: call for proper terminology

[Niklas Broberg]

On 10/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Niklas Broberg wrote:
> Annotate the data type using a GADT:
> data MyData a where
>  MyCon :: MyData a

The range of the data constructor MyCon is the entire type MyData a --
so the above data type is the regular algebraic data type, and can be
written just as
data MyData a = MyCon
which, some say, makes the fact 'a' is phantom, and the overall intent
clearer.

One may hear phrases how generally awesome and indispensable GADT are;
it is distressing to realize then that sometimes (often?) one is
talking about regular algebraic data types, only in the `where'
syntax.

It helps to reduce confusion about the merits of various features and
additions to Haskell if we use the term GADT exclusively for truly
_generalized_ algebraic data types.


Right you are, I stand corrected.

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Classes with no data type

[Niklas Broberg]

|> Thus I have a typical classes problem, in that I have several
|> implementations of essentially the same function for different
|> circumstances.  The problem is, they must all operate on the same
|> data type, so I cannot define them as seperate instances.
|>
|> Anyone got any ideas how to type this?

Annotate the data type using a GADT:


{-# OPTIONS_GHC -fglasgow-exts #-}
module Foo where

data One
data Two

data MyData a where
 MyCon :: MyData a

con1 :: MyData One
con1 = MyCon

con2 :: MyData Two
con2 = MyCon

class Display a where

> display :: MyData a -> String


instance Display One where
display _ = "one"

instance Display Two where
 display _ = "two"


The annotations will tell you which constructor was used to create the
data, and you can implement destructor functions that can tell the
difference.

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Haskell web forum

[Niklas Broberg]

On 9/20/06, Aaron Denney <[EMAIL PROTECTED]> wrote:

And I disagree with you.  Web forums are usenet reinvented poorly.
It's impossible to keep track of what's new, threading is either poor or
nonexistent.  Mailing lists with searchable archives work well.  gmane
provides a nice usenet interface to mailing lists.


I don't recognize the forums I frequent in your description at all. I
have absolutely no problem keeping up with what's new. In fact I find
it a lot easier since many of the topics take place in subforums that
I know don't interest me, so I don't even need to go there to check.
With this mailing list, I have to manually "mark as read" about 2/3 of
all incoming mails because they don't (from the title) interest me,
and I have to read a few that don't interest me because I couldn't
tell from the title.

Threading also works as well as could be expected, better than
threading in gmail for instance, so I don't see the problem here
either.


> It's all there, all the time.

Yes, that's part of the problem.


How is that? You mean because all the old stuff gets in the way of the
new? Then you're just using a bad forum software that can't properly
point out the new stuff for you. I agree that not all forums are good,
but there are definitely those that are.


> It is also  easy to create sub-groups/forums for specific projects,

This is the one semi-useful thing.  Of course, what you end up with is
another not-so-useful forum.


This is probably the one most useful thing yes. I wouldn't call it
semi-useful though. Just remember all the responses that the HCAR gets
each year of the form "wow how many cool projects are out there that I
had no clue existed". What if all (or many of) those projects were
actually there, on the forums, where everyone knew where to look?

And your last sentence, I just don't understand. "not-so-useful" just
because it's a forum, or did you mean somethine else as well?

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Haskell web forum

[Niklas Broberg]

More potential than what we have already: http://dir.gmane.org/gmane.comp.lang.haskell.general >?


Yes. How could we use that to create subforums for particular projects
or subcommunities?

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Haskell web forum

[Niklas Broberg]

> i definitely think that to rise up Haskell popularity we need now to
> create web forum.

I disagree with this. I don't like web forums, I don't use web forums
if I can avoid it. They're way more work than mailing lists.


And I disagree with you. I don't like mailing lists, and I don't use
them if I can avoid it. They're way more work than web forums. For the
end user at least, if perhaps not for the administrator. ;-)

It is much easier to keep conversations in context in a forum, and to
search for old conversations. It's all there, all the time. It is also
easy to create sub-groups/forums for specific projects, which will
both increase their accessibility for the rest of the community, and
draw the interest of new developers.

A mailing list will never be enough. A forum has way way more potential.

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Haskell XML

[Niklas Broberg]

Hi Lucius,

my Haskell Source eXtensions [1] (which Neil suggested earlier)
supports expressions, values and pattern matching as language
constructs, but not types.

WASH [2] supports expressions, values and (to a limited extent) types,
but not pattern matching.

XHaskell [3] has the support necessary to get the typing right for
semi-structured data, but I don't know if they do anything explicitly
targetted at XML.

Hope that helps you some :-)

/Niklas

[1] http://www.cs.chalmers.se/~d00nibro/haskell-src-exts/
[2] http://www.informatik.uni-freiburg.de/~thiemann/WASH/
[3] http://www.comp.nus.edu.sg/~luzm/xhaskell/xhaskell.htm

On 8/30/06, Lucius Meredith <[EMAIL PROTECTED]> wrote:

Till,

i was looking for an OCamlDuce-like solution. The point there is that the
support is at the language level -- not library level. OCamlDuce has
language constructs -- values, type and pattern-matching specifically aimed
at XML processing. Thus, the OCamlDuce compiler catches many misuses, errors
invisible to a library-based approach.

The HXmlToolbox and HaXML are -- to the best of my knowledge --
library-based approaches, not language-level approaches.

Best wishes,

--greg


On 8/30/06, Till Mossakowski <[EMAIL PROTECTED]> wrote:
> There is also the Haskell XML Toolbox (HXT)
>
> http://www.fh-wedel.de/~si/HXmlToolbox/
>
> and HaXml
>
> http://www.cs.york.ac.uk/fp/HaXml/
>
> Could someone summarize the pros and cons of
> HXT versus HaXml versus HSX?
>
> Greetings,
> Till
>
> Neil Mitchell schrieb:
> > Hi Greg,
> >
> > I've been using Haskell Source eXtensions which seems to have as much
> > XML language support as you could ever possibly need :)
> >
> > http://www.cs.chalmers.se/~d00nibro/haskell-src-exts/
> >
> > Thanks
> >
> > Neil
> >
> > On 8/29/06, Lucius Meredith
<[EMAIL PROTECTED]> wrote:
> >> All,
> >>
> >> Apologies if this question has been beaten to death, but i'm wondering
if
> >> anyone out there has plans to do a language-level support for XML
> >> processing
> >> ala OCamlDuce. i would really like to be writing more code in Haskell,
> >> but
> >> XML is in almost everything i touch and OCamlDuce provides the right
> >> level
> >> of compiler support for the sorts of applications i'm writing.
> >>
> >> Best wishes,
> >>
> >> --greg
> >>
> >> --
> >> L.G. Meredith
> >> Partner
> >> Biosimilarity LLC
> >> 505 N 72nd St
> >> Seattle, WA 98103
> >>
> >> +1 206.650.3740
> >> ___
> >> Haskell mailing list
> >> Haskell@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell
> >>
> >>
> >>
> > ___
> > Haskell mailing list
> > Haskell@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell
>
>
> --
> Till MossakowskiOffice:  Phone +49-421-218-64226
> DFKI Lab Bremen CartesiumFax +49-421-218-9864226
> Robert-Hooke-Str. 5 Enrique-Schmidt-Str. [EMAIL PROTECTED]
> D-28359 Bremen  Room 2.051   http://www.tzi.de/~till
>
>



--
L.G. Meredith
Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103

+1 206.650.3740
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell




___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: ANNOUNCE: HNOP 0.1

[Niklas Broberg]

Well, we did have a serious SoC suggestion about the industrial Hello
World application, by Isaac Jones. I guess the industrial noop would
be just as good.

/Niklas

On 6/30/06, Krasimir Angelov <[EMAIL PROTECTED]> wrote:

There was lots of suggestions for the future development of HNOP. Is
it too late to propose Google SoC project for it? At least it will be
a good candidate for the next summer.

Cheers,
  Krasimir

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Trying On Learn Haskell Web Server

[Niklas Broberg]

Ehum, shameless plug. :)

On 3/6/06, Graham Klyne <[EMAIL PROTECTED]> wrote:
> Cale Gibbard wrote:
> > Ah, neat, I knew about WASH, but somehow I'd missed the fact that
> > there was a server there :)
>
> Interesting... at a casual glance, this looks as if it could be coming close 
> to
> being a "full stack web application framework" for Haskell, looking to occupy
> the same kind of territory as systems like Java/Servlets+JSP+the rest,
> Ruby/Rails or Python/Turbogears (the last a package I'm currently using).

Have you looked at HSP [1]? This is exactly what the HSP project aims
for, although there is quite some ways to go yet.

> I think see:
>   The web server
>   CGI process dispatching
>   Web page templating
>   Relational database access

All of these are present in HSP.

> Additional features of a full-stack web application framework that may or may
> not be present are:
>
> - Support for longer-running web processes (implemented in haskell, of course)

HSP has that.

> - An easy way to map incoming URIs to specific functions (hmm.. or to monadic
> values, I think)

I don't think I understand what you're after exactly, but I'm sure
it's interesting, care to explain a bit further? :-)

> - Easy mapping from Haskell data structures to underlying SQL - what would be
> called an Object-Relational Mapper (ORM) in OO languages

Some of our students are working on bringing the power of Ruby/Rails
to HSP, with emphasis on smooth database interfacing. Not sure exactly
what this entails though, I've never used Rails... :-)

>
> - Handling of interaction with a browser-side Javascript library for smoother
> AJAX support

This is not currently present in HSP, but they are surely on the
conceptual todo-list. There is a design for a crude JavaScript
support, but we'd certainly need more.

> - Options to run the whole thing behind Apache to leverage its security and 
> web
> space management capabilities

Lemmih has implemented a HSP/FastCGI binding for Apache. I also know
that work is being done on building a direct HSP/Apache binding. All
work in progress though.

> I think that continuation-based web session state management, ala
> Smalltalk/Seaside, would be a very natural fit for a Haskell framework -- all
> handled by a "Web session monad", maybe.  (Or maybe I just don't know what I'm
> talking about ;)

This is by far the biggest drawback of HSP today. There is no
high-level support for continuations (other than explicitly defined
continuations at top level).

> How far are we from having such a framework for Haskell?

Depends on how many people would be willing to invest time in it.
Right now we have students at Chalmers working on a project that aims
towards such a framework, but they can only do so much in the time
they have. We would surely welcome any help we could get. :-)

/Niklas

(ps. Going on vacation for 2 weeks in a few hours, so I'm not likely
to respond for a while... ;-))

[1] http://www.cs.chalmers.se/~d00nibro/hsp/
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCEMENT: HAskell Server Pages version 0.3.0

[Niklas Broberg]

> PS: I owe great thanks to Niklas Broberg for his excellent work on
> HSP. In truth, the idea of combining XML and Haskell I have through
> him, and I also adapted much of his code.

... and now it will be the other way around. :)

Lemmih's HASP is a strong evolution of HSP on the runtime side, and I
will incorporate much of his ideas into my HSPr implementation. Both
projects can be seen as implementations of "the language HSP", so the
APIs will be the same for the end users.

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Discrete event simulation

[Niklas Broberg]

> I'm wondering if there is work done about discrete event simulation in
> functional languages, and more specifically, Haskell DSLs.  Any pointers?

Check out Yampa: 
http://haskell.org/yampa/

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Announce: Haskell Server Pages 0.2

[Niklas Broberg]

> I'm having problems building hspr from the darcs repo. The
> HSPR.CGI.ErrorHandler module seems to be missing.

Indeed it was. Fixed now, thanks!

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Announce: Haskell Server Pages 0.2

[Niklas Broberg]

== Haskell Server Pages ==

Release early, release often. I know, I know, but better late than
never, so here it is:

Haskell Server Pages (HSP), a Haskell-based language for writing
dynamic web pages.
Webpage and darcs repo available at http://www.cs.chalmers.se/~d00nibro/hsp

Features:
* Embedded XML syntax
* A (low-to-mid-level) programming model for writing dynamic web pages
* A runtime system, in the guise of a server utility, with support for:
  - session (through cookies) and application (through the server) state
  - interfacing to the HTTP request-response model
  - on-request compilation of pages (using hs-plugins)
* A cgi-handler utility for use where the server can't be used (i.e.
if you have no control over the resident web server). Supports
everything the server does except application state and setting
outgoing headers (plus it is atm considerably slower to respond).

Things not working yet:
* The server /only/ handles .hsp-pages (i.e. no images or the like),
as it is intended to work as a plugin to general-purpose servers like
Apache or HWS that should handle any other file types. To properly
plug the HSP server in, I (or someone else so inclined) need to write
bindings to such servers, currently the server utility only works in
stand-alone mode.
* No support for POST data yet.
* Session handling needs improvement, currently session ids are
generated from 1 up (I thought the hashUnique function had a more
spread-out distribution...).
* Probably a lot more things that I cannot remember right now.

Things sorely missing:
* Libraries, libraries, libraries and more libraries.
* A "nice" model for continuations.

Comments, critique, patches or whathaveyou most welcome.

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Ann: haskell-src-exts 0.2

[Niklas Broberg]

Announcing haskell-src-exts 0.2:

http://www.cs.chalmers.se/~d00nibro/haskell-src-exts

haskell-src-exts (hsx) is an extension of the standard haskell-src
package, and handles most common syntactic extensions to Haskell,
including:

* Multi-parameter type classes with functional dependencies
* Empty data declarations
* GADTs
* Implicit parameters (ghc and hugs style)
* Template Haskell (broken for 6.4 atm, needs redoing)

and a few more. Apart from these standard extensions, it also handles
regular patterns  as per the HaRP extension
(http://www.cs.chalmers.se/~d00nibro/harp) as well as HSP-style
embedded XML syntax.

Source code available through darcs.

/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Announce: HaRP (Haskell Regular Patterns) version 0.2

[Niklas Broberg]

We have released a new version of HaRP.
Major updates are:
* A revised syntax.
* Regular patterns are now non-greedy by default.
More information and downloads can be found at
http://www.dtek.chalmers.se/~d00nibro/harp/
/Niklas Broberg
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1

[Niklas Broberg]

Dylan Thurston wrote:
So I guess that in
foo [/ a? 2 b /] = (a,b)
the type of a is '[Int]', not 'Maybe Int', right?
Aye. If you wanted Maybe Int, you would need to do
foo [/ [EMAIL PROTECTED] 2 b /] = (a,b)
I wrote:
> I'm starting to think maybe our context dependent approach to implicit
> bindings isn't very good after all since it seems to confuse a lot of
> people. Perhaps variables bound inside regular patterns should always be
> non-linear... of course that would still be context dependent when 
compared
> to normal Haskell patterns, but perhaps still less confusing?
Dylan Thurston wrote:
Alternatively, you could forbid the use of simple variables nonlinearly,
since there's an alternative way to write it.  Or, you could make
variables (and other pattern binding) more context dependent, recording
all the relevant parts of the context (and not just whether the context
is linear or not), if that makes sense.
Interesting issues, anyway!
Indeed they are.
We basically have two reasons for not wanting to record the context in bound 
variables.
The first is that it would not correspond very well with ordinary pattern 
matching, and we sought to minimize the differences by only adding the 
context dependence that was impossible to avoid.
The second is that there is a way to get at that context information 
already, by explicitly binding larger patterns (cf. the example above). In 
contrast, were we to record contexts in all bound variables there would be 
no way to avaid the context information should you want to. As an example

catMaybes :: [Maybe a] -> [a]
catMaybes [/ (Just a | Nothing)* /] = a
If we were to record the context in which a appears, we would have removed 
one data constructor (Just) but added another (Left).
Perhaps even more illustrating would be

catEithers :: [Either a a] -> [a]
catEithers [/ (Left a | Right a)* /] = a
Dylan Thurston wrote:
By the way, are nested regular expression matches allowed?  Something
like:
foo :: [[Int]] -> Int
foo [/ _* [/ 5* a 6* /] _* /] = a
Absolutely. We've added regular patterns as a new pattern category in 
Haskell, so anywhere that you can use a standard pattern you can use a 
regular pattern, including inside a regular pattern.

Dylan Thurston wrote:
?  If so, what is the type of a in
foo [/ _* [/ 5* a* /]* _* /]
?
It will be [[Int]]. a has type [Int] in the inner pattern, and in the outer 
pattern it appears in non-linear context (inside the *). Compare to

foo [/ _* (Just a@(_:_))* _* /] = a
Here the a clearly binds to a list in the inner expression, and in the 
regular pattern it appears in non-linear context. So here foo :: [Maybe [a]] 
-> [[a]]
As an aside, the patterns above will always give a the empty list since the 
first _* will "eat" the entire input, being greedy and all. But of course 
that won't affect the types...

With the package you can try out the types yourself. Just write these 
functions in a source file and load it into ghci following the guidelines on 
the homepage (http://www.dtek.chalmers.se/~d00nibro/harp/). Then you can let 
ghci infer the types for you. =)

/Niklas
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1

[Niklas Broberg]

What about
foo [/ (/ 2 (/ a _ /)* 3 /)* /] = a
?  What is the type of a here?  I think it should be [[Int]].
Not quite, the type of a will be [Int].
The only context dependency of variable types is the difference between 
linear and non-linear contexts. In linear context, variables have the types 
you would normally expect in standard Haskell. In non-linear context, the 
type is a list of what it would otherwise be, regardless of what and how 
many enclosing non-linear regular pattern operators.

If you want a full trace of where the items in a come from, you need to do 
it in several steps:

foo [/ (/ 2 b@:(/ _ _ /)* 3 /)* /] = map (map bar) b  -- here b :: [[[Int]]]
 where bar [a, _] = a
The reason for b having type [[[Int]]] is that it binds to a pattern of type 
[[Int]] (a repeating * enclosing a sequence).

In general: binding explicitly preserves the trace of the pattern it binds 
to; binding implicitly preserves no trace at all. To see why this is so, 
consider the following analogy:

bar :: Maybe (Maybe (Maybe Int)) -> (Maybe (Maybe Int), Maybe Int, Int)
bar (Just a@(Just b@(Just c))) = (a,b,c)
When binding a , you look at the type of the subpattern it binds to. When 
looking at the value held by a on the right hand side, there is no way to 
trace the context it appeared in before the pattern match.
When binding c, you also look at the subpattern it binds to, i.e. the 
pattern c is equivalent to the pattern [EMAIL PROTECTED] There is no trace of where it 
comes from.
Now look at this regular pattern:

foo [/ a@:(/ _ b@:(/ _ c /) /) /] = (a,b,c)
What is the type of foo?
Well, the type of c is whatever it binds to, which is just an element of the 
list (assuming Int). But since it is bound in non-linear context, its type 
will be [Int]. This form of context dependence is the only one we ever need 
to consider, where a variable is bound implicitly. And the only question is, 
does it have a list type or not? Another way to look at it is to see that c 
is equivalent to c@:_ in non-linear context and [EMAIL PROTECTED] in linear context.
b is bound explicitly using the @: operator, so the type of b is a list of 
whatever it binds to. No context dependence. What it binds to is a a 
sequence, i.e. a list, so the type of b will be [[Int]].
a is bound explicitly using the @: operator, so the type of a is a list of 
what it binds to. No context dependece here either. It too binds to a list, 
so its type will be [[Int]].
Thus,

foo :: ([[Int]], [[Int]], [Int])
And then which special syntax for implicit binding am I supposed to use?
Is it
foo [/ (/ 2 (/ a@:(/_ _/) _ /)* 3 /)* /] = a
or maybe
foo [/ (/ 2 (/ a@::(/_ _/) _ /)* 3 /)* /] = a
The former. We have added the @: operator as a a non-linear counterpart of 
the linear @. Adding more : won't add more levels of lists...

? And what's the type?  [[[Int]]]?
Not quite right here either, the type will be [[Int]]. The first enclosing 
list comes from the fact that the subsequence (/ ... /) has type list 
(whatever will be matched against it is a sequence of items), and the second 
enclosing list comes from the use of the non-linear binding operator @:.

Hopefully I make sense (more than before?).
I'm starting to think maybe our context dependent approach to implicit 
bindings isn't very good after all since it seems to confuse a lot of 
people. Perhaps variables bound inside regular patterns should always be 
non-linear... of course that would still be context dependent when compared 
to normal Haskell patterns, but perhaps still less confusing?

Anyway, thanks for the interest and the comments =)
/Niklas
_
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1

[Niklas Broberg]

ches of the sub-pattern, in this case all matches of 3.
d :: Maybe Int - d is bound to a zero-or-one pattern, and it will be Nothing 
in case of zero matches, and Just the match to the sub-pattern in case of a 
match, in this case 5.
e :: [[Int]] - e is bound to a zero-or-more pattern, and will thus contain a 
list of all the matches of the sub-pattern. In this case the sub-pattern is 
a sequence, which has a list type, so the type of e is a list of lists.
f :: [Int] - f is bound using the list-binding operator @:, so its type will 
always be a list of the type of the sub-pattern, regardless of the context 
it appears in. It will contain all matches of the sub-pattern (Note that a 
normal bind using @ would have been illegal here). At top level (and in 
ordinary pattern matching), the pattern foo is equivalent to [EMAIL PROTECTED], but 
inside numerating patterns the pattern foo is equivalent to foo@:_. (see 
discussion below)
g :: [Int] - g is equivalent to g@:_ as mentioned above, so the same will 
hold for g as for f.
h :: Either Int [Int] - h is bound to a choice pattern (or union pattern if 
you prefer), so it will be bound to the match of one of the two 
sub-patterns, annotated with Left or Right. In this case the left 
sub-pattern matches a single element of type Int, whereas the right 
sub-pattern matches a sequence of type [Int].
i :: [Int] - Since the choice pattern is numerating (each of the 
sub-patterns are matched zero or one times), i is equivalent to i@:_.

For completeness, another example to show how sequences work:
bar :: [Int] -> [Int]
bar [/ 0 a@(/ 1* 2 (3|4) (/ 5 6 /) 7? /) /] = a
In this case a will have the type [Int], since a sequence will always have 
the type [e] where e is the type of the elements of the list to match. So in 
this example,

?> bar [0,2,3,5,6]
[2,3,5,6]
?> bar [0,1,1,1,2,4,5,6,7]
[1,1,1,2,4,5,6,7]
A slightly more useful, real-life example:
Assume a config file (or the like) of the following form:
option-name : option-value
option-name : option-value
...
Parsing this into name-value pairs can be done like so:
parseConf :: String -> [(String, String)]
parseConf str =
 let [/ (/ names*? ' '* ':' ' '* vals*? '\n' /)* /] = str
  in zip names vals
Hopefully that's enough examples, it should be fairly clear how it all 
works. =)

Regarding @ vs @:, it would be fully possible to implement this just using @ 
and change its behavior depending on the context it appears in, much like we 
do with identifiers bound without using the explicit @ operator. We feel 
that doing so could lead to (even more) confusion regarding how variables 
are bound, and have therefore chosen to introduce the extra @: operator to 
make this differing behavior explicit. That identifiers bound without a @ or 
@: have differing semantics depending on context is unfortunate but 
unavoidable, and we feel that the added confusion is minor in this case.

Open issues:
* Greedy vs. non-greedy matching:
The current implementation is greedy by default, but some voices have been 
raised (on this list) that non-greedy matching would be better as default. 
After some initial use of the system we have also come to find that we tend 
to use non-greedy patterns far more often than their greedy counterparts. 
Unless we hear some convincing arguments not to, it is very likely that our 
next release will have non-greedy patterns as the default.

* Strings:
Strings are a special syntactic case of a list, and we are planning an 
analogous special case of regular patterns for it, for instance [s/ "Hello " 
a* /] would be equal to [/ 'H' 'e' 'l' 'l' 'o' ' ' a* /], but this is not 
yet implemented.

Any and all comments are welcome and appreciated,
Niklas Broberg, d00nibro[at]dtek.chalmers.se
Andreas Farre, d00farre[at]dtek.chalmers.se
Chalmers University of Technology
[1] XML processing is actually what we need these regular patterns for. Feel 
free to visit the project that lead to this spin-off, Haskell Server Pages, 
at http://www.dtek.chalmers.se/~d00nibro/hsp/

_
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Regular Patterns (RE: [Haskell] regular expression syntax)

[Niklas Broberg]

, i is equivalent to i@:_.

For completeness, another example to show how sequences work:
bar :: [Int] -> [Int]
bar [/ 0 a@(/ 1* 2 (3|4) (/ 5 6 /) 7? /) /] = a
In this case a will have the type [Int], since a sequence will always have 
the type [e] where e is the type of the elements of the list to match. So in 
this example,

?> bar [0,2,3,5,6]
[2,3,5,6]
?> bar [0,1,1,1,2,4,5,6,7]
[1,1,1,2,4,5,6,7]
Hopefully that's enough examples, it should be fairly clear how it all 
works. =)

Regarding @ vs @:, it would be fully possible to implement this just using @ 
and change its behavior depending on the context it appears in, much like we 
do with identifiers bound without using the explicit @ operator. We feel 
that doing so could lead to (even more) confusion regarding how variables 
are bound, and have therefore chosen to introduce the extra @: operator to 
make this differing behavior explicit. That identifiers bound without a @ or 
@: have differing semantics depending on context is unfortunate but 
unavoidable, and we feel that the added confusion is minor in this case.

As we said at the beginning we have implemented this as a preprocessor to 
ordinary Haskell, but it still needs some more alpha-testing before we 
release it... we need to catch the big fish first.

There are a number of open issues still, one is the choice of delimeter 
token. We have chosen to delimit patterns with just a whitespace, but using 
a comma might be better. The motivation for the current choice is that [/ a, 
b*, c /] lends the feeling that each pattern is an element of sorts, when in 
fact each pattern may represent any number of elements. Any input on this?

Another open issue is greedy vs. non-greedy matching of * and +. The current 
implementation is greedy, but some voices were raised earlier on this list 
that non-greedy matching would be better as default. We envision a system 
where you can choose behavior by adding "flags" to the pattern, i.e. [g/ 
 /] might indicate a greedy match etc.

Strings are a special syntactic case of a list, and we are planning a 
special case of regular patterns for it, for instance [s/ "Hello " a* /] 
would be equal to [/ 'H' 'e' 'l' 'l' 'o' ' ' a* /], but this is not yet 
implemented.

Of course, unfortunately, there is also a downside.
Our preprocessor is implemented by translating regular patterns into code in 
a parser monad. Due to the way that matching is done, matching will always 
be "strict" in the sense that if you apply the function

foo [/ a* /] = a

to an infinite list, the call will loop forever. At this point we see no 
reasonable way around this, there may be some special cases we can catch but 
we see no overall solution to the problem.

Another drawback, at least in our implementation, is efficiency. Using an 
external C engine for matching regular expression would far outperform our 
system, no matter how efficient we make our backend. Thus this is not 
intended to replace any existing functionality, rather we envision it as a 
very high-level interface to matching regular expressions in the spirit of 
String being [Char], where Text.Regex can be compared to using PackedString 
for critical programs.

Perhaps by integrating regular patterns directly into a compiler like ghc we 
could use ugly low-level behind-the-scenes tricks for doing the actual 
matching in an external engine, thus greatly increasing efficiency. Any 
thoughts? =)

We will supply the preprocessor for public scrutiny some time next week, we 
just need to do some more alpha-testing first... Comment away!

regards,

Niklas Broberg, d00nibro[at]dtek.chalmers.se
Andreas Farre, d00farre[at]dtek.chalmers.se
Chalmers University of Technology
[1] Feel free to also visit the project that lead to this spin-off, Haskell 
Server Pages
http://www.dtek.chalmers.se/~d00nibro/hsp/

_
Take off on a romantic weekend or a family adventure to these great U.S. 
locations. http://special.msn.com/local/hotdestinations.armx

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: type classes, superclass of different kind

[Niklas Broberg]

Robert Will wrote:

Now I would like to have Collection to be a superclass of Map yielding the
following typing
reduce :: (Map map a b) =>
  ((a, b) -> c) -> c
  -> map a b -> c
Note that in an OO programming language with generic classes (which is in
general much less expressive than real polymorphism), I can write
class MAP[A, B] inherit COLLECTION[TUPLE[A, B]]

which has exactly the desired effect (and that's what I do in the
imperative version of my little library).
There seems to be no direct way to achieve the same thing with Haskell
type classes (or any extension I'm aware of).  Here is a quesion for the
most creative of thinkers: which is the design (in proper Haskell or a
wide-spread extension) possibly include much intermediate type classes and
other stuff, that comes nearest to my desire?
I don't know if I qualify as the most creative of thinkers, but I have a 
small library of ADSs that you may want to look at, it's at

http://www.dtek.chalmers.se/~d00nibro/algfk/

I recall having much the same problem as you did, my solution was to make 
maps (or Assoc as I call them) depend on tuple types, i.e. (somewhat 
simplified):

class (Collection c (k,v), Eq k) => Assoc c k v where
 lookup :: k -> c (k,v) -> v
 [...many more member functions here...]
This means that the type constructors for maps and collections have the same 
kind (* -> *), which makes it possible for me to say that an Assoc is 
actually also a Collection. A lot more info to be found off the link.

I believe this question to be important and profound.  (We shouldn't
make our functional designs more different from the OO ones, than they
need to be.)  If I err, someone will tell me :->
No need to recreate all the stupid things the OO world has come up with, 
better to do it correctly right away... ;)

/Niklas Broberg, d00nibro[at]dtek.chalmers.se

_
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell