from:"Chris"

Oh, yes.  That looks great!  Also seems to work with OverloadedStrings
in the natural way in GHC 7.6, although that isn't documented.

Now if only it didn't force NoImplicitPrelude, since I really want to
-hide-package base and -package my-other-prelude.  Even adding
-XImplicitPrelude doesn't help.

On Tue, Jul 9, 2013 at 11:46 AM, Aleksey Khudyakov
alexey.sklad...@gmail.com wrote:
 On 08.07.2013 23:54, Chris Smith wrote:

 So I've been thinking about something, and I'm curious whether anyone
 (in particular, people involved with GHC) think this is a worthwhile
 idea.

 I'd like to implement an extension to GHC to offer a different
 behavior for literals with polymorphic types.  The current behavior is
 something like:

 Probably RebidableSyntax[1] could work for you. From description it
 allows to change meaning of literals.

 [1]
 http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/syntax-extns.html#rebindable-syntax

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

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

Re: [Haskell-cafe] Possible extension to Haskell overloading behavior

Oh, never mind.  In this case, I guess I don't need an extension at all!

On Tue, Jul 9, 2013 at 1:47 PM, Chris Smith cdsm...@gmail.com wrote:
 Oh, yes.  That looks great!  Also seems to work with OverloadedStrings
 in the natural way in GHC 7.6, although that isn't documented.

 Now if only it didn't force NoImplicitPrelude, since I really want to
 -hide-package base and -package my-other-prelude.  Even adding
 -XImplicitPrelude doesn't help.

 On Tue, Jul 9, 2013 at 11:46 AM, Aleksey Khudyakov
 alexey.sklad...@gmail.com wrote:
 On 08.07.2013 23:54, Chris Smith wrote:

 So I've been thinking about something, and I'm curious whether anyone
 (in particular, people involved with GHC) think this is a worthwhile
 idea.

 I'd like to implement an extension to GHC to offer a different
 behavior for literals with polymorphic types.  The current behavior is
 something like:

 Probably RebidableSyntax[1] could work for you. From description it
 allows to change meaning of literals.

 [1]
 http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/syntax-extns.html#rebindable-syntax

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

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

Re: [Haskell-cafe] Possible extension to Haskell overloading behavior

Ugh... I take back the never mind.  So if I replace Prelude with an
alternate definition, but don't use RebindableSyntax, and then hide
the base package, GHC still uses fromInteger and such from base even
though it should be inaccessible.  But if I do use RebindableSyntax,
then the end-user has to add 'import Prelude' to the top of their
code.  Am I missing something?

On Tue, Jul 9, 2013 at 1:51 PM, Chris Smith cdsm...@gmail.com wrote:
 Oh, never mind.  In this case, I guess I don't need an extension at all!

 On Tue, Jul 9, 2013 at 1:47 PM, Chris Smith cdsm...@gmail.com wrote:
 Oh, yes.  That looks great!  Also seems to work with OverloadedStrings
 in the natural way in GHC 7.6, although that isn't documented.

 Now if only it didn't force NoImplicitPrelude, since I really want to
 -hide-package base and -package my-other-prelude.  Even adding
 -XImplicitPrelude doesn't help.

 On Tue, Jul 9, 2013 at 11:46 AM, Aleksey Khudyakov
 alexey.sklad...@gmail.com wrote:
 On 08.07.2013 23:54, Chris Smith wrote:

 So I've been thinking about something, and I'm curious whether anyone
 (in particular, people involved with GHC) think this is a worthwhile
 idea.

 I'd like to implement an extension to GHC to offer a different
 behavior for literals with polymorphic types.  The current behavior is
 something like:

 Probably RebidableSyntax[1] could work for you. From description it
 allows to change meaning of literals.

 [1]
 http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/syntax-extns.html#rebindable-syntax

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

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

Re: [Haskell-cafe] Possible extension to Haskell overloading behavior

This is working now.  Trying to use -XRebindableSyntax with
-XImplicitPrelude seems to not work (Prelude is still not loaded) when the
exposed Prelude is from base, but it works fine when the Prelude is from a
different package.  Counterintuitive, but it does everything I need it to.
Thanks for the suggestion!
On Jul 9, 2013 4:20 PM, Aleksey Khudyakov alexey.sklad...@gmail.com
wrote:

 On 10.07.2013 01:13, Chris Smith wrote:

 Ugh... I take back the never mind.  So if I replace Prelude with an
 alternate definition, but don't use RebindableSyntax, and then hide
 the base package, GHC still uses fromInteger and such from base even
 though it should be inaccessible.  But if I do use RebindableSyntax,
 then the end-user has to add 'import Prelude' to the top of their
 code.  Am I missing something?

  If base is hidden GHCi refuses to start becaus it can't import Prelude
 (with -XNoImplicitPrelude it starts just fine).

 According to documentation GHC will use whatever fromInteger is in scope.
 But I never used extension in such way.

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

[Haskell-cafe] Possible extension to Haskell overloading behavior

2013-07-08 Thread Chris Smith

So I've been thinking about something, and I'm curious whether anyone
(in particular, people involved with GHC) think this is a worthwhile
idea.

I'd like to implement an extension to GHC to offer a different
behavior for literals with polymorphic types.  The current behavior is
something like:

1. Give the literal a polymorphic type, like (Integral a = a)
2. Type check the whole program, possibly giving the term a more
constrained type.
3. If the type is still ambiguous, apply defaulting rules.

I'd like to add the option to do this instead.

1. Take the polymorphic type, and immediately apply defaulting rules
to get a monomorphic type.
2. Type check the program with the monomorphic type.

Mostly, this would reduce the set of valid programs, since the type is
chosen before considering whether it meets all the relevant
constraints.  So what's the purpose?  To simplify type errors for
programmers who don't understand type classes.  What I have in mind is
domain-specific dialects of Haskell that replace the Prelude and are
aimed at less technical audiences - in my case, children around 10 to
13 years old; but I think the ideas apply elsewhere, too.  Type
classes are (debatably) the one feature of Haskell that tends to be
tricky for non-technical audiences, and yet pops up in very simple
programs (and more importantly, their error messages) even when the
programmer wasn't aware of it's existence, because of its role in
overloaded literals.

In some cases, I think it's a good trade to remove overloaded
literals, in exchange for simpler error messages.  This leaves new
programmers learning a very small, simple language, and not staring so
much at cryptic error messages.  At the same time, it's not really
changing the language, except for the need to explicitly use type
classes (via conversion functions like fromInteger) rather than get
them thrown in implicitly.  With GHC's extended defaulting rules that
apply for OverloadedStrings, this could also be used to treat all
string literals as Text, too, which might make some people happy, too.

Of course, the disadvantage is that for numeric types, you would lose
the convenience of overloaded operators, since this is only a sensible
thing to do if you're replacing the Prelude with one that doesn't use
type classes.  But in at least my intended use, I prefer to have a
single Number type anyway (and a single Text type that's not sometimes
called [Char]).  In the past, explaining these things has eaten up far
too much time that I'd rather have spent on more general skills and
creative activities.

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

Re: [Haskell-cafe] Possible extension to Haskell overloading behavior

2013-07-08 Thread Chris Smith

Oops, when I wrote this, I'd assumed it was possible to export
defaults from a module, like an alternate Prelude.  But it looks like
they only affect the current module.  So this whole thing depends on
also being able to either define defaults in an imported module, or in
options to GHC.

On Mon, Jul 8, 2013 at 12:54 PM, Chris Smith cdsm...@gmail.com wrote:
 So I've been thinking about something, and I'm curious whether anyone
 (in particular, people involved with GHC) think this is a worthwhile
 idea.

 I'd like to implement an extension to GHC to offer a different
 behavior for literals with polymorphic types.  The current behavior is
 something like:

 1. Give the literal a polymorphic type, like (Integral a = a)
 2. Type check the whole program, possibly giving the term a more
 constrained type.
 3. If the type is still ambiguous, apply defaulting rules.

 I'd like to add the option to do this instead.

 1. Take the polymorphic type, and immediately apply defaulting rules
 to get a monomorphic type.
 2. Type check the program with the monomorphic type.

 Mostly, this would reduce the set of valid programs, since the type is
 chosen before considering whether it meets all the relevant
 constraints.  So what's the purpose?  To simplify type errors for
 programmers who don't understand type classes.  What I have in mind is
 domain-specific dialects of Haskell that replace the Prelude and are
 aimed at less technical audiences - in my case, children around 10 to
 13 years old; but I think the ideas apply elsewhere, too.  Type
 classes are (debatably) the one feature of Haskell that tends to be
 tricky for non-technical audiences, and yet pops up in very simple
 programs (and more importantly, their error messages) even when the
 programmer wasn't aware of it's existence, because of its role in
 overloaded literals.

 In some cases, I think it's a good trade to remove overloaded
 literals, in exchange for simpler error messages.  This leaves new
 programmers learning a very small, simple language, and not staring so
 much at cryptic error messages.  At the same time, it's not really
 changing the language, except for the need to explicitly use type
 classes (via conversion functions like fromInteger) rather than get
 them thrown in implicitly.  With GHC's extended defaulting rules that
 apply for OverloadedStrings, this could also be used to treat all
 string literals as Text, too, which might make some people happy, too.

 Of course, the disadvantage is that for numeric types, you would lose
 the convenience of overloaded operators, since this is only a sensible
 thing to do if you're replacing the Prelude with one that doesn't use
 type classes.  But in at least my intended use, I prefer to have a
 single Number type anyway (and a single Text type that's not sometimes
 called [Char]).  In the past, explaining these things has eaten up far
 too much time that I'd rather have spent on more general skills and
 creative activities.

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

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

2013-06-02 Thread Chris Wong

 The C++/C function (e.g. toUppers) is computation-only and as pure as cos
 and tan. The fact that marshaling string incurs an IO monad in current
 examples is kind of unintuitive and like a bug in design. I don't mind
 making redundant copies under the hood from one type to another..

