Re: [Haskell-cafe] Splittable random numbers

[Ryan Newton]

I'm not too familiar with all the Haskell API's for RNGs.  This is the first
time I've looked at CryptoRandomGen, but I can see the benefit of having a
bytestring interface rather than the System.Random Int based one.

Is there a reason that the AES implementation in the "AES" or "crypto"
packages can't be ripped out and repackage in the way you would like?

Cheers,
  -Ryan

On Fri, Jan 21, 2011 at 6:11 PM, Thomas DuBuisson <
thomas.dubuis...@gmail.com> wrote:

> Ryan,
> If you make an AES based RNG then consider making an instance for
> CryptoRandomGen (see DRBG [1] for example instances).  Such an
> instance means you can use "splitGen" [2], which can split generators
> in the manner described in this thread.  If you make the RNG match
> NIST SP 800-90 then feel free to send it to me for inclusion in the
> DRBG package, I've been meaning to make the block cipher based DRBG
> for a while now.
>
> Finally, any implementation of AES (using NI or not) could probably go
> in its own package or a cipher-specific package like CryptoCipher[3].
> Its a shame we don't have an AES implementation on Hackage that 1)
> exposes the fundamental block interface instead of some higher-level
> wrapping and 2) isn't tied to a large library.
>
> Cheers,
> Thomas
>
> [1] http://hackage.haskell.org/package/DRBG
> and
>
> http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/src/Crypto-Random-DRBG.html#HmacDRBG
> [2]
> http://hackage.haskell.org/packages/archive/crypto-api/0.3.1/doc/html/Crypto-Random.html#v:splitGen
> [3] http://hackage.haskell.org/package/cryptocipher
>
>
> On Fri, Jan 21, 2011 at 2:19 PM, Ryan Newton  wrote:
> > Hi cafe,
> >
> > I want to add the ability to use AES-NI instructions on Intel
> architectures
> > to GHC.  Mainly I'd like to do splittable random number generators based
> on
> > AES as was suggested at the outset of this email.  (I met Burton Smith
> last
> > week and this topic came up.)
> >
> > I was just reading the below thread about the plugin architecture which
> got
> > me thinking about what the right way to add AES-NI is.  (Disregarding for
> a
> > moment portability and the issue of where to test cpuid...)
> >
> >
> http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html
> >
> > The FFI is always an option.  But after reading the first N pages I could
> > come across from google I'm still not totally clear on whether "unsafe"
> > foreign calls can happen simultaneously from separate Haskell threads
> (and
> > with sufficiently low overhead for this purpose).
> >
> > I also ran across the phrase "compiler primitive" somewhere wrt GHC:
> >
> http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations
> >
> > Is that the right way to go?  Or would the compiler plugin mechanism
> > possibly allowing doing this without modifying mainline GHC?
> >
> > Thanks,
> >   -Ryan
> >
> > On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton 
> wrote:
> >>
> >> On 11/12/10 5:33 AM, Richard Senington wrote:
> >>>
> >>> It does not give the results you would want. This may have something to
> >>> do with picking "good" parameters for the mkLehmerTree function.
> >>> For example, using a random setup, I just got these results
> >>> result expected range
> >>> 16.814 expected = 16.0 (1,31)
> >>> 16.191 expected = 16.5 (1,32)
> >>> 16.576 expected = 17.0 (1,33)
> >>> 17.081 expected = 17.5 (1,34)
> >>> 17.543 expected = 18.0 (1,35)
> >>
> >> Have you run any significance tests? I wouldn't be surprised to see
> +/-0.5
> >> as within the bounds of expected randomness. I'm more worried about it
> >> seeming to be consistently on the -0.5 end of things, than I am about it
> not
> >> matching expectation (how many samples did you take again?). For small
> >> ranges like this, a consistent -0.5 (or +0.5) tends to indicate
> off-by-one
> >> errors in the generator.
> >>
> >> --
> >> Live well,
> >> ~wren
> >> ___
> >> Haskell-Cafe mailing list
> >> haskell-c...@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> >
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Release/git plans

[scooter . phd]

Llvm is also a good reference for compiler plugin design; it would appear that 
Scala borrowed from their approach.


-scooter
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: austin seipp 
Sender: glasgow-haskell-users-boun...@haskell.org
Date: Fri, 21 Jan 2011 17:59:32 
To: Simon Peyton-Jones
Cc: Simon Marlow; 
glasgow-haskell-users@haskell.org
Subject: Re: Release/git plans

Simon,

On Fri, Jan 21, 2011 at 3:13 AM, Simon Peyton-Jones
 wrote:
> Austin
>
> | So, given that 7.2 will be released much earlier than the normal
> | release cycle, is there any room for anything else to get into HEAD
> | for the 7.2 release before everything is switched? In particular I
> | fixed up Max Bolingbroke's old compiler plugin work to be usable with
> | the latest HEAD, and all the fundamental work is there and done, just
> | some additional small things are needed (notably having ghc dump
> | plugin information a la -ddump flags, and testsuite patches are about
> | it I think.) The patch itself is pretty small and doesn't touch *too*
> | much code, mostly adding dynamic loading and the plugin API, but it's
> | arguably adding a 'big' feature for users of GHC to start utilizing,
> | and perhaps a release in 7.2 would cause problems merging changes
> | until you cut a new STABLE branch with git, like you said.
>
> I'm sorry I've been slow on this.  "Review and apply the plugins patch" is in 
> my inbox, but it's been queued up behind too many other things, notably 
> making the new typechecker work.

That's fine! One thing at a time. The typechecker overhaul is great
IMO, and I've noticed it's fixed many strange GHC bugs relating to
type system feature interactions (including a few I hit.) Much
appreciated work!

> I'm pretty keen on the whole plugin idea, because it makes the compiler more 
> extensible and lowers the barrier to entry.  My only reason for delay is that 
> I wanted to review the design (as seen by a plug-in author).  Once we provide 
> it, we have to support it, and it's harder to change.

This is very reasonable and I was going to mention it once someone
responded. Up to this point, Max has really been the main person to
write any plugins for GHC using the current interface. I would really
welcome anybody interested in hacking on GHC look at the current API
in the patch - my main concern up to this point is that the actual
means of installing passes into the Core pipeline, the installation
function of type `[CoreToDo] -> CoreM [CoreToDo]`, is a little
fragile.

Scala's approach seems to be to have plugins specify 'runAfter' and
'runBefore' constraints, which specify what compiler phases should run
before and after the plugin's pass in question (and certain phases may
run multiple times, so as a consequence, so does your plugin.) If I
remember correctly, this was somewhat similar to the original design
Max proposed which was to specify in which phase the pass is run, and
it essentially amounted to a phase constraint. Perhaps Max can
elaborate on why this design was rejected in favor of the current one,
so we can see how and where it falls down, and what we really want.

Thomas pointed out the Scala compiler plugin design document, so I'll
be sure to read over it this weekend when I get the chance to cook up
ideas.