If you can guarantee that the call is pure, then you can execute it
directly using `unsafePerformIO`. Simply call the external function as
usual, then invoke `unsafePerformIO` on the result.

See 
http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/System-IO-Unsafe.html.

On another note, if you really care about performance, you should use
the `bytestring` and `text` packages instead of String. They are
implemented in terms of byte arrays, instead of linked lists, hence
are both faster and more FFI-friendly.




 On Sun, Jun 2, 2013 at 8:08 PM, Brandon Allbery allber...@gmail.com wrote:

 On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie tom.da...@gmail.com wrote:

 On 2 Jun 2013, at 16:48, Brandon Allbery allber...@gmail.com wrote:

 (String is a linked list of Char, which is also not a C char; it is a
 constructor and a machine word large enough to hold a Unicode codepoint. And
 because Haskell is non-strict, any part of that linked list can be an
 unevaluated thunk which requires forcing the evaluation of arbitrary Haskell
 code elsewhere to reify the value; this obviously cannot be done in the
 middle of random C code, so it must be done during marshalling.)


 I'm not convinced that that's obvious – though it certainly requires
 functions (that go through the FFI) to grab each character at a time.


 I think you underestimate the complexity of the Haskell runtime and the
 interactions between it and the FFI. Admittedly it is probably not obvious
 in the sense of anyone can tell without knowing anything about it that it
 can't possibly work, but it should be at least somewhat obvious to someone
 who sees why there needs to be an FFI in the first place that the situation
 is not trivial, and that they probably should not blindly assume that the
 only reason one can't just pass Haskell values directly to C is that some
 GHC developer was feeling lazy at the time.

 --
 brandon s allbery kf8nh   sine nomine
 associates
 allber...@gmail.com
 ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net



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




--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] question about GADT and deriving automatically a Show instance

2013-05-17 Thread Chris Wong

On Sat, May 18, 2013 at 9:11 AM, TP paratribulati...@free.fr wrote:

 So the following version does not work:
 
 [..]
 data Person :: Gender - * where
 Dead :: Person Gender  -- WHAT DO I PUT HERE
 Alive :: { name :: String
   , weight :: Float
   , father :: Person Gender } - Person Gender

Here's the problem. In the line:

Dead :: Person Gender

you are referring to the Gender *type*, not the Gender kind.

To refer to the kind instead, change this to:

Dead :: forall (a :: Gender). Person a

This means for all types A which have the kind Gender, I can give you
a Person with that type. The Alive declaration and deriving clause
can be fixed in a similar way.

Also, to enable the forall syntax, you need to add

{-# LANGUAGE ExplicitForAll #-}

at the top of the file.

Chris


--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-13 Thread Chris Wong

Oh, I see now. I originally made the runRobot functions reset the
input state when the Robot finished running. That worked well for my
use case (testing GUIs), but as you have noticed, it causes
unintuitive behavior when runRobot is called at a high frequency.

In hindsight, that was a design flaw on my part: that resetting
behavior should be specified explicitly, not attached unconditionally
to every call to runRobot.

I've removed the offending code, and released it as version 1.1.
Hopefully I've ironed out the issues now :)


On Mon, May 13, 2013 at 12:49 PM, Niklas Hambüchen m...@nh2.me wrote:
 Can you show me the code that triggers that behavior?

 It is basically

 Just connection - connect
 forever $ do
   (x,y) - getGyroMovement
   runRobotWithConnection (moveBy x y) connection



--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-13 Thread Chris Wong

I removed the functionality because I didn't really see a use for it
anymore. The `hold` and `tap` functions are already exception safe
(thanks to `bracket`), and anyone who uses the unguarded `press`
function probably wants to keep it held down anyway.

Chris


On Tue, May 14, 2013 at 12:46 PM, Niklas Hambüchen m...@nh2.me wrote:
 Awesome, that works very well, and it even made my program run faster /
 with less CPU.

 The reset functionality is useful, but I think optional is better. Did
 you remove it entirely or is it still available?

 On Tue 14 May 2013 08:25:04 SGT, Chris Wong wrote:
 Oh, I see now. I originally made the runRobot functions reset the
 input state when the Robot finished running. That worked well for my
 use case (testing GUIs), but as you have noticed, it causes
 unintuitive behavior when runRobot is called at a high frequency.

 In hindsight, that was a design flaw on my part: that resetting
 behavior should be specified explicitly, not attached unconditionally
 to every call to runRobot.

 I've removed the offending code, and released it as version 1.1.
 Hopefully I've ironed out the issues now :)


 On Mon, May 13, 2013 at 12:49 PM, Niklas Hambüchen m...@nh2.me wrote:
 Can you show me the code that triggers that behavior?

 It is basically

 Just connection - connect
 forever $ do
   (x,y) - getGyroMovement
   runRobotWithConnection (moveBy x y) connection



 --
 Chris Wong, fixpoint conjurer
   e: lambda.fa...@gmail.com
   w: http://lfairy.github.io/



--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-12 Thread Chris Wong

On Thu, May 9, 2013 at 1:36 PM, Chris Wong
chrisyco+haskell-c...@gmail.com wrote:
 On Thu, May 9, 2013 at 4:47 AM, Niklas Hambüchen m...@nh2.me wrote:
 Hi,

 I just started using your library to move my cursor.

 Is it possible that it ignores negative values in moveBy?

 In other words, I can only move the cursor into one direction.

 I did some research, and traced this to a bug in an old (1.6) version
 of xcb-proto [1]. The coordinates were declared incorrectly as Word16,
 instead of Int16 as they should have been. It's been fixed in
 xcb-proto since 1.7.

Okay, I've released a new version of Robot (1.0.1.1), that should fix
this bug. Niklas: can you try it out please?

Also, it turns out taking a screenshot is much easier than I thought.
A single call to getImage returns a list of bytes, which happens to
match exactly the internal structure used by JuicyPixels. I'll look
deeper into this when I get the time.

Chris

--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-12 Thread Chris Wong

On Sun, May 12, 2013 at 8:46 PM, Niklas Hambüchen m...@nh2.me wrote:
 Yes, that works now.

Excellent!

 I have another problem though: I move the cursor at high resolution
 (128 Hz) and it seems that when robot issues a command to X, it
 disables (keyboard) state so far. This means that it's impossible for
 me to Ctrl-C my program: Only c is sent all the time, me pressing
 Ctrl seems to be reset with the next robot event.

Can you show me the code that triggers that behavior?

--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-05-08 Thread Chris Wong

On Thu, May 9, 2013 at 4:47 AM, Niklas Hambüchen m...@nh2.me wrote:
 Hi,

 I just started using your library to move my cursor.

 Is it possible that it ignores negative values in moveBy?

 In other words, I can only move the cursor into one direction.

I did some research, and traced this to a bug in an old (1.6) version
of xcb-proto [1]. The coordinates were declared incorrectly as Word16,
instead of Int16 as they should have been. It's been fixed in
xcb-proto since 1.7.

I've cc'd Antoine Latter, the maintainer of XHB, about this bug. Once
he uploads a new version of XHB, I'll be happy to fix it on my end.

[1] 
http://cgit.freedesktop.org/~keithp/xcb-proto/commit/src/xtest.xml?id=f3ae971edce37ad96ef0b8a6059c1f853e88fcf3

On Tue, May 7, 2013 at 5:18 AM, Jeanne-Kamikaze
jeannekamik...@gmail.com wrote:
 Looks like an interesting library. Will it be able to read pixels from a
 window at some point?

Not sure -- I have no idea how screen capturing works in X11. Calling
gnome-screenshot should probably cover most use cases.

Chris

--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

2013-04-28 Thread Chris Smith

I think it's worth backing up here, and remembering the original point
of the proposal, by thinking about what is and isn't a goal.  I think
I'd classify things like this:

Goals:
- Use a lightweight, common, and familiar core syntax for simple formatting.
- Still allow haddock-specific stuff like links to other symbols.

Non-Goals:
- Compliance/compatibility with any specification or other system.
- Have any kind of formal semantics.

The essence of this proposal is about making Haddock come closer to
matching all the other places where people type formatted text on the
Internet.  As Johan said, markdown has won.  But markdown won because
it ended up being a collection of general conventions with
compatibility for the 95% of commonly used bits... NOT a formal
specification.  If there are bits of markdown that are just really,
really awkward to use in Haddock, modify them or leave them out.  I
think the whole discussion is getting off on the wrong start by
looking for the right specification against which this should be
judged, when it's really just about building the most natural possible
ad-hoc adaptation of markdown to documentation comments.  Just doing
the easy stuff, like switching from /foo/ to *foo* for emphasis,
really is most of the goal.  Anything beyond that is even better.

Compatibility or compliance to a specification are non-issues: no one
is going to be frequently copying documentation comments to and from
other markdown sources.  Haddock will unavoidably have its own
extensions for references to other definitions anyway, as will the
other system, so it won't be compatible.  Let's just accept that.

Formal semantics is a non-issue: the behavior will still be defined by
the implementation, in that people will write their documentation, and
if it looks wrong, they will fix it.  We don't want to reason formally
about the formatting of our comments, or prove that it's correct.
Avoiding unpleasant surprises is good; but avoiding *all* possible
ambiguous corner cases in parsing, even when they are less likely than
typos, is not particularly important.  If some ambiguity becomes a big
problem, it will get fixed later as a bug.

I think the most important thing here is to not get caught up in
debates about advanced syntax or parsing ambiguities, or let that stop
us from being able to emphasize words the same way we do in the whole
rest of the internet.

-- 
Chris Smith

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

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

2013-04-28 Thread Chris Smith

On Apr 28, 2013 6:42 PM, Alexander Solla alex.so...@gmail.com wrote:
 I think that much has to do with the historical division in computer
science.  We have mathematics on the right hand, and electrical engineering
on the wrong one.

I've been called many things, but electrical engineer is a new one!

My point was not anything at all to do with programming.  It was about
writing comments, which is fundamentally a communication activity.  That
makes a difference.  It's important to keep in mind that the worst possible
consequence of getting corner cases wrong here is likely that some
documentation will be confusing because the numbering is messed up in an
ordered list.

Pointing out that different processors treat markdown differently with
respect to bold or italics and such is ultimately missing the point.  For
example, I an aware that Reddit treats *foo* like italics while, say,
Google+ puts it in bold... but I really don't care.  What is really of any
importance is that both of them take reasonable conventions from plain text
and render them reasonably.  As far as I'm concerned, you can flip a coin
as to whether it ends up in bold or italics.

That doesn't mean the choices should not be documented.  Sure they should.
But it seems ridiculous to sidetrack the proposal to do something nice by
concerns about the minutiae of the syntax.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Markdown extension for Haddock as a GSoC project

2013-04-27 Thread Chris Smith

Oops, forgot to reply all.
-- Forwarded message --
From: Chris Smith cdsm...@gmail.com
Date: Apr 27, 2013 12:04 PM
Subject: Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
To: Bryan O'Sullivan b...@serpentine.com
Cc:

I don't agree with this at all.  Far more important than which convention
gets chosen is that Haskell code can be read and written without learning
many dialects of Haddock syntax.  I see an API for pluggable haddock syntax
as more of a liability than a benefit.  Better to just stick to what we
have than fragment into more islands.

I do think that changing Haddock syntax to include common core pieces of
Markdown could be a positive change... but not if it spawns a battle of
fragmented documentation syntax that lasts a decade.
On Apr 27, 2013 11:08 AM, Bryan O'Sullivan b...@serpentine.com wrote:

 On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley alist...@abayley.orgwrote:

 How's about Creole?
 http://wikicreole.org/

 Found it via this:

 http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/

 If you go with Markdown, I vote for one of the Pandoc implementations,
 probably Pandoc (strict):
 http://johnmacfarlane.net/babelmark2/

 (at least then we're not creating yet another standard...)

 Probably the best way to deal with this is by sidestepping it: make the
 support for alternative syntaxes as modular as possible, and choose two to
 start out with in order to get a reasonable shot at constructing a suitable
 API.

 I think it would be a shame to bikeshed on which specific syntaxes to
 support, when a lot of productive energy could more usefully go into
 actually getting the work done. Better to say prefer a different markup
 language? code to this API, then submit a patch!

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

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

[Haskell-cafe] ANN: Robot - Simulate keyboard and mouse events under X11

2013-04-22 Thread Chris Wong

I'm pleased to announce the initial release of Robot!

Robot lets you send fake keyboard and mouse events, just like its
namesake in Java.

Only X11 systems are supported right now (via XTest), but Windows and
Mac can be added later if anyone cares.


## Features

+ Simple API (only 9 functions and 3 types)

+ Few dependencies

+ Exception safe -- unlike with other libraries, all keys and buttons
are released automatically when the robot terminates. `bracket` and
`finally` are used where appropriate.


## Links

Hackage: http://hackage.haskell.org/package/robot-1.0

Examples: https://github.com/lfairy/robot/tree/master/examples


Happy hacking!
Chris

--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] Fwd: [Haskell-beginners] Monad instances and type synonyms

2013-04-14 Thread Chris Wong

On Sun, Apr 14, 2013 at 5:10 PM, Christopher Howard
christopher.how...@frigidcode.com wrote:
 type Adjustment a = SaleVariables - a

 [...]

 instance Monad Adjustment where

   (=) = ...
   return = ...

Essentially, you can't partially apply type synonyms. I don't recall
the exact reasoning, but if this sort of thing was allowed it would
probably poke funny holes in the type system.

Also, Control.Monad.Instances already supplies a Monad instance for
functions (r - a). So even if that did pass, you'd bump into
overlapping instances anyway.

Chris

 
 If I try this, I get

 code:
 
 Type synonym `Adjustment' should have 1 argument, but has been given none
 In the instance declaration for `Monad Adjustment'
 

 But if I give an argument, then it doesn't compile either (it becomes a
 * kind). And I didn't want to make the type with a regular data
 declaration either, because then I have to give it a constructor, which
 doesn't fit with what I want the type to do.

 --
 frigidcode.com

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


--
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] unsafeInterleaveST (and IO) is really unsafe [was: meaning of referential transparency]

2013-04-12 Thread Chris Smith

On Fri, Apr 12, 2013 at 1:44 AM,  o...@okmij.org wrote:
 As to alternatives -- this is may be the issue of
 familiarity or the availability of a nice library of combinators.

It is certainly not just a matter of familiarity, nor availability.
Rather, it's a matter of the number of names that are required in a
working set.  Any Haskell programmer, regardless of whether they use
lazy I/O, will already know the meanings of (.), length, and filter.
On the other hand, ($), count_i, and filterL are new names that must
be learned from yet another library -- and much harder than learned,
also kept in a mental working set of fluency.

This ends up being a rather strong argument for lazy I/O.  Not that
the code is shorter, but that it (surprisingly) unifies ideas that
would otherwise have required separate vocabulary.

I'm not saying it's a sufficient argument, just that it's a much
stronger one than familiarity, and that it's untrue that some better
library might achieve the same thing without the negative
consequences.  (If you're curious, I do believe that it often is a
sufficient argument in certain environments; I just don't think that's
the kind of question that gets resolved in mailing list threads.)

-- 
Chris Smith

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

Re: [Haskell-cafe] GSOC application level

2013-03-06 Thread Chris Smith

Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote:

 I know that this year's projects aren't up
 yet

Just to clarify, there isn't an official list of projects for you to choose
from.  The project that you purpose is entirely up to you.  There is a list
of recommendations at
http://hackage.haskell.org/trac/summer-of-code/report/1 and another list of
ideas at http://reddit.com/r/haskell_proposals -- but keep in mind that you
ultimately make your own choice about what you propose, and it doesn't have
to be selected from those lists.  You can start writing your perusal today
if you like.

Having an unusually good idea is a great way to get selected even if you
don't have an established body of work to point to.  Just keep in mind that
proposals are evaluated not just on the benefit if they are completed, but
also on their likelihood of success... a good idea is both helpful and
realistic.  They are also evaluated on their benefit to the actual Haskell
community... so of that's not something you have a good fell for, I'd
suggest getting involved.  Follow reddit.com/r/haskell, read this mailing
list, read Haskell blogs from planet.haskell.org, and get familiar with
what Haskellers are concerned about and interested in.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules

2013-02-28 Thread Chris Wong

On Thu, Feb 28, 2013 at 1:26 PM, Brandon Allbery allber...@gmail.com wrote:
 On Wed, Feb 27, 2013 at 8:37 AM, Corentin Dupont corentin.dup...@gmail.com
 wrote:
 Hi Chris,
 Thanks!
 That's true for the user number. What should I do? Encrypt it?

 It's not that you have a user number, or even that it's accessible: it's
 that it's the entirety of access control, meaning that if the user changes
 it they can masquerade as another user. The correct solution is that a user
 should authenticate, which creates a session hash that you stash away and
 also send back to the user as a cookie so the browser will present it on
 accesses. Then you check that the presented hash is there and matches the
 session hash. These should expire periodically, requiring the user to log
 back in again.

Brandon pretty much pulled the words out of my mouth, but I have one
last thing to add: no matter how well you encrypt the information, as
long as it's in the URL it's insecure.

Hypothetical situation #1: if there's someone looking over your
shoulder, they can just note down the address -- it is in plain view,
after all.

Even more likely: your friend wants to watch the game, so you send her
the link. Unfortunately, you forget to delete your session information
from the URL. Now your friend (conveniently named Eve) has hijacked
your account and is voting on your behalf.

The Ruby on Rails website has an excellent explanation of common
security holes [1]. The article is Rails-centric, but most of it
applies to Haskell as well.

[1] http://guides.rubyonrails.org/security.html

As for libraries, Happstack has happstack-authenticate [2]. I haven't
used it myself, but it looks good.

[2] http://hackage.haskell.org/package/happstack-authenticate

Chris

 --
 brandon s allbery kf8nh   sine nomine associates
 allber...@gmail.com  ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

Re: [Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules

2013-02-26 Thread Chris Wong

 Hello everybody!
 I am very happy to announce the beta release [1] of Nomyx, the only game
 where You can change the rules.

I just gave it a go -- it looks fun :)

However, I've spotted a security hole. The current user number is
stored in the URL -- if I change that number, I can masquerade as
someone else! Is this behavior intended?

 This is an implementation of a Nomic [2] game in Haskell (I believe the
 first complete implementation). In a Nomyx game you can change the rules of
 the game itself while playing it. The players can submit new rules or modify
 existing ones, thus completely changing the behaviour of the game through
 time. The rules are managed and interpreted by the computer. They must be
 written in the Nomyx language, which is a subset of Haskell.
 At the beginning, the initial rules are describing:
 - how to add new rules and change existing ones. For example a unanimity
 vote is necessary to have a new rule accepted.
 - how to win the game. For example you win the game if you have 5 rules
 accepted.
 But of course even that can be changed!

 Here is a video introduction and first tutorial of the game:
 http://vimeo.com/58265498
 The game is running here: www.nomyx.net:8000/Nomyx
 I have set up a forum where players can learn about Nomyx and discuss the
 rules they intend to propose: www.nomyx.net/forum

 As this is the first beta release of the game, I'm looking for beta testers
 :) Although I tested it quite a lot, I'm sure a lot of bugs remains,
 especially in multiplayer.
 So if you are interested in testing Nomyx, please go to this forum thread
 and we'll set up a small team to start a match!
 http://www.nomyx.net/forum/viewtopic.php?p=5

 Comments/contributions are very highly welcome! There is still a lot to do.
 As for now, the game is not completely securised. It is easy to break it by
 submitting rules containing malicious code. I'm working on it. If you'd like
 to do security testing, please do it locally on your own machine and send me
 a bug report :).

 Cheers,
 Corentin

 [1] http://hackage.haskell.org/package/Nomyx
 [2] www.nomic.net

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


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

[Haskell-cafe] Uniplate and rewriting with different types