Also worth noting, like I said, is I would inevitably like to extend
compiler plugins to work on Cmm, once the new codegen (using hoopl)
hits. Maybe even allow you to write a new backend ultimately if you
wanted to, although I'd call that the last and ultimate challenge at
this point (because from my cursory glances, it would require quite a
bit of re-engineering and re-design of the driver and compilation
pipeline, much more so than just the Core plugins did or Cmm plugins
might. That's a bit more time than I have... at the moment ;)

To accumulate ideas and comments I've spent the past few days writing
up a wiki page (mostly written in the wee hours of the morning no
less), documenting the current API, how it might be improved, and
future work like C-- plugins or plugins implementing new backends.
Most of it is half baked. And half-written. Probably grammatical
errors and run-on sentences. Incomplete sections. Likely with big,
stupid ideas. Caveat emptor, etc.

The wiki page in all its (horrid, half-written and mangled) glory can
be located here:

http://hackage.haskell.org/trac/ghc/wiki/NewPlugins

If people can comment and add ideas, it will be much easier to
determine if this should go into 7.2.1. If the current API is too
fragile or needs to be expanded, it would likely be best to back out
and do some work, and try again for 7.4.1. That will also give a much
bigger window for feedback and testing, since 7.2 will be on a much
shorter cycle it seems.

I'll probably end up throwing up a RFC on both glasgow-haskell-users
and cvs-ghc sometime in the next week to get feedback after more
brainstorming, because it's the most important thing as of right now
and for any f

Re: Release/git plans

[austin seipp]

Simon,

On Fri, Jan 21, 2011 at 3:13 AM, Simon Peyton-Jones
 wrote:
> Austin
>
> | So, given that 7.2 will be released much earlier than the normal
> | release cycle, is there any room for anything else to get into HEAD
> | for the 7.2 release before everything is switched? In particular I
> | fixed up Max Bolingbroke's old compiler plugin work to be usable with
> | the latest HEAD, and all the fundamental work is there and done, just
> | some additional small things are needed (notably having ghc dump
> | plugin information a la -ddump flags, and testsuite patches are about
> | it I think.) The patch itself is pretty small and doesn't touch *too*
> | much code, mostly adding dynamic loading and the plugin API, but it's
> | arguably adding a 'big' feature for users of GHC to start utilizing,
> | and perhaps a release in 7.2 would cause problems merging changes
> | until you cut a new STABLE branch with git, like you said.
>
> I'm sorry I've been slow on this.  "Review and apply the plugins patch" is in 
> my inbox, but it's been queued up behind too many other things, notably 
> making the new typechecker work.

That's fine! One thing at a time. The typechecker overhaul is great
IMO, and I've noticed it's fixed many strange GHC bugs relating to
type system feature interactions (including a few I hit.) Much
appreciated work!

> I'm pretty keen on the whole plugin idea, because it makes the compiler more 
> extensible and lowers the barrier to entry.  My only reason for delay is that 
> I wanted to review the design (as seen by a plug-in author).  Once we provide 
> it, we have to support it, and it's harder to change.

This is very reasonable and I was going to mention it once someone
responded. Up to this point, Max has really been the main person to
write any plugins for GHC using the current interface. I would really
welcome anybody interested in hacking on GHC look at the current API
in the patch - my main concern up to this point is that the actual
means of installing passes into the Core pipeline, the installation
function of type `[CoreToDo] -> CoreM [CoreToDo]`, is a little
fragile.

Scala's approach seems to be to have plugins specify 'runAfter' and
'runBefore' constraints, which specify what compiler phases should run
before and after the plugin's pass in question (and certain phases may
run multiple times, so as a consequence, so does your plugin.) If I
remember correctly, this was somewhat similar to the original design
Max proposed which was to specify in which phase the pass is run, and
it essentially amounted to a phase constraint. Perhaps Max can
elaborate on why this design was rejected in favor of the current one,
so we can see how and where it falls down, and what we really want.

Thomas pointed out the Scala compiler plugin design document, so I'll
be sure to read over it this weekend when I get the chance to cook up
ideas.

Also worth noting, like I said, is I would inevitably like to extend
compiler plugins to work on Cmm, once the new codegen (using hoopl)
hits. Maybe even allow you to write a new backend ultimately if you
wanted to, although I'd call that the last and ultimate challenge at
this point (because from my cursory glances, it would require quite a
bit of re-engineering and re-design of the driver and compilation
pipeline, much more so than just the Core plugins did or Cmm plugins
might. That's a bit more time than I have... at the moment ;)

To accumulate ideas and comments I've spent the past few days writing
up a wiki page (mostly written in the wee hours of the morning no
less), documenting the current API, how it might be improved, and
future work like C-- plugins or plugins implementing new backends.
Most of it is half baked. And half-written. Probably grammatical
errors and run-on sentences. Incomplete sections. Likely with big,
stupid ideas. Caveat emptor, etc.

The wiki page in all its (horrid, half-written and mangled) glory can
be located here:

http://hackage.haskell.org/trac/ghc/wiki/NewPlugins

If people can comment and add ideas, it will be much easier to
determine if this should go into 7.2.1. If the current API is too
fragile or needs to be expanded, it would likely be best to back out
and do some work, and try again for 7.4.1. That will also give a much
bigger window for feedback and testing, since 7.2 will be on a much
shorter cycle it seems.

I'll probably end up throwing up a RFC on both glasgow-haskell-users
and cvs-ghc sometime in the next week to get feedback after more
brainstorming, because it's the most important thing as of right now
and for any future work in this area, in my opinion, since it will be
a publicly exposed API for users to write code against.

> The fact that you are actively engaged, have done the work with Max, and are 
> (I assume) happy to respond to user queries, fix bugs etc, is a major 
> incentive.  Thank you!

I'm more than happy to respond to any user queries and respond to bugs
people come up with, yes (Max seems to be w

Re: [Haskell-cafe] Splittable random numbers

[Thomas DuBuisson]

Ryan,
If you make an AES based RNG then consider making an instance for
CryptoRandomGen (see DRBG [1] for example instances).  Such an
instance means you can use "splitGen" [2], which can split generators
in the manner described in this thread.  If you make the RNG match
NIST SP 800-90 then feel free to send it to me for inclusion in the
DRBG package, I've been meaning to make the block cipher based DRBG
for a while now.

Finally, any implementation of AES (using NI or not) could probably go
in its own package or a cipher-specific package like CryptoCipher[3].
Its a shame we don't have an AES implementation on Hackage that 1)
exposes the fundamental block interface instead of some higher-level
wrapping and 2) isn't tied to a large library.

Cheers,
Thomas

[1] http://hackage.haskell.org/package/DRBG
and
http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/src/Crypto-Random-DRBG.html#HmacDRBG
[2] 
http://hackage.haskell.org/packages/archive/crypto-api/0.3.1/doc/html/Crypto-Random.html#v:splitGen
[3] http://hackage.haskell.org/package/cryptocipher


On Fri, Jan 21, 2011 at 2:19 PM, Ryan Newton  wrote:
> Hi cafe,
>
> I want to add the ability to use AES-NI instructions on Intel architectures
> to GHC.  Mainly I'd like to do splittable random number generators based on
> AES as was suggested at the outset of this email.  (I met Burton Smith last
> week and this topic came up.)
>
> I was just reading the below thread about the plugin architecture which got
> me thinking about what the right way to add AES-NI is.  (Disregarding for a
> moment portability and the issue of where to test cpuid...)
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html
>
> The FFI is always an option.  But after reading the first N pages I could
> come across from google I'm still not totally clear on whether "unsafe"
> foreign calls can happen simultaneously from separate Haskell threads (and
> with sufficiently low overhead for this purpose).
>
> I also ran across the phrase "compiler primitive" somewhere wrt GHC:
>     http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations
>
> Is that the right way to go?  Or would the compiler plugin mechanism
> possibly allowing doing this without modifying mainline GHC?
>
> Thanks,
>   -Ryan
>
> On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton  wrote:
>>
>> On 11/12/10 5:33 AM, Richard Senington wrote:
>>>
>>> It does not give the results you would want. This may have something to
>>> do with picking "good" parameters for the mkLehmerTree function.
>>> For example, using a random setup, I just got these results
>>> result expected range
>>> 16.814 expected = 16.0 (1,31)
>>> 16.191 expected = 16.5 (1,32)
>>> 16.576 expected = 17.0 (1,33)
>>> 17.081 expected = 17.5 (1,34)
>>> 17.543 expected = 18.0 (1,35)
>>
>> Have you run any significance tests? I wouldn't be surprised to see +/-0.5
>> as within the bounds of expected randomness. I'm more worried about it
>> seeming to be consistently on the -0.5 end of things, than I am about it not
>> matching expectation (how many samples did you take again?). For small
>> ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one
>> errors in the generator.
>>
>> --
>> Live well,
>> ~wren
>> ___
>> Haskell-Cafe mailing list
>> haskell-c...@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Splittable random numbers

[Ryan Newton]

Hi cafe,

I want to add the ability to use AES-NI instructions on Intel architectures
to GHC.  Mainly I'd like to do splittable random number generators based on
AES as was suggested at the outset of this email.  (I met Burton Smith last
week and this topic came up.)

I was just reading the below thread about the plugin architecture which got
me thinking about what the right way to add AES-NI is.  (Disregarding for a
moment portability and the issue of where to test cpuid...)

http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html

The FFI is always an option.  But after reading the first N pages I could
come across from google I'm still not totally clear on whether "unsafe"
foreign calls can happen simultaneously from separate Haskell threads (and
with sufficiently low overhead for this purpose).

I also ran across the phrase "compiler primitive" somewhere wrt GHC:
http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations

Is that the right way to go?  Or would the compiler plugin mechanism
possibly allowing doing this without modifying mainline GHC?

Thanks,
  -Ryan

On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton  wrote:

> On 11/12/10 5:33 AM, Richard Senington wrote:
>
>> It does not give the results you would want. This may have something to
>> do with picking "good" parameters for the mkLehmerTree function.
>> For example, using a random setup, I just got these results
>> result expected range
>> 16.814 expected = 16.0 (1,31)
>> 16.191 expected = 16.5 (1,32)
>> 16.576 expected = 17.0 (1,33)
>> 17.081 expected = 17.5 (1,34)
>> 17.543 expected = 18.0 (1,35)
>>
>
> Have you run any significance tests? I wouldn't be surprised to see +/-0.5
> as within the bounds of expected randomness. I'm more worried about it
> seeming to be consistently on the -0.5 end of things, than I am about it not
> matching expectation (how many samples did you take again?). For small
> ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one
> errors in the generator.
>
> --
> Live well,
> ~wren
>
> ___
> Haskell-Cafe mailing list
> haskell-c...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: backward compatibility

[Ian Lynagh]

On Fri, Jan 21, 2011 at 10:18:57AM +, Simon Marlow wrote:
> On 20/01/2011 20:22, Axel Simon wrote:
>
>> So, again, for this particular "extension" I suggest that the layout
>> rule in the standard(s) should be revised -- if I'm mistaken, this will
>> not break other programs.
>
> You've convinced me.  The benefit from "fixing" GHC in this case is  
> outweighed by the cost, I think we should revert the change (or at least  
> enable RelaxedLayout by default), and propose the change for Haskell  
> 2011/2012.  Ian, Simon, what do you think?

You mean NondecreasingIndentation, right? (RelaxedLayout only makes a
difference with explicit braces).

NondecreasingIndentation is already on by default; are you suggesting we
also add it to Haskell98 and Haskell2010?


Thanks
Ian


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Cleaning up after the Close button is pressed

[Simon Marlow]

On 20/01/2011 05:27, Colin Hume wrote:

Hi everyone,

I posted previously on haskell-beginners about an issue which would have
been better directed to this list. Since then, I have revisited the
issue and am now even less certain of its cause.

I have to perform cleanup when my application terminates.
GHC.ConsoleHandler handles cleanup from Ctrl-C and Ctrl-Break very
nicely under Windows. My sample handler and main function are shown at [1].

When I press Ctrl-C and Ctrl-Break during threadDelay, messages are
written to console_event.log as I expected. When I press the Close
button during threadDelay, no message is written to console_event.log.
Am I missing something fundamental about handling the Close button or
installing handlers?

In case it makes a difference, I'm using GHC 6.12.3 under Windows XP.


I don't know a great deal about this, but if you think it might be a bug 
please report it at


  http://hackage.haskell.org/trac/ghc/newticket?type=bug

giving as much information as you can.

Cheers,
Simon

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Release/git plans

[Thomas Schilling]

On 21 January 2011 09:13, Simon Peyton-Jones  wrote:

> I'm pretty keen on the whole plugin idea, because it makes the compiler more 
> extensible and lowers the barrier to entry.  My only reason for delay is that 
> I wanted to review the design (as seen by a plug-in author).  Once we provide 
> it, we have to support it, and it's harder to change.

The Scala compiler has a plugin system.  Here's a document that
describes their approach to dealing with phase ordering of plugins:
.  It seems rather complex, but seems
necessary (or the document is just very long).  There's also a
tutorial on writing Scala plugins, which may help to get a feel for
how their API works. 

/ Thomas

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: backward compatibility

[Simon Peyton-Jones]

| You've convinced me.  The benefit from "fixing" GHC in this case is
| outweighed by the cost, I think we should revert the change (or at least
| enable RelaxedLayout by default), and propose the change for Haskell
| 2011/2012.  Ian, Simon, what do you think?

I'm ok with that

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: backward compatibility

[Simon Marlow]

On 20/01/2011 20:22, Axel Simon wrote:


In the case of the layout "bug", I think it might be worth considering
going the other way: adjusting the standard with what ghc has always
done. If I understand correctly, all my code using:

foo = do
some computation
trace "I am here" $ do
some more computation

will break. I use this style of coding a lot to avoid too much
indentation and thus I would have to enable this extension everywhere
(and get warnings (or errors?) for older ghcs). Even if we had 2 or 3
implementations of Haskell 2010 in a decade, then they might not have
this extension. Furthermore, if they claim they actually do implement
the layout extension then they still might get it wrong in some subtle
way. An extension is never as well exercised as the non-extension part
of the compiler. I therefore think that keeping the number of extensions
to a minimum should be a high priority. It seems that the ghc team is
going overboard with the amount of extensions and their granularity that
I do not believe that there will ever be another compiler since
implementing all these extensions is a nightmare. The road of may
extensions is leading down the road that the Haskell standards aimed to
avoid: having a single implementation defining what a Haskell program
can be.

So, again, for this particular "extension" I suggest that the layout
rule in the standard(s) should be revised -- if I'm mistaken, this will
not break other programs.


You've convinced me.  The benefit from "fixing" GHC in this case is 
outweighed by the cost, I think we should revert the change (or at least 
enable RelaxedLayout by default), and propose the change for Haskell 
2011/2012.  Ian, Simon, what do you think?


Cheers,
Simon

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Release/git plans

[Simon Peyton-Jones]

Austin

| So, given that 7.2 will be released much earlier than the normal
| release cycle, is there any room for anything else to get into HEAD
| for the 7.2 release before everything is switched? In particular I
| fixed up Max Bolingbroke's old compiler plugin work to be usable with
| the latest HEAD, and all the fundamental work is there and done, just
| some additional small things are needed (notably having ghc dump
| plugin information a la -ddump flags, and testsuite patches are about
| it I think.) The patch itself is pretty small and doesn't touch *too*
| much code, mostly adding dynamic loading and the plugin API, but it's
| arguably adding a 'big' feature for users of GHC to start utilizing,
| and perhaps a release in 7.2 would cause problems merging changes
| until you cut a new STABLE branch with git, like you said.

I'm sorry I've been slow on this.  "Review and apply the plugins patch" is in 
my inbox, but it's been queued up behind too many other things, notably making 
the new typechecker work.

I'm pretty keen on the whole plugin idea, because it makes the compiler more 
extensible and lowers the barrier to entry.  My only reason for delay is that I 
wanted to review the design (as seen by a plug-in author).  Once we provide it, 
we have to support it, and it's harder to change.

The fact that you are actively engaged, have done the work with Max, and are (I 
assume) happy to respond to user queries, fix bugs etc, is a major incentive.  
Thank you!

So yes, because of that I undertake to do this for 7.2 [unless Simon M tells me 
no :-)].  I'll add a few thoughts to the ticket right now.  
http://hackage.haskell.org/trac/ghc/ticket/3843.  Interested parties, add 
yourselves to the cc list of the ticket.