2013-01-28 Thread Chris Mears

Hi all,

I have a question about the Uniplate library, regarding rewriting with
transformations that have different types.

With the following type, and transformation functions:

data Odd = OddOne Even | OddZero Even  deriving (Data,Typeable,Show)
data Even = EvenOne Odd | EvenZero Odd | Nil   deriving (Data,Typeable,Show)

t1,t2,t3 :: Even - Maybe Even

t1 (EvenOne (OddOne x)) = Just $ EvenOne (OddZero x)
t1 x= Nothing

t2 (EvenOne (OddZero x)) = Just $ EvenZero (OddOne x)
t2 x = Nothing

t3 (EvenZero (OddOne x)) = Just $ EvenZero (OddZero x)
t3 x = Nothing

it is easy to combine the transformations into a single
transformation, because they all have the same type.  The result can
then be passed to the Uniplate's rewriteBi function:

allts x = t1 x `mplus` t2 x `mplus` t3 x
example = OddOne (EvenOne (OddOne (EvenOne (OddOne Nil
go = rewriteBi allts example

But if one of the transformations has a different type, you can't do
it this way.  For instance, redefine t2 to have a different type:

t2 :: Odd - Maybe Odd
t2 (OddZero (EvenOne x)) = Just $ OddZero (EvenZero x)
t2 x = Nothing

and you are stuck because the functions of different types can't be
combined into a single transformation.

My question is: is there a good way to combine the transformation
functions if they have different types?

I have come up with a possible solution (see below), but I am not sure
that it is the right approach, and it is probably inefficient.

Chris Mears

{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE ScopedTypeVariables #-}

import Control.Monad
import Control.Monad.State
import Data.Generics
import Data.Generics.Uniplate.Data

data Odd = OddOne Even | OddZero Even  deriving (Data,Typeable,Show)
data Even = EvenOne Odd | EvenZero Odd | Nil   deriving (Data,Typeable,Show)

t1 (EvenOne (OddOne x)) = Just $ EvenOne (OddZero x)
t1 x= Nothing

t2 :: Odd - Maybe Odd
t2 (OddZero (EvenOne x)) = Just $ OddZero (EvenZero x)
t2 x = Nothing

t3 (EvenZero (OddOne x)) = Just $ EvenZero (OddZero x)
t3 x = Nothing

-- The transformers are wrapped in an existential type.
data WrappedTransformer from =
  forall to. (Data to, Biplate from to) = WrappedTransformer (to - Maybe to)

-- Apply a single transformation, and return Just x if the
-- transformation fired (where x is the result of the rewriting), and
-- Nothing if no transformation fired.
rewriteBiCheck :: Biplate from to = (to - Maybe to) - from - Maybe from
rewriteBiCheck f e =
case runState (rewriteBiM check e) False of
  (e', True) - Just e'
  (_, False) - Nothing
  where check x = case f x of
Nothing - return Nothing
Just y - put True  return (Just y)

-- Apply a list of wrapped transformations until no more
-- transformations can be applied.
rewriteBiList :: forall from. [WrappedTransformer from] - from - from
rewriteBiList transformers m = go transformers m
  where go :: [WrappedTransformer from] - from - from
go [] m = m
go ((WrappedTransformer t):ts) m = case rewriteBiCheck t m of
   Just m' - go transformers m'
   Nothing - go ts m

-- Test case.
example = OddOne (EvenOne (OddOne (EvenOne (OddOne Nil

go = rewriteBiList [ WrappedTransformer t1
   , WrappedTransformer t2
   , WrappedTransformer t3 ] example

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

Re: [Haskell-cafe] catamorphisms and attribute grammars

2013-01-26 Thread Chris Wong

Hi Petr,

Congratulations -- you've just implemented a Moore machine! [1]

I posted something very much like this just last year [2]. It's a very
common pattern in Haskell, forming the basis of coroutines and
iteratees and many other things.

Edward Kmett includes it in his machines package [3]. His variation,
like mine, hides the state inside a closure, removing the need for
existentials. pipes 2.0 contains one implemented as a free monad [4].

[1] http://en.wikipedia.org/wiki/Moore_machine
[2] 
http://hackage.haskell.org/packages/archive/machines/0.2.3/doc/html/Data-Machine-Moore.html
[3] http://www.haskell.org/pipermail/haskell-cafe/2012-May/101460.html
[4] 
http://hackage.haskell.org/packages/archive/pipes/2.0.0/doc/html/Control-Pipe-Common.html

Chris

On Sun, Jan 27, 2013 at 11:03 AM, Petr P petr@gmail.com wrote:
   Dear Haskellers,

 I read some stuff about attribute grammars recently [1] and how UUAGC [2]
 can be used for code generation. I felt like this should be possible inside
 Haskell too so I did some experiments and I realized that indeed
 catamorphisms can be represented in such a way that they can be combined
 together and all run in a single pass over a data structure. In fact, they
 form an applicative functor.

 [1] http://www.haskell.org/haskellwiki/Attribute_grammar
 [2] Utrecht University Attribute Grammar Compiler

 To give an example, let's say we want to compute the average value of a
 binary tree. If we compute a sum first and then count the elements, the
 whole tree is retained in memory (and moreover, deforestation won't happen).
 So it's desirable to compute both values at once during a single pass:

 -- Count nodes in a tree.
 count' :: (Num i) = CataBase (BinTree a) i
 count' = ...

 -- Sums all nodes in a tree.
 sum' :: (Num n) = CataBase (BinTree n) n
 sum' = ...

 -- Computes the average value of a tree.
 avg' :: (Fractional b) = CataBase (BinTree b) b
 avg' = (/) $ sum' * count'

 Then we can compute the average in a single pass like

 runHylo avg' treeAnamorphism seed

 My experiments together with the example are available at
 https://github.com/ppetr/recursion-attributes

 I wonder, is there an existing library that expresses this idea?

   Best regards,
   Petr Pudlak


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


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

Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

2013-01-21 Thread Chris Dornan

I am also sorry to be late on this but I have run into the same problem
trying to demonise a programme on 7.4.2. My solution was to get a shell
wrapper to run the daemon in debug mode (I.e., sans fork) and get the shell
script to do the demonising.

Other than this I have found the threaded RTS to be sound and I am quite
reliant on it. So, where things that run threaded are concerned, no
forkProcess calls for me until I can better understand this better.

If anybody does think they understand what is going on here it would be
great if they could write it up. IMHO, either the current notes on
forkProcess don't go far enough, or there is a bug needing a workaround
until the platform gets fixed.

Chris

From:  Mark Lentczner mark.lentcz...@gmail.com
Date:  Sunday, 20 January 2013 23:15
To:  haskell haskell-cafe@haskell.org
Cc:  Mike Meyer m...@mired.org
Subject:  Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

Sorry to be reviving this thread so long after but I seem to be running
into similar issues as Michael S. did at the start.

In short, I'm using forkProcess with the threaded RTS, and see occasional
hangs:
* I see these only on Linux. On Mac OS X, I never do.
* I'm using GHC 7.4.2
* I noticed the warning in the doc for forkProcess, but assumed I was safe,
as I wasn't holding any shared resources at the time of the fork, and no
shared resources in the program are used in the child.
* WIth gdb, I've traced the hang to here in the run-time: forkProcess 
discardTasksExcept  freeTask  closeMutex(task-lock) 
pthread_mutex_destroy
The discussion in this thread leaves me with these questions:
* Is there reason to think the situation has gotten better in 7.6 and later?
* Isn't the only reason System.Process is safer because it does an immediate
exec in the child? Alas, I really want to just fork() sometimes.
* Is it really true that even if my program has no shared resources with the
child, that the IO subsystem and FFI system do anyway? Surely the RTS would
take care of doing the right thing with those, no?
* There should be no concern with exec w.r.t. library invariants since exec
is wholesale replacement - all the libraries will reinitialize. Is there a
problem here I'm missing?
Alas, I've stopped using the threaded RTS until I understand this better.

- Mark
___ Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))

2012-12-30 Thread Chris Smith

On Sun, Dec 30, 2012 at 8:51 AM, David Thomas davidleotho...@gmail.comwrote:

 Jon's suggestion sounds great.

 The bike shed should be green.


There were plenty of proposals that would work fine.  `case of` was great.
 `\ of` was great.  It's less obvious to me that stand-alone `of` is never
ambiguous... but if that's true, it's reasonable.  Sadly, the option that
was worse that doing nothing at all is what was implemented.

The bikeshedding nonsense is frustrating.  Bikeshedding is about wasting
time debating the minutia of a significant improvement, when everyone
agrees the improvement is a good idea.  Here, what happened was that
someone proposed a minor syntax tweak (from `\x - case x of` to `case
of`), other reasonable minor syntax tweaks were proposed instead to
accomplish the same goal, and then in the end, out of the blue, it was
decided to turn `case` into a layout-inducing keyword (or even worse, only
sometimes but not always layout-inducing).

There is no bike shed here.  There are just colors (minor syntax tweaks).
 And I don't get the use of bikeshedding as basically just a rude comment
to be made at people who don't like the same syntax others do.

-- 
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Categories (cont.)

2012-12-21 Thread Chris Smith

It would definitely be nice to be able to work with a partial Category
class, where for example the objects could be constrained to belong to a
class. One could then restrict a Category to a type level representation
of the natural numbers or any other desired set. Kind polymorphism should
make this easy to define, but I still don't have a good feel for whether it
is worth the complexity.
On Dec 21, 2012 6:37 AM, Tillmann Rendel ren...@informatik.uni-marburg.de
wrote:

Hi,

Christopher Howard wrote:

instance Category ...

The Category class is rather restricted:

Restriction 1:
You cannot choose what the objects of the category are. Instead, the
objects are always all Haskell types. You cannot choose anything at all
about the objects.

Restriction 2:
You cannot freely choose what the morphisms of the category are. Instead,
the morphisms are always Haskell values. (To some degree, you can choose
*which* values you want to use).

These restrictions disallow many categories. For example, the category
where the objects are natural numbers and there is a morphism from m to n
if m is greater than or equal to n cannot be expressed directly: Natural
numbers are not Haskell types; and is bigger than or equal to is not a
Haskell value.

Tillmann

__**_
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Chris Smith

Ketil Malde ke...@malde.org wrote:
 The point of the point is that neither of these are translations of
 literary works, there is no precedence for considering them as such, and
 that reading somebody's work (whether literary or source code) before
 writing one's own does not imply that the 'somebody' will hold any
 rights to the subsequent work.

So IANAL, but I do have an amateur interest in copyright law.  The debate
over the word translation is completely irrelevant.  The important point
is whether it is a derived work.  That phrase certainly includes more
than mere translation.  For example, it includes writing fiction that's set
in the same fantasy universe or HHS the same characters as another author's
works.  It also includes making videos with someone else's music playing in
the background. If you create a derived work, then the author of the
original definitely has rights to it, regardless of whether it is a mere
translation.  That's also why the word derived in a comment was
particularly Dacey to the legal staff and probably caused them to overreact
in this case.

The defense in the case of software is to say that the part that was copied
was not a work of authorship in the sense that, say, a fiction character
is.  This is generally not a hard case to win, since courts see computer
software as dominated by its practical function.  But if you copied
something that was clearly a matter of expression and not related to the
function of the software, you could very well be creating a derived work
over which the original author could assert control.

That said, I agree that in this particular case it's very unlikely that the
original author could have won an infringement case.  I just balked a
little at the statements about translation, which was really just an
example.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] mtl: Why there is Monoid w constraint in the definition of class MonadWriter?

2012-12-10 Thread Chris Wong

Hi Petr,

On Sun, Dec 9, 2012 at 7:59 AM, Petr P petr@gmail.com wrote:

 The class is defined as

  class (Monoid w, Monad m) = MonadWriter w m | m - w where
...

 What is the reason for the Monoid constrait? It seems superfluous to me. I
 recompiled the whole package without it, with no problems.

How I see it, the MTL classes are there to lift operations
automatically through layers of transformers. They're just a hack to
avoid having to call `lift` all the time, and aren't really designed
to be used on monads other than the original WriterT.

With this interpretation, the constraint makes sense -- it is simply
reflecting the constraints already on the concrete monad.

Chris

 Of course, the Monoid constraint is necessary for most _instances_, like
 in

  instance (Monoid w, Monad m) = MonadWriter w (Lazy.WriterT w m) where
  ...

 but this is a different thing - it depends on how the particular instance
 is implemented.

 I encountered the problem when I needed to define an instance where the
 monoidal structure is fixed (Last) and I didn't want to expose it to the
 user. I wanted to spare the user of of having to write Last/getLast
 everywhere. (I have an instance of MonadWriter independent of WriterT, its
 'tell' saves values to a MVar. Functions 'listen' and 'pass' create a new
 temporary MVar. I can post the detail, if anybody is interested.)

 Would anything break by removing the constraint? I think the type class
 would get a bit more general this way.

   Thanks for help,
   Petr Pudlak

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


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

Re: [Haskell-cafe] Parsing different types, same typeclass

2012-11-17 Thread Chris Wong

Hello José,

 So, I have a typeclass Action which defines method run:

 class Action a where
 run :: a - Int

 (snipped)

 Now, I want to parse either A or B from a String.
 I was thinking about something like this...

 parseAction :: (Action a, Read a) = String - a
 parseAction str
 | (A  `isPrefixOf` str = (read :: String - A) str
 | (B  `isPrefixOf` str = (read :: String - B) str

 The problem is that when calling parseAction I get ambiguous type
 constraints. How to implement a parse function for two distinct
 types that share the same typeclass Action. Because after calling
 parseAction I don't whether A or B was returned: I only care
 that they are Action instances so I can call run.

The problem with your current type:

(Action a, Read a) = String - a

is that it actually means:

For any type that implements Action and Read, I can convert a
string to that type.

This is wrong because if a user of your module added another type C,
your function wouldn't be able to handle it -- it only knows about A
and B. That is what GHC is trying to tell you.

How you can solve this problem depends on what you're trying to do. If
there is a finite number of actions, you can merge them into a single
type and remove the type class altogether:

data Action = A Int | B Int
deriving (Read, Show)

run :: Action - Int
run (A x) = x
run (B x) = x

parse :: String - Action
parse = read

If you have a possibly unlimited number of possible actions, there are
many approaches to this -- including, as Stephen said, existential
types. However, it's hard to decide on a proper solution without
knowing what you're actually trying to do.

Chris

 Best regards,
 José

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

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

Re: [Haskell-cafe] generalizing the writer monad

2012-10-17 Thread Chris Wong

Hello!

On Thu, Oct 18, 2012 at 6:59 AM, Petr P petr@gmail.com wrote:
 Hi,

 (this is a literate Haskell post.)

 lately I was playing with the Writer monad and it seems to me that it
 is too tightly coupled with monoids. Currently, MonadWriter makes the
 following assumptions:

 (1) The written value can be read again later.
 (2) For that to be possible it has to be monoid so that multiple (or
 zero) values can be combined.

 I fell say that this is a bit restricting. Sometimes, the written
 value can be lost - either used to compute something else or for
 example sent out using some IO action to a file, network etc. For
 example, I'd like to create an IO-based writer monad whose `tell` logs
 its argument somewhere - prints it, stores to a file etc.

Try the Coroutine monad transformer:

http://hackage.haskell.org/package/monad-coroutine

Instead of writing the log inside the monad, you can yield the message
instead. The calling code is then free to choose what to do with the
messages.

 So what I'm suggesting is to have another type class between Monad and
 MonadWriter, let's say MonadTell, which only allows to write values,
 not to retrieve them later:

 {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, 
 FunctionalDependencies #-}
 import Control.Monad
 import Control.Monad.Trans
 import qualified Control.Monad.Writer as W
 import qualified Control.Monad.Reader as R
 import Data.Monoid

 class Monad m = MonadTell w m where
 tell :: w - m ()
 tell w = writer ((), w)
 writer :: (a, w) - m a
 writer ~(a, w) = tell w  return a

 (We don't need fun.deps. here, they're needed in MonadWriter because
 of `listen`. IDK if it'd be still better to add fun.dep. just to
 eliminate typing problems?)

 And MonadWriter would be defined by inheriting from MonadTell:

 class (MonadTell w m, Monoid w) = MonadWriter' w m | m - w where
 listen :: m a - m (a, w)
 pass :: m (a, w - w) - m a

 Now we could use MonadWriter as before, but we could also make more
 generic writers like:

 newtype Log = Log String deriving Show
 -- Prints logs to stdout.
 instance MonadTell Log IO where
 tell (Log s) = putStrLn s

 -- Collects the length of written logs.
 instance Monad m = MonadTell Log (W.WriterT (Sum Int) m) where
 tell (Log s) = W.tell (Sum $ length s)


 main = do
 let l = Log Hello world
 tell l
 print . getSum . W.execWriter $ (tell l :: W.Writer (Sum Int) ())

 The same applies to MonadReader. We could make another type class
 between Monad and MonadReader just with `ask`:

 class Monad m = MonadAsk r m | m - r where
 ask :: m r

 This would allow us to write instances like

 instance MonadAsk Log IO where
 ask = liftM Log getLine

 Does it make sense?

 Best regards,
 Petr Pudlak

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

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

Re: [Haskell-cafe] ANNOUNCE: Sylvia, a lambda calculus visualizer

2012-10-01 Thread Chris Wong

On Tue, Oct 2, 2012 at 3:23 PM, Conrad Parker con...@metadecks.org wrote:
 Nice, it builds and runs fine for me. Perhaps you could include a few
 more example commandlines to get started?  Running without arguments
 (as the README.mkd suggests) just prints the help text.

Thanks for pointing that out! I've added an examples page at

https://github.com/lfairy/sylvia/wiki/Examples

 This is still in very early alpha, but it renders a fair number of
 combinators correctly. I plan to add animated reduction (once I figure
 out how to do it), and eventually develop this into a sandbox game of
 some sort. I'm hoping to get some comments and ideas on how I can take
 it from here.

 I'd love to see a game which incrementally teaches reduction and
 expansion steps in the way that DragonBox [http://dragonboxapp.com/]
 teaches algebra. That would be a learning mode like Angry Birds, where
 new combinator birds are introduced every few levels and a small
 selection of useful birds are provided to help solve each level.

Interesting! I'll have a closer look at it when I have the time.

 (Lambda calculus really should be a kids' game, grown-ups always make
 it seem more complex than it is).

That's exactly the point I'm trying to make :)

Heck, lambda calculus is just as simple as natural numbers (if not
simpler), yet people learn the former at university and the latter a
few months after they're born.

I think the difference is in the way they are taught. Want to teach
someone about numbers? Here's one orange. Here's two oranges. And look
-- put them together, and you get three.

Want to teach someone lambda calculus? Give 'em a textbook, and an
hour-long lecture about programming language theory.

The result doesn't surprise me one bit.

 Conrad.

On Tue, Oct 2, 2012 at 4:16 PM, Alistair Bayley alist...@abayley.org wrote:
 Not sure if it's what you're after, but I was reminded of this (models
 untyped lambda calculus):
   http://worrydream.com/AlligatorEggs/

Thanks -- I've tried that before, and unfortunately it suffers the
same problem I've had with many other visualizations. Because it uses
colors to refer to variables, we end up with two problems:

1. Color blind people can't play it.

2. More subtly: colors - absolute variable names - lots of alpha
conversion. Alligators eating each other is fun. Swapping alligators
frantically to stop accidental capture is not.

Chris

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

[Haskell-cafe] ANNOUNCE: Sylvia, a lambda calculus visualizer

2012-09-27 Thread Chris Wong

Hello all

Some of you in the audience may have read Dave Keenan's paper, [To
Dissect a Mockingbird][]. A subset of that may have wondered if it was
possible to generate those pretty pictures programmatically. For that
subset, I can answer to you -- yes, yes you can.

[To Dissect a Mockingbird]: http://dkeenan.com/Lambda/

Sylvia is a lambda calculus visualizer. It takes in an expression in
the untyped lambda calculus and spits out a pretty picture.

This is still in very early alpha, but it renders a fair number of
combinators correctly. I plan to add animated reduction (once I figure
out how to do it), and eventually develop this into a sandbox game of
some sort. I'm hoping to get some comments and ideas on how I can take
it from here.


Obligatory links


Hackage: http://hackage.haskell.org/package/sylvia

Source: https://github.com/lfairy/sylvia

Documentation: https://github.com/lfairy/sylvia/wiki



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

Re: [Haskell-cafe] Call for discussion: OverloadedLists extension

2012-09-23 Thread Chris Smith

Michael Snoyman mich...@snoyman.com wrote:
 That said, it would be great to come up with ways to mitigate the
 downsides of unbounded polymorphism that you bring up. One idea I've
 seen mentioned before is to modify these extension so that they target
 a specific instance of IsString/IsList, e.g.:

 {-# STRING_LITERALS_AS Text #-}

 foo == (fromString foo :: Text)

That makes sense for OverloadedStrings, but probably not for
OverloadedLists or overloaded numbers... String literals have the
benefit that there's one type that you probably always really meant.
The cases where you really wanted [Char] or ByteString are rare.  On
the other hand, there really is no sensible I always want this
answer for lists or numbers.  It seems like a kludge to do it
per-module if each module is going to give different answers most of
the time.

-- 
Chris

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

Re: [Haskell-cafe] Installation issues with Centos

Hi Manish,
 
Are you aware of the CentOS distro I am maintaining at justhub.org
/download? Even if you want to build your own installations it will probably
be useful for getting you going.
 
(It should soon appear on the Haskell Platform Linux page - or at least we
have a ticket for it!)
 
Chris
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Installation issues with Centos

Hi Jim,

 Previously I've been able to install and use ghc and HP in ~/ without
problems. Is there any reason
 why this couldn't be done with your justhub package?

 As I've never tried this brute surgery on such a magnus opus before I'm
not sure this is at all feasible?

I wouldn't recommend trying to install the justhub package in user-space.

Starting from the GHC bindists and the sources for everything else (platform
and hub wrapper) you can relocate everything of course. In theory I believe
it would also be possible to make all the RPMs relocatable, but because of
all of the moving parts it's not so easy in practice.

It is on my list of things to do -- obviously the more requests I get the
higher it will go on the priority list, and the number of requests has now
just doubled, to two (but I will bet there are more -- I take it seriously).

Chris



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

Re: [Haskell-cafe] Installation issues with Centos

Thanks Henk!

 I just added this to the Linux page[0].

The action on that HP ticket was to put a link here, 
http://hackage.haskell.org/platform/linux.html, which should happen by the next 
platform release.

Chris



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

Re: [Haskell-cafe] Cabal install fails due to recent HUnit

On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan b...@serpentine.com
wrote:
 On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan 
 b...@serpentine.com
 wrote:

 Not to flog a dead horse, but:

...
Not to flog a dead horse, but:

All our builds broke again yesterday due to this bug. The package was
iteratee-0.8.9.3, though given the vocal opposition of Bryan O'Sullivan, I
won't advocate fixing it in place just now.
...
I was going to argue to support versions of cabal (and GHC) for at least a
year. That means that if you're on Ubuntu, which has releases every 6
months, you have 6 months to upgrade. However, that year has already expired
for cabal 0.10, or is about to expire if you count the Ubuntu release it
came with.

So what do others think? Does the haskell community want to support
anything other than the bleeding edge? If so, for how long?

While we are all making glue, it really, really doesn't need to be like
this! (Everybody is going to hate me for this and I am quite sure I am going
to be ignored, but my conscience forbids me from staying quiet.)

Every one of my Haskell Platform releases on justhub.org provides all the
libraries and tools needed for
that platform, which gets laid on top of the existing platforms (which can
be removed when they are no longer needed).

Each project can chooses its platform, and can pin whatever packages it
needs to use without fear of being disrupted,
while installing new GHC and platform releases for use with other projects.
(Proper package erasure is supported too.)

With trivial effort source trees can be moved around among different systems
and rebuilt in the exact same configuration.

The standard tools (ghc, ghci, ghc-pkg, cabal, etc.) can be used just as
normal. All the developer needs to do is designate which platform
(or bare ghc) to be used at the root of each work tree -- or leave it to use
the platform-du-jour.

I can only describe working with this kind of environment as peaceful
(certainly not cabal hell).

Trying to mutate and maintain coherent an ever-growing network of packages
is not a scalable way of doing business. If on top
of this the history gets  patched up aren't things going to get even more
confusing?

I know that this way of doing things won't provide immediate relief (it's
too radical relative to where everybody is) but I am
trying to address Erik's question about what we should be aiming for.
Shouldn't we be trying to find a sustainable, long-term,
preferred method of delivering stable Haskell development environments? Why
not a functional model? What is not to like?

I will be at the CUFP if anybody would like to see a live demo or debate any
of these points.

Chris



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

Re: [Haskell-cafe] Over general types are too easy to make.

2012-09-02 Thread Chris Smith

On Sun, Sep 2, 2012 at 9:40 AM,  timothyho...@seznam.cz wrote:
 The thing is, that one ALWAYS wants to create a union of types, and not
 merely an ad-hock list of data declarations.  So why does it take more code
 to do the right thing(tm) than to do the wrong thing(r)?

You've said this a few times, that you run into this constantly, or
even that everyone runs into this.  But I don't think that's the case.
 It's something that happens sometimes, yes, but if you're running
into this issue for every data type that you declare, that is
certainly NOT just normal in Haskell programming.  So in that sense,
many of the answers you've gotten - to use a GADT, in particular -
might be great advice in the small subset of cases where average
Haskell programmers want more complex constraints on types; but it's
certainly not a good idea to do to every data type in your
application.

I don't have the answer for you about why this always happens to you,
but it's clear that there's something there - perhaps a stylistic
issue, or a domain-specific pattern, or something... - that's causing
you to face this a lot more frequently than others do.  If I had to
take a guess, I'd say that you're breaking things down into fairly
complex monolithic parts, where a lot of Haskell programmers will have
a tendency to work with simpler types and break things down into
smaller pieces.  But... who knows... I haven't seen the many cases
where this has happened to you.

-- 
Chris

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

Re: [Haskell-cafe] hellno - a somewhat different approach to tackling cabal hell

2012-09-02 Thread Chris Wong

On Mon, Sep 3, 2012 at 3:15 PM, Richard Wallace
rwall...@thewallacepack.net wrote:
 I like the approach so far.  But hellno itself seems to have several
 dependencies itself.  So installing with cabal pulls these in as
 fixed libraries (text, mtl, transformers, and parsec).  Any
 plans to make these not have to be fixed? Or is there a trick I'm
 missing?

All of those libraries are included in the Haskell Platform anyway.
The majority of users shouldn't need to install extra packages to get
it to work.

 On Sun, Sep 2, 2012 at 11:25 AM, Danny B danny.b@gmail.com wrote:
 Like many of us, I've suffered from cabal dependency hell and sought relief.

 I wasn't exactly happy with sandboxes - because using per-project ones
 meant package duplication and shared sandboxes suffer from the same
 issues as the GHC package database itself, i.e. reinstalls can break
 other projects, etc. So I wrote hellno, which is so named because that's
 the expression one makes when seeing cabal hell suddenly manifest itself
 and that's also the expression one makes upon encountering yet ANOTHER
 cabal wrapper.

 To quote the README:
 Generally, with hellno you'll get the same result as for blowing away your 
 user
 package database and doing a nice clean install but without having to 
 recompile
 everything and with ability to easily revert back and change between 
 projects.

 Hellno works by keeping all the compiled packages to itself in a
 database, so that when you ask it to bring in the dependencies of a
 project, it will use the precompiled packages if available or install
 the deps and save them for later reuse.

 Hellno puts symlinks in the user package database pointing to packages
 in its storage to make them visible. Mutating the user db is hardly
 elegant, although shouldn't result in much trouble.

 It's been working fine for me, so I figured it may be useful to others.
 You can get hellno from GitHub:
 https://github.com/db81/hellno

 I don't mean to say that sandboxing is inherently bad or should not be
 used, but I guess it's better to consider more than one way.

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

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

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

Re: [Haskell-cafe] How to implement instance of MonadBaseControl IO

2012-08-22 Thread Chris Wong

On Wed, Aug 22, 2012 at 7:16 PM, yi huang yi.codepla...@gmail.com wrote:
 I have a `newtype Yun a = Yun { unYun :: ReaderT YunEnv (ResourceT IO) a }`
 , and i need to define an instance of `MonadBaseControl IO` for it.
 Newtype instance deriving don't work here. I guess the answer is simple, i
 just can't figure it out, hope anybody can lightening me.

I had the same problem some time ago. In my case it's StateT instead
of ReaderT, but it's the same idea. The tough part is getting around
the crazy CPS -- it's supposed to help with performance, but at the
cost of usability.

Anyway, here's my implementation:
https://github.com/lfairy/haskol/blob/master/Web/KoL/Core.hs#L58

Michael Snoyman has written a tutorial as well:
http://www.yesodweb.com/book/monad-control
I'd recommend printing it out and going over it slowly -- it can get
pretty dense at times.

Chris

 Best regards.
 Yihuang.

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


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

Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

2012-08-20 Thread Chris Dornan

I think we should encourage stable build environments to know precisely
which package versions they have been using and to keep using them until
told otherwise. Even when the types and constraints all work out there is a
risk that upgraded packages will break. Everybody here wants cabal to just
install the packages without problem, but if you want to insulate yourself
from package upgrades surely sticking with proven combinations is the way to
go.

Chris

-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Erik Hesselink
Sent: 20 August 2012 08:33
To: Bryan O'Sullivan
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends

I am strongly against this, especially for packages in the platform.

If you fail to specify an upper bound, and I depend on your package, your
dependencies can break my package! For example, say I develop executable A
and I depend on library B == 1.0. Library B depends on library C = 0.5 (no
upper bound). Now C 0.6 is released, which is incompatible with B. This
suddenly breaks my build, even though I have not changed anything about my
code or dependencies. This goes against the 'robust' aspect mentioned as one
of the properties of the Haskell platform, and against the Haskell
philosophy of correctness in general.

This is not an imaginary problem. At my company, we've run into these
problems numerous times already. Since we also have people who are not
experts at Cabal and the Haskell ecosystem building our software, this can
be very annoying. The fix is also not trivial: we can add a dependency on a
package we don't use to all our executables or we can fork the library (B,
in the example above) and add an upper bound/fix the code. Both add a lot of
complexity that we don't want. Add to that the build failures and associated
emails from CI systems like Jenkins.

I can see the maintenance burder you have, since we have to do the same for
our code. But until some Cabal feature is added to ignore upper bounds or
specify soft upper bounds, please follow the PVP, also in this regard. It
helps us maintain a situation where only our own actions can break our
software.

Erik

On Wed, Aug 15, 2012 at 9:38 PM, Bryan O'Sullivan b...@serpentine.com
wrote:
 Hi, folks -

 I'm sure we are all familiar with the phrase cabal dependency hell 
 at this point, as the number of projects on Hackage that are intended 
 to hack around the problem slowly grows.

 I am currently undergoing a fresh visit to that unhappy realm, as I 
 try to rebuild some of my packages to see if they work with the GHC 
 7.6 release candidate.

 A substantial number of the difficulties I am encountering are related 
 to packages specifying upper bounds on their dependencies. This is a 
 recurrent problem, and its source lies in the recommendations of the 
 PVP itself (problematic phrase highlighted in bold):

 When publishing a Cabal package, you should ensure that your 
 dependencies in the build-depends field are accurate. This means 
 specifying not only lower bounds, but also upper bounds on every
dependency.


 I understand that the intention behind requiring tight upper bounds 
 was good, but in practice this has worked out terribly, leading to 
 depsolver failures that prevent a package from being installed, when 
 everything goes smoothly with the upper bounds relaxed. The default 
 response has been for a flurry of small updates to packages in which 
 the upper bounds are loosened, thus guaranteeing that the problem will 
 recur in a year or less. This is neither sensible, fun, nor sustainable.

 In practice, when an author bumps a version of a depended-upon 
 package, the changes are almost always either benign, or will lead to 
 compilation failure in the depending-upon package. A benign change 
 will obviously have no visible effect, while a compilation failure is 
 actually better than a depsolver failure, because it's more informative.

 This leaves the nasty-but-in-my-experience-rare case of runtime 
 failures caused by semantic changes. In these instances, a downstream 
 package should reactively add an upper bound once a problem is discovered.

 I propose that the sense of the recommendation around upper bounds in 
 the PVP be reversed: upper bounds should be specified only when there 
 is a known problem with a new version of a depended-upon package.

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


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


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

Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

2012-08-20 Thread Chris Dornan

Of course if you wish or need to upgrade a package then you can just upgrade
it -- I am not suggesting anyone should forgo upgrades! It is just that
there is no need to make the stability of a build process dependent on new
package releases.

To upgrade a package I would fork my sandbox, hack away at the package
database (removing, upgrading, installing packages) until I have a candidate
combination of packages and swap in the new sandbox into my work tree and
test it, reverting to the tried and tested environment if things don't work
out.  If the new configuration works then then I would dump the new package
configuration and check it in. Subsequent updates and builds on other work
trees should pick up the new environment.

The key thing I was looking for was control of when your build environment
gets disrupted and stability in between -- even when building from the repo.

Chris

-Original Message-
From: Erik Hesselink [mailto:hessel...@gmail.com] 
Sent: 20 August 2012 14:35
To: Chris Dornan
Cc: Bryan O'Sullivan; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends

Hub looks interesting, I'll have to try it out (though I'm not on an RPM
based distro). But isn't this the goal of things like semantic versioning
[0] and the PVP? To know that you can safely upgrade to a bugfix release,
and relavily safely to a minor release, but on a major release, you have to
take care?

Haskell makes it much easier to see if you can use a new major (or
minor) version of a library, since the type checker catches many (but not
all!) problems for you. However, this leads to libraries breaking their
API's much more easily, and that in turn causes the problems voiced in this
thread. However, fixing all versions seems like a bit of a blunt instrument,
as it means I'll have to do a lot of work to bring even bug fixes in.

Erik

[0] http://semver.org/



On Mon, Aug 20, 2012 at 3:13 PM, Chris Dornan ch...@chrisdornan.com wrote:
 I think we should encourage stable build environments to know 
 precisely which package versions they have been using and to keep 
 using them until told otherwise. Even when the types and constraints 
 all work out there is a risk that upgraded packages will break. 
 Everybody here wants cabal to just install the packages without 
 problem, but if you want to insulate yourself from package upgrades 
 surely sticking with proven combinations is the way to go.

 Chris

 -Original Message-
 From: haskell-cafe-boun...@haskell.org 
 [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Erik Hesselink
 Sent: 20 August 2012 08:33
 To: Bryan O'Sullivan
 Cc: haskell-cafe@haskell.org
 Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds 
 are not our friends

 I am strongly against this, especially for packages in the platform.

 If you fail to specify an upper bound, and I depend on your package, 
 your dependencies can break my package! For example, say I develop 
 executable A and I depend on library B == 1.0. Library B depends on 
 library C = 0.5 (no upper bound). Now C 0.6 is released, which is 
 incompatible with B. This suddenly breaks my build, even though I have 
 not changed anything about my code or dependencies. This goes against 
 the 'robust' aspect mentioned as one of the properties of the Haskell 
 platform, and against the Haskell philosophy of correctness in general.

 This is not an imaginary problem. At my company, we've run into these 
 problems numerous times already. Since we also have people who are not 
 experts at Cabal and the Haskell ecosystem building our software, this 
 can be very annoying. The fix is also not trivial: we can add a 
 dependency on a package we don't use to all our executables or we can 
 fork the library (B, in the example above) and add an upper bound/fix 
 the code. Both add a lot of complexity that we don't want. Add to that 
 the build failures and associated emails from CI systems like Jenkins.

 I can see the maintenance burder you have, since we have to do the 
 same for our code. But until some Cabal feature is added to ignore 
 upper bounds or specify soft upper bounds, please follow the PVP, also 
 in this regard. It helps us maintain a situation where only our own 
 actions can break our software.

 Erik

 On Wed, Aug 15, 2012 at 9:38 PM, Bryan O'Sullivan b...@serpentine.com
 wrote:
 Hi, folks -

 I'm sure we are all familiar with the phrase cabal dependency hell
 at this point, as the number of projects on Hackage that are intended 
 to hack around the problem slowly grows.

 I am currently undergoing a fresh visit to that unhappy realm, as I 
 try to rebuild some of my packages to see if they work with the GHC
 7.6 release candidate.

 A substantial number of the difficulties I am encountering are 
 related to packages specifying upper bounds on their dependencies. 
 This is a recurrent problem, and its source lies in the 
 recommendations of the PVP itself

Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

2012-08-19 Thread Chris Dornan

I agree with Bryan's proposal unreservedly. 

However, I think there might be a way to resolve the tension between:

  * maintaining and publishing a definite dependent-package configuration
that is known to work and

  * having a package unencumbered with arbitrary restrictions on which
future versions of its dependent packages it will work with.

Can't we have both? The cabal file would only eliminate package version that
are known not to work as Bryan suggests but the versions of the dependent
packages that the package has been tested with -- the 'reference
configuration' -- could be recorded separately. A separate build tool could
take the reference configuration and direct cabal to rebuild the reference
instance, specifying the fully qualified packages to use.

I have a set of tools for doing this because (see http://justhub.org -- and
if you have root access to an RPM-based Linux then the chances are you can
try it out, otherwise the sources are available).

For each project or package, separate from the cabal file recording the hard
dependencies,  I record the current reference configuration in a file which
lists the base installation (generally a Haskell platform but it can be a
bare compiler) and the list of fully-qualified dependent modules. Like the
cabal file the reference configuration would get checked into the VCS and/or
included in the Hackage tarball.

A normal build process first builds the environment ensuring that the
correct platform is selected and the exact package dependencies are
installed -- this is usually just a checking step unless the package
environment has been disturbed or the reference configuration has been
revised. Once the environment has been checked the normal program build
process proceeds as normal, where the real work generally happens.

Once the project is checked out on another system (or a package is installed
anew) the build step would actually build all of the dependent packages.

For this to really work a sandbox mechanism is needed -- merely trying out a
package/project shouldn't trash your only development environment! 

If a library package is to be integrated into a live project the reference
environment probably won't be the one you need but I find it useful to be
able to build it anyway in a clean environment and incrementally
up/downgrade the packages, searching out a compatible configuration. (Being
able to easily push and recover sandboxes is helpful here too.)

Would this way of working resolve the tension we are seeing here? I am so
used to working this way it is difficult for me to say.

(As others have said here and elsewhere, functional packaging is really
cool.)

Chris


-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of MightyByte
Sent: 16 August 2012 04:02
To: Ivan Lazar Miljenovic
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends

On Wed, Aug 15, 2012 at 9:19 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
 On 16 August 2012 08:55, Brandon Allbery allber...@gmail.com wrote:
 Indeed.  But the ghc release that split up base broke cabalised 
 packages with no warning to users until they failed to compile.  
 Upper bounds were put in place to avoid that kind of breakage in the
future.

 I like having upper bounds on version numbers... right up until people 
 abuse them.

I also tend to favor having upper bounds.  Obviously they impose a cost, but
it's not clear to me at all that getting rid of them is a better tradeoff.
I've had projects that I put aside for awhile only to come back and discover
that they would no longer build because I hadn't put upper bounds on all my
package dependencies.  With no upper bounds, a package might not be very
likely to break for incremental version bumps, but eventually it *will*
break.  And when it does it's a huge pain to get it building again.  If I
have put effort into making a specific version of my package work properly
today, I want it to always work properly in the future (assuming that
everyone obeys the PVP).  I don't think it's unreasonable that some
activation energy be required to allow one's project to work with a new
version of some upstream dependency.

Is that activation energy too high right now?  Almost definitely.  But
that's a tool problem, not a problem with the existence of upper bounds
themselves.  One tool-based way to help with this problem would be to add a
flag to Cabal/cabal-install that would cause it to ignore upper bounds.
(Frankly, I think it would also be great if Cabal/cabal-install enforced
upper version bounds automatically if none were specified.)  Another
approach that has been discussed is detecting dependencies that are only
used internally[1], and I'm sure there are many other possibilities.  In
short, I think we should be moving more towards purely functional builds
that reduce the chance that external factors will break things

Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

2012-08-16 Thread Chris Smith

I am tentatively in agreement that upper bounds are causing more
problems than they are solving.  However, I want to suggest that
perhaps the more fundamental issue is that Cabal asks the wrong person
to answer questions about API stability.  As a package author, when I
release a new version, I know perfectly well what incompatible changes
I have made to it... and those might include, for example:

1. New modules, exports or instances... low risk
2. Changes to less frequently used, advanced, or internal APIs...
moderate risk
3. Completely revamped commonly used interfaces... high risk

Currently *all* of these categories have the potential to break
builds, so require the big hammer of changing the first-dot version
number.  I feel like I should be able to convey this level of risk,
though... and it should be able to be used by Cabal.  So, here's a
proposal just to toss out there; no idea if it would be worth the
complexity or not:

A. Cabal files should get a new Compatibility field, indicating the
level of compatibility from the previous release: low, medium, high,
or something like that, with definitions for what each one means.

B. Version constraints should get a new syntax:

bytestring ~ 0.10.* (allow later versions that indicate low or
moderate risk)
bytestring ~~ 0.10.* (allow later versions with low risk; we use
the dark corners of this one)
bytestring == 0.10.* (depend 100% on 0.10, and allow nothing else)

Of course, this adds a good bit of complexity to the constraint
solver... but not really.  It's more like a pre-processing pass to
replace fuzzy constraints with precise ones.

-- 
Chris

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

Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

2012-08-16 Thread Chris Smith

Twan van Laarhoven twa...@gmail.com wrote:
 Would adding a single convenience function be low or high risk? You say it
 is low risk, but it still risks breaking a build if a user has defined a
 function with the same name.

Yes, it's generally low-risk, but there is *some* risk.  Of course, it
could be high risk if you duplicate a Prelude function or a name that
you know is in use elsewhere in a related or core library... these
decisions would involve knowing something about the library space,
which package maintainers often do.

 I think the only meaningful distinction you can make are:

Except that the whole point is that this is *not* the only distinction
you can make.  It might be the only distinction with an exact
definition that can be checked by automated tools, but that doesn't
change the fact that when I make an incompatible change to a library
I'm maintaining, I generally have a pretty good idea of which kinds of
users are going to be fixing their code as a result.  The very essence
of my suggestion was that we accept the fact that we are working in
probabilities here, and empower package maintainers to share their
informed evaluation.  Right now, there's no way to provide that
information: the PVP is caught up in exactly this kind of legalism
that only cares whether a break is possible or impossible, without
regard to how probable it is.  The complaint that this new mechanism
doesn't have exactly such a black and white set of criteria associated
with it is missing the point.

-- 
Chris

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

[Haskell-cafe] ANNOUNCE: time-recurrence-0.9.0

2012-08-02 Thread Chris Heller

I am happy to announce a new version of time-recurrence, a library of
functions for generating recurring sequences of dates:

http://hackage.haskell.org/package/time-recurrence

New in version 0.9.0 is a redesigned top layer API. Previously
recurrences were described by combining generating functions to get
the desired effect.

This was quite functional but had the drawback that a recurrence was
difficult to persist outside of the Haskell run-time. As of version
0.9.0 this limitation is no more. Now the actual recurrence rule is
defined by combining types into a data structure which can either be
persisted (and later read back) or evaluated into a function to
generate dates. This also means that the type system now enforces
correct rule creation!

Additionally some convenience functions are available to construct the
recurrence rule in a format familiar to previous users of this
library.

Here is a familiar example:

Generate the 15th and 30th of the month, but only during the work week:

 jan2011 = ptime Sat, 01 Jan 2012 00:00:00 -0400
 jan2012 = ptime Sun, 01 Jan 2013 00:00:00 -0400
 takeWhile (= jan2013) $ starting jan2012 $
   recur monthly
   == enum (Days [15,30])
   == filter (WeekDays [Monday .. Friday])

[2011-02-15 04:00:00 UTC
,2011-03-15 04:00:00 UTC, 2011-03-30 04:00:00 UTC
,2011-04-15 04:00:00 UTC
,2011-05-30 04:00:00 UTC
,2011-06-15 04:00:00 UTC, 2011-06-30 04:00:00 UTC
,2011-07-15 04:00:00 UTC
,2011-08-15 04:00:00 UTC, 2011-08-30 04:00:00 UTC
,2011-09-15 04:00:00 UTC, 2011-09-30 04:00:00 UTC
,2011-11-15 04:00:00 UTC, 2011-11-30 04:00:00 UTC
,2011-12-15 04:00:00 UTC, 2011-12-30 04:00:00 UTC
]

On the road to version 1.0, I plan to add another type layer which
strictly enforces RFC 5545 section 3.3.10.

As always I encourage feedback, criticism, suggestions and pull
requests. I would especially welcome any type system experts feedback:
quite a few GHC extensions needed to be turned on to get this to work.

-Chris

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

Re: [Haskell-cafe] Reddy on Referential Transparency

2012-07-31 Thread Chris Dornan

Uday Reddy has followed up with another substantial and interesting post on 
referential transparency here:


http://stackoverflow.com/questions/210835/what-is-referential-transparency/11740176#11740176

The thrust of his argument appears to be that functional programmers have 
created a lot of confusion around the ideas of referential transparency. I 
sympathize but I think he is going too far. 

As I see it, while the very close association of functional programming and 
related concepts with referential transparency may have led to some confusion 
around the concept that doesn't mean that the specific means that functional 
programmers have been using to increase (classically understood) RT in 
functional programs is somehow invalid.

Reddy has responded to my comment here

http://stackoverflow.com/a/11680011/306550

and I have followed up in turn.

Chris


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

Re: [Haskell-cafe] AI - machine learning

2012-07-30 Thread Chris Taylor

miro miroslav.karpis at gmail.com writes:

 
 Hi All, recently I started to take a look at haskell,
   especially at AI. I can see some email addresses of interested
   people there but not so much of other activity behind. Does it
   exist some mailing group especially for AI? 
   Basically I'm interested in trying some machine learning
   algorithms. Start with reinforcement learning and value-based),
   and go towards AGI (Artificial General Intelligence). Does anybody
   know about some already existing haskell approaches, or is there
   anybody working on this?
   Cheers,
   m.
 

Hi Miro

For the past month or so I've been working through some of the algorithms in 
Artificial Intelligence: A Modern Approach by Russell and Norvig, and 
implementing them in Haskell. The code is available on github 
(https://github.com/chris-taylor/aima-haskell), you may be interested in taking 
a look. I haven't written any code for reinforcement learning yet, though I 
have 
implemented value iteration and policy iteration for MDPs.

Chris


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

[Haskell-cafe] Reddy on Referential Transparency

Café,

For those who havent seen it Uday Reddy has a comprehensive answer to a
request
to explain referential transparency on Stack Overflow.

 
http://stackoverflow.com/questions/210835/what-is-referential-transparency/9
859966#9859966

For good measure he finishes with a rather scathing assessment of functional
programmers claim to ownership of RT:

Functional programmers don't know much of this research.
   Their ideas on referential transparency are to be taken
   with a large grain of salt.

Marvellous! 'Tis rare to find such a robust assessment combined with
understanding (and it certainly makes me think a bit).

Have we become a bit complacent about RT?

Chris



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

Re: [Haskell-cafe] Reddy on Referential Transparency

Claus Reinke [mailto:claus.rei...@talk21.com]:

 I happen to disagree with Reddy's assertion that having to explain a
complicated language
 with the help of a less complicated one is perfectly adequate. Reddy
himself has done good
 work on semantics of programming languages, but I'm a programmer first -
if the language
 I work with does not give me the qualities that its semantics give me,
then my means of
 expression and understanding are limited by the translation.

I also disagree. Haskell makes extensive use of translation into a core but
those translations
work so well because of the strong referential transparency guarantees that
you get with
Haskell.

Equational reasoning locally and leaning on types for refactoring are
intimately integrated into
my functional programming process (as I bet they are for most Haskell
programmers) -- I think
the academic promise of RT has become quite 'real'.

Something that may not be obvious to someone who doesn't program Haskell at
scale is the major
benefits of 'ghc -Wall'.  Working with the -Wall subset of Haskell (as many
do on production code)
problems with accidental variable capture is much more difficult to do -- a
terrific safeguard when
(equationally) working code.

Chris
 


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

Re: [Haskell-cafe] Reddy on Referential Transparency

 So a language is referentially transparent if replacing a sub-term with 
 another with the same
 denotation doesn't change the overall meaning?

Isn't this just summarizing the distinguishing characteristic of a denotational 
semantics?

My understanding is that RT is about how easy it is to carry out _syntactical_ 
transformations
of a program that preserve its meaning. For example, if you can freely and 
naively inline a
function definition without having to worry too much about context then your PL 
is deemed
to possess lots of RT-goodness (according to FP propaganda anyway; note you 
typically can't
freely inline function definitions in a procedural programming language because 
the actual
arguments to the function may involve dastardly side effects; even with a 
strict function-calling
semantics divergence will complicate matters).

Chris



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

Re: [Haskell-cafe] Reddy on Referential Transparency