Simon


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: backward compatibility

[Axel Simon]

On 21.01.2011, at 09:10, Simon Peyton-Jones wrote:


| So, again, for this particular "extension" I suggest that the layout
| rule in the standard(s) should be revised

Indeed I suspect the NonDecreasingIndentation change is a proposal  
for Haskell Prime pocess.  Or if it isn't it could be is if someone  
proposed it.  That's the process we have in place for changing the  
base language.




I have proposed to incorporate this extension into the Haskell standard.

Axel


Simon

| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Axel Simon
| Sent: 20 January 2011 20:23
| To: Simon Marlow
| Cc: GHC users
| Subject: Re: backward compatibility
|
| Hi Simon,
|
| On Jan 20, 2011, at 17:54, Simon Marlow wrote:
|
| > The layout fix is this change:
| >
| >
| http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37d
| 436cf6aac
| >
| > Another case where GHC was not strictly standards-compliant, and  
it

| > was fixed by adding a flag for the extension.
| >
| >
| > These were all bugs, but fixing them broke some code,
| > unfortunately.  In cases like this we *could* deprecate the
| > behaviour for one major release with a warning, before removing  
it.
| > However there's a non-trivial cost to doing so, and in some of  
these

| > cases it would have been quite awkward to implement the warning
| > (plus the cost of adding tests to make sure we actually got the
| > warning right; it's easy to introduce yet more bugs). Furthermore,
| > deprecations are often ignored, so sometimes the breakage is just
| > delayed.
| >
| > Hopefully that explains why sometimes we make breaking changes.   
If

| > the breaking change has a high enough impact, then it becomes
| > worthwhile to add backwards compatibility (via warnings /
| > deprecation or whatever). Of course from the point of view of the
| > user, the impact is always either high (it broke) or zero (it
| > didn't) :-)  We have to make a judgement as to whether we should
| > spend effort on backwards compatibility or not.  Perhaps we're
| > getting it wrong - so feedback from users is always valuable.
|
| I appreciate that you want to make ghc compliant to the standard.  
But

| to be honest, it is still the case that ghc defines the de-facto
| standard of what a Haskell program can be, since many programs do
| employ one or more ghc-only extensions.
|
| In the case of the layout "bug", I think it might be worth  
considering

| going the other way: adjusting the standard with what ghc has always
| done. If I understand correctly, all my code using:
|
| foo = do
|some computation
|trace "I am here" $ do
|some more computation
|
| will break. I use this style of coding a lot to avoid too much
| indentation and thus I would have to enable this extension  
everywhere
| (and get warnings (or errors?) for older ghcs). Even if we had 2  
or 3
| implementations of Haskell 2010 in a decade, then they might not  
have
| this extension. Furthermore, if they claim they actually do  
implement
| the layout extension then they still might get it wrong in some  
subtle
| way. An extension is never as well exercised as the non-extension  
part

| of the compiler. I therefore think that keeping the number of
| extensions to a minimum should be a high priority. It seems that the
| ghc team is going overboard with the amount of extensions and their
| granularity that I do not believe that there will ever be another
| compiler since implementing all these extensions is a nightmare. The
| road of may extensions is leading down the road that the Haskell
| standards aimed to avoid: having a single implementation defining  
what

| a Haskell program can be.
|
| So, again, for this particular "extension" I suggest that the layout
| rule in the standard(s) should be revised -- if I'm mistaken, this
| will not break other programs.
|
| Cheers,
| Axel
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: backward compatibility

[Simon Peyton-Jones]

| So, again, for this particular "extension" I suggest that the layout
| rule in the standard(s) should be revised 

Indeed I suspect the NonDecreasingIndentation change is a proposal for Haskell 
Prime pocess.  Or if it isn't it could be is if someone proposed it.  That's 
the process we have in place for changing the base language.

Simon

| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Axel Simon
| Sent: 20 January 2011 20:23
| To: Simon Marlow
| Cc: GHC users
| Subject: Re: backward compatibility
| 
| Hi Simon,
| 
| On Jan 20, 2011, at 17:54, Simon Marlow wrote:
| 
| > The layout fix is this change:
| >
| >
| http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37d
| 436cf6aac
| >
| > Another case where GHC was not strictly standards-compliant, and it
| > was fixed by adding a flag for the extension.
| >
| >
| > These were all bugs, but fixing them broke some code,
| > unfortunately.  In cases like this we *could* deprecate the
| > behaviour for one major release with a warning, before removing it.
| > However there's a non-trivial cost to doing so, and in some of these
| > cases it would have been quite awkward to implement the warning
| > (plus the cost of adding tests to make sure we actually got the
| > warning right; it's easy to introduce yet more bugs). Furthermore,
| > deprecations are often ignored, so sometimes the breakage is just
| > delayed.
| >
| > Hopefully that explains why sometimes we make breaking changes.  If
| > the breaking change has a high enough impact, then it becomes
| > worthwhile to add backwards compatibility (via warnings /
| > deprecation or whatever). Of course from the point of view of the
| > user, the impact is always either high (it broke) or zero (it
| > didn't) :-)  We have to make a judgement as to whether we should
| > spend effort on backwards compatibility or not.  Perhaps we're
| > getting it wrong - so feedback from users is always valuable.
| 
| I appreciate that you want to make ghc compliant to the standard. But
| to be honest, it is still the case that ghc defines the de-facto
| standard of what a Haskell program can be, since many programs do
| employ one or more ghc-only extensions.
| 
| In the case of the layout "bug", I think it might be worth considering
| going the other way: adjusting the standard with what ghc has always
| done. If I understand correctly, all my code using:
| 
| foo = do
|some computation
|trace "I am here" $ do
|some more computation
| 
| will break. I use this style of coding a lot to avoid too much
| indentation and thus I would have to enable this extension everywhere
| (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3
| implementations of Haskell 2010 in a decade, then they might not have
| this extension. Furthermore, if they claim they actually do implement
| the layout extension then they still might get it wrong in some subtle
| way. An extension is never as well exercised as the non-extension part
| of the compiler. I therefore think that keeping the number of
| extensions to a minimum should be a high priority. It seems that the
| ghc team is going overboard with the amount of extensions and their
| granularity that I do not believe that there will ever be another
| compiler since implementing all these extensions is a nightmare. The
| road of may extensions is leading down the road that the Haskell
| standards aimed to avoid: having a single implementation defining what
| a Haskell program can be.
| 
| So, again, for this particular "extension" I suggest that the layout
| rule in the standard(s) should be revised -- if I'm mistaken, this
| will not break other programs.
| 
| Cheers,
| Axel
| 
| 
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users