Re: [Haskell-cafe] Mystery of an Eq instance

[Tom Ellis]

On Fri, Sep 20, 2013 at 09:47:24PM +0530, damodar kulkarni wrote:
 Ok, let's say it is the effect of truncation. But then how do you explain
 this?
 
 Prelude sqrt 10.0 == 3.1622776601683795
 True
 Prelude sqrt 10.0 == 3.1622776601683796
 True
 
 Here, the last digit **within the same precision range** in the fractional
 part is different in the two cases (5 in the first case and 6 in the second
 case) and still I am getting **True** in both cases.

What do you mean the same precision range?  Notice:

Prelude 3.1622776601683795 == 3.1622776601683796
True
Prelude 3.1622776601683795 == 3.1622776601683797
True
Prelude 3.1622776601683795 == 3.1622776601683798
False

The truncation happens base 2, not base 10.  Is that what's confusing you?

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

Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6

[Adam Foltzer]

Hi Carter,

Thanks for this heads up! Many of us here are cutting edge Mac users, and
would have been bitten by this.

Darin and I plan to spend some time next month preparing an unofficial
 patched version of ghc 7.6 that should play nice with clang / xcode 5,
 though at such a time ghc 7.8 will be in RC status at the very least.


Can this be backported to the 7.6.3 tag and released as 7.6.4? It would be
nice to not have to choose between running the latest xcode and the ability
to test multiple GHC versions.

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

Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6

[Carter Schonwald]

glad to help.

an alternative for the discerning power user is to install a recent version
of gcc locally (eg 4.8), and build 7.6.3 with that! (or just repoint your
ghc settings file to a locally built version of real gcc.)

yes, assuming we have the time (after all, it's all volunteer time), that
is the plan.


On Fri, Sep 20, 2013 at 1:50 PM, Adam Foltzer acfolt...@gmail.com wrote:

 Hi Carter,

 Thanks for this heads up! Many of us here are cutting edge Mac users, and
 would have been bitten by this.

 Darin and I plan to spend some time next month preparing an unofficial
 patched version of ghc 7.6 that should play nice with clang / xcode 5,
 though at such a time ghc 7.8 will be in RC status at the very least.


 Can this be backported to the 7.6.3 tag and released as 7.6.4? It would be
 nice to not have to choose between running the latest xcode and the ability
 to test multiple GHC versions.

 Cheers,
 Adam

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

[Haskell-cafe] Music update

[Mark Lentczner]

Some might remember me asking about music packages a while back... An
update:

I ended up using Euterpea, which in turn uses both Codec.Midi and
Sound.PortMidi. My working environment was to have my code loaded up in
ghci, play MIDI into a software MIDI bus, and pipe that into MainStage 3
which ran the synths.

The piece I was working on premiered last night at a concert in Wellington,
NZ. The live recording will take a while, but you can hear a studio synth
recording (from the above setup) here:

https://soundcloud.com/mtnviewmark/plain-changes-2-all-synth-mix


The code for the piece is all open source:
https://github.com/mzero/PlainChanges2. In particular, there is a somewhat
improved MIDI 
playerhttps://github.com/mzero/PlainChanges2/blob/master/src/Sound/MidiPlayer.hs
in
there.

Enjoy!

- Mark

P.S.: Yes, and now that that's done with, I can get on with the next
Haskell Platform release!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Demarcating monad transformers.

[Nickolay Kudasov]

Hi Café,

Below I describe what I call «demarcating monad transformer». It works
great for my purposes, though the construction feels a bit awkward.
Perhaps, this is just an instance of a general case. For details and
example, see [1] (single module package).

Recently I got a challenge of manipulating transformed monadic values. In
my case the value was of type t (Free f) a (or MonadFree m = t m a).
The challange itself was to provide a function:

transform :: (Functor f, MonadTrans t) = (forall b. f b - t (Free f)
b) - t (Free f) a - t (Free f) a

The type t (Free f) a for my purposes can be read as «a program with
low-level API specified with functor f and extra features specified with
monad transformer t».
transform takes a “basic transformation” phi and an abstract program p and
applies phi whenever p “executes” command of free functor f.

It turns out that this function is impossible (try StateT). The point is
that you can't “get inside” of transformed monadic value.

So I came up with idea of «demarcating» monad transformer. By «demarcating»
I mean separating pure monadic computations (lifted m a) from transformed
ones (t m a).

Such separation can be made explicit with the help of free monads:

data DemarcateF t m next
= forall b. DemarcateMonad   (m b) (b - next)  -- pure monadic
computation
| forall b. DemarcateTrans (t m b) (b - next)  -- transformed
monadic computation
instance Functor (Demarcate t m) where ...
-- getting monad for freenewtype Demarcate t m a = Demarcate {
unDemarcate :: Free (DemarcateF t m) a }
instance Monad (Demarcate t m) where ...instance MonadTrans (Demarcate
t) where ...

With that I can define transform functions:

-- transform arbitrary monadic computationtransformDemarcateM ::
(forall b. m b - Demarcate t m b) - Demarcate t m a - Demarcate t m
a
-- transform free monadic actionstransformDemarcateFree :: (forall b.
f b - Demarcate t (Free f) b) - Demarcate t (Free f) a - Demarcate
t (Free f) atransformDemarcateFree phi = transformDemarcateM (iterM
phi)

The complete code is available at [1]. Check out examples/simple.hs for a
use case.

Now the questions are:

   - has anyone else encountered such a challenge?
   - is this solution an instance of a more general pattern?
   - is it sensible to use Demarcate t m a when m is not a free monad?
   - how Demarcate may affect the performance?

Thanks in advance,
Nick

[1] https://github.com/fizruk/demarcatehttps://github.com/fizruk/demarcate
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mystery of an Eq instance

[damodar kulkarni]

 It seems to me that you're not familiar with the intricacies of
 floating-point arithmetic. You're not alone, it's one of the top questions
 on StackOverflow.

 Please find yourself a copy of What Every Computer Scientist Should Know
 About Floating-Point Arithmetic by David Goldberg, and read it. It should
 be very enlightening. It explains a bit about how IEEE754, pretty much the
 golden standard for floating point math, defines these precision rules.


I can imagine the following dialogue happening between His[1] Excellency,
the Lord Haskell (if I am allowed to anthropomorphize it) and me:
Me: My Lord, I just used the (==) on floats and it gave me some unpleasant
surprises.
Lord Haskell: You fool, why did you tested floats for equality? Don't you
know a bit about floating points?
Me: My Lord, I thought it'd be safe as it came with the typeclass
guarantee you give us.
Lord Haskell: Look, you fool you scum you unenlightened filthy soul, yes I
know I gave you that Eq instance for the floating point BUT nonetheless you
should NOT have used it; NOW go enlighten yourself.
Me: My Lord, thank you for the enlightenment.

I don't know how many people out there are being enlightened by His
Excellency, the Lord Haskell, on floating point equality and other things.
Yes, many a good old junkies, like the filthier kinkier C, were keen on
enlightening people on such issues. But, see, C is meant to be used for
such enlightenment.

Although I am not an expert on floating point numbers, the paper is not
surprising as I have learnt, at least some things given in the paper, the
hard way by burning myself a couple of times because of the floating point
thing while programming some things in the good old C.
But even the Haskell tempted to define an Eq instance for that scary thing
__that__ was a new enlightenment for me.

Life is full of opportunities to enlighten yourself.

That was also a reason before GHC 7.4 (Eq is no longer a superclass of Num).


This seems a good step forward, removing the Eq instance altogether on
floating point types would be much better; (unless as pointed out by
Brandon, you have a very clever representation that can store (floats) in
terms of some operation like sin(x) or ln(x) (with infinite precision))

I know I might be wrong in expecting this change as it might break a lot of
existing code. But why not daydream?

[1] Please read His/Her


Thanks and regards,
-Damodar Kulkarni


On Fri, Sep 20, 2013 at 10:04 PM, Stijn van Drongelen rhym...@gmail.comwrote:

 On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni 
 kdamodar2...@gmail.comwrote:

 Ok, let's say it is the effect of truncation. But then how do you explain
 this?

 Prelude sqrt 10.0 == 3.1622776601683795
 True
 Prelude sqrt 10.0 == 3.1622776601683796
 True


 Well, that's easy:

 λ: decodeFloat 3.1622776601683795
 (7120816245988179,-51)
 λ: decodeFloat 3.1622776601683796
 (7120816245988179,-51)

 On my machine, they are equal. Note that ...4 and ...7 are also equal,
 after they are truncated to fit in 53 (which is what `floatDigits 42.0`
 tells me) bits (`floatRadix 42.0 == 2`).

 Ok, again something like truncation or rounding seems at work but the
 precision rules the GHC is using seem to be elusive, to me.


 It seems to me that you're not familiar with the intricacies of
 floating-point arithmetic. You're not alone, it's one of the top questions
 on StackOverflow.

 Please find yourself a copy of What Every Computer Scientist Should Know
 About Floating-Point Arithmetic by David Goldberg, and read it. It should
 be very enlightening. It explains a bit about how IEEE754, pretty much the
 golden standard for floating point math, defines these precision rules.

 But more importantly, if one is advised NOT to test equality of two
 floating point values, what is the point in defining an Eq instance?


 Although equality is defined in IEEE754, it's not extremely useful after
 arithmetic (except perhaps for zero tests). Eq is a superclass of Ord,
 however, which is vital to using floating point numbers.

 Is the Eq instance there just to make __the floating point types__ members
 of the Num class?


 That was also a reason before GHC 7.4 (Eq is no longer a superclass of
 Num).

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

Re: [Haskell-cafe] Mystery of an Eq instance

[Mike Meyer]

On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni kdamodar2...@gmail.com
wrote:
 This seems a good step forward, removing the Eq instance altogether on
 floating point types would be much better; (unless as pointed out by
 Brandon, you have a very clever representation that can store
 (floats) in terms of some operation like sin(x) or ln(x) (with
 infinite precision))

Please don't. The problem isn't with the Eq instance. It does exactly
what it should - it tells you whether or not two floating point
objects are equal.

The problem is with floating point arithmetic in general. It doesn't
obey the laws of arithmetic as we learned them, so they don't behave
the way we expect. The single biggest gotcha is that two calculations
we expect to be equal often aren't. As a result of this, we warn
people not to do equality comparison on floats.

So people who don't understand that wind up asking Why doesn't this
behave the way I expect? Making floats not be an instance of Eq will
just cause those people to ask Why can't I compare floats for
equality?. This will lead to pretty much the same explanation. It
will also mean that people who know what they're doing who want to do
so will have to write their own code to do it.

It also won't solve the *other* problems you run into with floating
point numbers, like unexpected zero values from the hole around zero.

Given that we have both Data.Ratio and Data.Decimal, I would argue
that removing floating point types would be better than making them
not be an instance of Eq.

It might be interesting to try and create a floating-point Numeric
type that included error information. But I'm not sure there's a good
value for the expression 1.0±0.1  0.9±0.1.

Note that Brandon was talking about representing irrationals exactly,
which floats don't do. Those clever representations he talks about
will do that - for some finite set of irrationals. They still won't
represent all irrationals or all rationals - like 0.1 - exactly, so
the problems will still exist. I've done microcode implementations of
floating point representations that didn't have a hole around 0.  They
still don't work right.

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

[Haskell-cafe] ANN: tf-random 0.1 (splittable pseudorandom number generator)

[Michał Pałka]

Dear all,

I am happy to announce the release of tf-random 0.1. tf-random is a
high-quality splittable pseudorandom number generator intended to
address the random number quality problems of the standard Haskell
StdGen generator.

tf-random uses a cryptographic hash function under the hood to generate
pseudorandom numbers, which is based on the ThreeFish block cipher. The
design of the generator is explained in the paper 'Splittable
Pseudorandom Number Generators Using Cryptographic Hashing' by Claessen,
Pałka, which will be presented on the upcoming Haskell Symposium.

The performance of tf-random was found to be about 8% slower than StdGen
on typical QuickCheck properties, which make heavy use of splitting, but
up to 2x faster in linear generation on a x86-64 processor.

The package is available from hackage at:

http://hackage.haskell.org/package/tf-random

The code has not yet been thoroughly tested, so expect bugs. For
example, it has never been tried on a big-endian architecture, and I
would appreciate if somebody could check if the results returned by it
are the same (with a given random seed) as on x86.

In addition to the generator, the package also contains alternative
versions of the RandomGen and Random classes. The most notable
difference is that method 'next' from RandomGen returns a Word32 drawn
uniformly from its the full range. The reason for this change is that I
found it impossible to write efficient Random instances that are
parametrized over the range of the generator (genRange). The instances
currently defined in the random package make an (illegitimate)
assumption that the range of StdGen is used, for that matter.

I hope that this release will spark a discussion about the future of the
standard PRNG and the RandomGen API in Haskell.

Best regards,
Michał

PS. Please copy me when replying as I am not on the list.


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

[Haskell-cafe] Fwd: Functional Programming in Bioinformatics, Birds-of-a-Feather Session at CUFP

[Ashish Agarwal]

 Functional Programming in Bioinformatics
 Birds-of-a-Feather Session at CUFP 2013
   September 23, 2013 at 6:00 PM
  Boston, MA United States

Bioinformatics is a discipline applying computational methods to biological
problems. Due to advances in experimental techniques, especially in
next-generation DNA sequencing, the amount of data being generated by
biologists is exponentially increasing. The resulting data deluge promises
to accelerate fundamental advances in human health, agriculture, and basic
research. However, progress is hindered due to the lack of software tools
for managing, analyzing, visualizing, and sharing such data.

The goal of this meeting is to bring together researchers and practitioners
of functional programming, logic, type theory, and related fields who are
interested in applying their skills to biology and medicine. We also
welcome biologists who are curious about state-of-the-art software
engineering techniques. The meeting will be casual with no presentations.
Our goal is simply to meet and discuss our interests, and propose future
events and collaborations. We will meet at Connolly’s Publik House within
the conference venue, the Hilton Boston Logan Airport Hotel, on Monday
September 23rd at 6:00 PM.

Everyone is welcome to attend this meeting regardless of whether you
registered for any ICFP or CUFP events. RSVP is not required, but to help
with planning, please email “agarwal1975 at gmail.com” if you know you will
attend.

Please also join the Well-Formed-Bio mailing list [1], which we welcome
everyone to use for discussions around the topic of formal software methods
applied to biology.

[1] https://groups.google.com/forum/#!forum/well-formed-bio
[2]
http://cufp.org/conference/sessions/2013/birds-feather-functional-programming-bioinformatic

Organizers: Ashish Agarwal, Jeff Hammerbacher
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] cabal: internal error when reading package index

[Henk-Jan van Tuyl]

L.S.,

I was trying to install a package from a local drive and got the following  
message:

  cabal install
  Resolving dependencies...
  cabal: internal error when reading package index: could not read tar file
  entryThe package index or index cache is probably corrupt. Running cabal
  update might fix it.

Then I tried cabal update:
  cabal update
  Downloading the latest package list from hackage.haskell.org
  Skipping download: Local and remote files match.
  Note: there is a new version of cabal-install available.
  To upgrade, run: cabal install cabal-install

Trying the command
  cabal install cabal-install
gave the same internal error message as for the first command.

What can I do about this?

Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.

http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cabal: internal error when reading package index

[Ivan Lazar Miljenovic]

On 18 September 2013 19:23, Henk-Jan van Tuyl hjgt...@chello.nl wrote:

 L.S.,

 I was trying to install a package from a local drive and got the following
 message:
   cabal install
   Resolving dependencies...
   cabal: internal error when reading package index: could not read tar file
   entryThe package index or index cache is probably corrupt. Running cabal
   update might fix it.

 Then I tried cabal update:
   cabal update
   Downloading the latest package list from hackage.haskell.org
   Skipping download: Local and remote files match.
   Note: there is a new version of cabal-install available.
   To upgrade, run: cabal install cabal-install

 Trying the command
   cabal install cabal-install
 gave the same internal error message as for the first command.

 What can I do about this?

Maybe try deleting the current download?  Namely
~/.cabal/packages/hackage.haskell.org/00-index.*


 Regards,
 Henk-Jan van Tuyl


 --
 Folding@home
 What if you could share your unused computer power to help find a cure? In
 just 5 minutes you can join the world's biggest networked computer and get
 us closer sooner. Watch the video.
 http://folding.stanford.edu/


 http://Van.Tuyl.eu/
 http://members.chello.nl/hjgtuyl/tourdemonad.html
 Haskell programming
 --
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Multi-param typeclass vs locally constrained typeclass methods

[Jacques Carette]

Could someone please explain what the difference (if any!), in semantics 
is between


class Foo f = Bar f g where
  method1 :: f a - g a

and

class Bar' g where
  method2 :: Foo f = f a - g a

?  Maybe the translation of the above to something lower level might 
help.  [Note: f a - g a is just an example, and is not meaningful to 
the question].


The best answer would contain a design guideline for typeclasses, which 
would spell out conditions in which to use each variant.


Jacques


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

Re: [Haskell-cafe] Multi-param typeclass vs locally constrained typeclass methods

[Roman Cheplyaka]

* Jacques Carette care...@mcmaster.ca [2013-09-18 08:21:51-0400]
 Could someone please explain what the difference (if any!), in
 semantics is between
 
 class Foo f = Bar f g where
   method1 :: f a - g a
 
 and
 
 class Bar' g where
   method2 :: Foo f = f a - g a

Bar is more flexible than Bar'. If you have n types, you can write n^2
Bar instances (potentially having very different semantics) to convert
between them.

You can only write n Bar' instances, on the other hand. In these
instances you can dispatch based on 'g' but not on 'f'. 'f' is abstract,
and you only can access it through the Foo interface.

So they are quite different.

Roman


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

[Haskell-cafe] future (editor) of HCAR?

[Janis Voigtlaender]

Dear all,

The Haskell Communities and Activities Report has been produced twice a
year for more than ten years now:

http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report

I have been responsible for producing it the last few years, which was
fun. I am now looking to pass that on, handing over the HCAR to someone
else. Any takers?

Editing HCAR is a few days work per year, but it is also a great way to
be involved in the Haskell community - you get a lot of news first hand.
There are various procedures in place that automate some of the work,
and if someone is interested in taking over, I'm very willing to help
along, for example producing the next edition of the report together for
a smooth transition.

Below I attach the previous call for contributions, which also answers
some basic questions about the report. For further questions about the
process etc., anybody interested simply get in touch with me.

Also, such a transition is a good opportunity to rethink model and
processes. Maybe you (anybody on the mailing list) have completely new
ideas for how the HCAR should be organized? How it could function
better? What other purposes it could serve than it has so far? ...
(Or even that HCAR in its existing form is not needed anymore, but could
be replaced by something great new?)

Best,
Janis.


 Original-Nachricht 
Betreff: Call for Contributions - Haskell Communities and Activities 
Report, May 2013 edition

Datum: Mon, 08 Apr 2013 21:56:19 +0200
Von: Janis Voigtländer j...@informatik.uni-bonn.de
An: Haskell hask...@haskell.org

Dear all,

I would like to collect contributions for the 24th edition of the


 Haskell Communities  Activities Report

http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report

Submission deadline: 1 May 2013

 (please send your contributions to hcar at haskell.org,
 in plain text or LaTeX format)


This is the short story:

* If you are working on any project that is in some way related
  to Haskell, please write a short entry and submit it. Even if
  the project is very small or unfinished or you think it is not
  important enough --- please reconsider and submit an entry anyway!

* If you are interested in an existing project related to Haskell that
  has not previously been mentioned in the HCAR, please tell me, so
  that I can contact the project leaders and ask them to submit an
  entry.

* Feel free to pass on this call for contributions to others that
  might be interested.

More detailed information:

The Haskell Communities  Activities Report is a bi-annual overview of
the state of Haskell as well as Haskell-related projects over the
last, and possibly the upcoming six months. If you have only recently
been exposed to Haskell, it might be a good idea to browse the
previous edition --- you will find interesting projects described as
well as several starting points and links that may provide answers to
many questions.

Contributions will be collected until the submission deadline. They
will then be compiled into a coherent report that is published online
as soon as it is ready. As always, this is a great opportunity to
update your webpages, make new releases, announce or even start new
projects, or to talk about developments you want every Haskeller to
know about!

Looking forward to your contributions,

Janis (current editor)


FAQ:

Q: What format should I write in?

A: The required format is a LaTeX source file, adhering to the template
that is available at:

 http://haskell.org/communities/05-2013/template.tex

There is also a LaTeX style file at

 http://haskell.org/communities/05-2013/hcar.sty

that you can use to preview your entry. If you do not know LaTeX, then
use plain text. If you modify an old entry that you have written for an
earlier edition of the report, you should already have received your old
entry as a template (provided I have your valid email address). Please
modify that template, rather than using your own version of the old
entry as a template.

Q: Can I include Haskell code?

A: Yes. Please use lhs2tex syntax (http://people.cs.uu.nl/andres/lhs2tex/).
The report is compiled in mode polycode.fmt.

Q: Can I include images?

A: Yes, you are even encouraged to do so. Please use .jpg format, then.

Q: Should I send files in .zip archives or similar?

A: No, plain file attachements are the way.

Q: How much should I write?

A: Authors are asked to limit entries to about one column of text. A
general introduction is helpful. Apart from that, you should focus on
recent or upcoming developments. Pointers to online content can be given
for more comprehensive or historic overviews of a project. Images do
not count towards the length limit, so you may want to use this
opportunity to pep up entries. There is no minimum 

Re: [Haskell-cafe] future (editor) of HCAR?

[Alejandro Serrano Mena]

I would be delighted to take the full responsibility (or just help) in the
HCAR.
I have some ideas, maybe I could get some time later to write them down.


2013/9/18 Janis Voigtlaender j...@informatik.uni-bonn.de

 Dear all,

 The Haskell Communities and Activities Report has been produced twice a
 year for more than ten years now:

 http://www.haskell.org/**haskellwiki/Haskell_**Communities_and_Activities_
 **Reporthttp://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report

 I have been responsible for producing it the last few years, which was
 fun. I am now looking to pass that on, handing over the HCAR to someone
 else. Any takers?

 Editing HCAR is a few days work per year, but it is also a great way to
 be involved in the Haskell community - you get a lot of news first hand.
 There are various procedures in place that automate some of the work,
 and if someone is interested in taking over, I'm very willing to help
 along, for example producing the next edition of the report together for
 a smooth transition.

 Below I attach the previous call for contributions, which also answers
 some basic questions about the report. For further questions about the
 process etc., anybody interested simply get in touch with me.

 Also, such a transition is a good opportunity to rethink model and
 processes. Maybe you (anybody on the mailing list) have completely new
 ideas for how the HCAR should be organized? How it could function
 better? What other purposes it could serve than it has so far? ...
 (Or even that HCAR in its existing form is not needed anymore, but could
 be replaced by something great new?)

 Best,
 Janis.


  Original-Nachricht 
 Betreff: Call for Contributions - Haskell Communities and Activities
 Report, May 2013 edition
 Datum: Mon, 08 Apr 2013 21:56:19 +0200
 Von: Janis Voigtländer j...@informatik.uni-bonn.de
 An: Haskell hask...@haskell.org

 Dear all,

 I would like to collect contributions for the 24th edition of the

 ==**==**
  Haskell Communities  Activities Report

 http://www.haskell.org/**haskellwiki/Haskell_**Communities_and_Activities_
 **Reporthttp://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report

 Submission deadline: 1 May 2013

  (please send your contributions to hcar at haskell.org,
  in plain text or LaTeX format)
 ==**==**

 This is the short story:

 * If you are working on any project that is in some way related
   to Haskell, please write a short entry and submit it. Even if
   the project is very small or unfinished or you think it is not
   important enough --- please reconsider and submit an entry anyway!

 * If you are interested in an existing project related to Haskell that
   has not previously been mentioned in the HCAR, please tell me, so
   that I can contact the project leaders and ask them to submit an
   entry.

 * Feel free to pass on this call for contributions to others that
   might be interested.

 More detailed information:

 The Haskell Communities  Activities Report is a bi-annual overview of
 the state of Haskell as well as Haskell-related projects over the
 last, and possibly the upcoming six months. If you have only recently
 been exposed to Haskell, it might be a good idea to browse the
 previous edition --- you will find interesting projects described as
 well as several starting points and links that may provide answers to
 many questions.

 Contributions will be collected until the submission deadline. They
 will then be compiled into a coherent report that is published online
 as soon as it is ready. As always, this is a great opportunity to
 update your webpages, make new releases, announce or even start new
 projects, or to talk about developments you want every Haskeller to
 know about!

 Looking forward to your contributions,

 Janis (current editor)


 FAQ:

 Q: What format should I write in?

 A: The required format is a LaTeX source file, adhering to the template
 that is available at:

  
 http://haskell.org/**communities/05-2013/template.**texhttp://haskell.org/communities/05-2013/template.tex

 There is also a LaTeX style file at

  
 http://haskell.org/**communities/05-2013/hcar.styhttp://haskell.org/communities/05-2013/hcar.sty

 that you can use to preview your entry. If you do not know LaTeX, then
 use plain text. If you modify an old entry that you have written for an
 earlier edition of the report, you should already have received your old
 entry as a template (provided I have your valid email address). Please
 modify that template, rather than using your own version of the old
 entry as a template.

 Q: Can I include Haskell code?

 A: Yes. Please use lhs2tex syntax (http://people.cs.uu.nl/**
 andres/lhs2tex/ http://people.cs.uu.nl/andres/lhs2tex/).
 The report is compiled in mode polycode.fmt.

 

Re: [Haskell-cafe] Multi-param typeclass vs locally constrained typeclass methods

[Jacques Carette]

On 13-09-18 08:54 AM, Roman Cheplyaka wrote:

* Jacques Carette care...@mcmaster.ca [2013-09-18 08:21:51-0400]

Could someone please explain what the difference (if any!), in
semantics is between

class Foo f = Bar f g where
   method1 :: f a - g a

and

class Bar' g where
   method2 :: Foo f = f a - g a

Bar is more flexible than Bar'. If you have n types, you can write n^2
Bar instances (potentially having very different semantics) to convert
between them.

You can only write n Bar' instances, on the other hand. In these
instances you can dispatch based on 'g' but not on 'f'. 'f' is abstract,
and you only can access it through the Foo interface.

So they are quite different.


Right, that makes sense, thanks.

Turns out that, in my case, I frequently want the Bar' case, as I want 
things to be fully polymorphic in Foo.


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

Re: [Haskell-cafe] OS X ghci problem

[Carter Schonwald]

The ghci bug goes away when you use a ghc head snapshot from late summer?
Great!


On Wednesday, September 18, 2013, Jan-Philip Loos wrote:

 Sadly I was not able to use your build directly, because ghc(i)
 searched libs in a invalid path (it seems to be wired to one of your
 directories). I tried to build this ghc version from source on my own,
 without success beyond stage 1. This [1] is related to the build
 failure. I tried new alex and happy versions, without any change. A
 naive approach was to compile alex/happy with ghc_stage1 compiler,
 without success (as I expected due missing TH). I tried several ghc
 versions for bootstrapping and alex/happy rebuilding (i guess ghc 
 7.6 is necessary for a valid 7.7 alex/happy build with the new Bool
 primops), without success too.

 Finally I ended in a fully self build ghc 7.7.20130730 ([2]) and with
 this ghc I can confirm that this specific error with
 Binding.GLFW.c'glfwInit is gone :) Thanks

 [1] http://www.mail-archive.com/ghc-devs@haskell.org/msg02357.html
 [2]
 http://darcs.haskell.org/ghcBuilder/uploads/tn23/ghc-7.7.20130730-src.tar.bz2

 On Mon, Sep 16, 2013 at 2:52 PM, Christiaan Baaij
 christiaan.ba...@gmail.com javascript:; wrote:
  Here's a binary dist of my build:
 https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2
  In case someone wants to confirm my findings.
 
  Cheers,
 
  Christiaan
 
  On Sep 16, 2013, at 2:24 PM, Christiaan Baaij 
 christiaan.ba...@gmail.com javascript:; wrote:
 
  Hi,
 
  I saw the same issue/crash on my machine using ghc 7.6.3.
 
  I just build a perf build of GHC-head with
  85a9e2468dc74b9e5ccde0dd61be86219fd323a2 as the latest commit.
 
  Now running, I get:
  1)  cabal install bindings-glfw
  2)  ghci
  3) ghci :m Bindings.GLFW
  4) ghci Bindings.GLFW.c'glfwInit
  5) ghci 1
 
  And doing:
  1.)  cabal install GLFW-b
  2.)  ghci -package GLFW-b
  3.) ghci import Graphics.UI.GLFW as GLFW
  4.) ghci GLFW.init
  5.) ghci True
 
  My platform:
  - OSX 10.8.4
  - ghc(i) 7.7.20130915
  - cabal 1.18.0.1 (using 1.18.0 of the Cabal library)
  - xcode cltools 4.6.2
 
  So it seems that the new ghci linking infrastructure fixes things
 
  Cheers,
 
  Christiaan
 
  On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos 
  maxda...@gmail.comjavascript:;
 wrote:
 
  What I do for GLFW is use a dylib, then you don't rely on GHCi's
 static-ish linker.
  The only wrinkle is figuring out where you want the dylib.
  I think homebrew will put one in /usr/local/lib, which works out
 nicely, but they don't have GLFW 3 yet.
  Another option is to build the dylib yourself from the GLFW source
 bundled with the GLFW-b package, then tell cabal where to find it.
 
  Hi,
  for me the problem relocates now to the bindings-glfw package, since
  the native bindings moved to this package and are wrapped up with
  glfw-b.
 
  My way to the same exception already mentioned by Brian Lewis:
  1)  cabal install bindings-glfw
  2)  ghci
  3) ghci :m Bindings.GLFW
  4) ghci Bindings.GLFW.c'glfwInit
  5) ghci terminates with exception: *** Terminating app due to uncaught
  exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool
  init]: unrecognized selector sent to instance 0x7fc443c01b30'
 
  Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no
  clue how to do this. I built the according glfw version on my own as a
  dylib and loaded ghci with it explicitly, this didn't help. I guess
  the compiled bindings-glfw is already statically packed up.
 
  How can I get ghci to use the native glfw dylib in combination with
  bindings-glfw? If I have to compile bindings-glfw with different
  settings, which settings? I have some oversight over haskell but no
  really deep knowledge according to bindings and lib-loading of ghci,
  but I'm willing to learn it ;)
 
  My Platform:
  - OSX 10.8.5
  - ghc(i) 7.6.3
  - cabal 1.18.0.1
  - xcode dev tools 4.6.3
 
  Thanks and Greetings
 
  Jan
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org javascript:;
  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] Haskell Weekly News: Issue 280

[Daniel Santa Cruz]

Welcome to issue 280 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers the
week of September 8 to 14, 2013.

Quotes of the Week

   * haasn: edwardk uses things in anger. shachaf uses them with
 disappointment :(

   * shachaf: Are you reading Mac Lane now? Saizan: yeah, it's not so
 bad if you skip the examples

Top Reddit Stories

   * For my 17th birthday, my best friend got me The most obscure
programming book I could find as a joke. I know what language I am
learning next!
 Domain: i.imgur.com, Score: 163, Comments: 67
 On Reddit: [1] http://goo.gl/0SyN5l
 Original: [2] http://goo.gl/oqGBzL

   * pipes-4.0: Simpler types and API
 Domain: haskellforall.com, Score: 95, Comments: 36
 On Reddit: [3] http://goo.gl/ciVnq5
 Original: [4] http://goo.gl/g9oq3i

   * Hackage 2 now available for beta testing -- switchover in a few weeks
 Domain: beta.hackage.haskell.org, Score: 91, Comments: 17
 On Reddit: [5] http://goo.gl/aIhL67
 Original: [6] http://goo.gl/zfprr9

   * Cartesian Closed Comic #22: Cabal 1.18
 Domain: ro-che.info, Score: 90, Comments: 3
 On Reddit: [7] http://goo.gl/tVUUFG
 Original: [8] http://goo.gl/O0BR6c

   * Parallel and Incremental CRCs by Edward Kmett
 Domain: fpcomplete.com, Score: 58, Comments: 7
 On Reddit: [9] http://goo.gl/YAChJl
 Original: [10] http://goo.gl/WnMsbY

   * Conquering Folds by Edward Kmett
 Domain: fpcomplete.com, Score: 47, Comments: 42
 On Reddit: [11] http://goo.gl/reAjgu
 Original: [12] http://goo.gl/kHsSye

   * Conal Elliot: From Haskell to hardware via cartesian closed categories
 Domain: conal.net, Score: 47, Comments: 3
 On Reddit: [13] http://goo.gl/VCwp7Y
 Original: [14] http://goo.gl/NO1sbs

   * FP Complete to release a personal edition of their online IDE
 Domain: fpcomplete.com, Score: 39, Comments: 38
 On Reddit: [15] http://goo.gl/QOMy5Y
 Original: [16] http://goo.gl/XBE7zT

   * Quark : A Web Browser with a Formally Verified Kernel
 Domain: goto.ucsd.edu, Score: 36, Comments: 6
 On Reddit: [17] http://goo.gl/RDZMY0
 Original: [18] http://goo.gl/rgBcki

   * My first Haskell program - FNIStash - a utility for Torchlight 2 using
threepenny for the GUI
 Domain: fluffynukeit.com, Score: 36, Comments: 19
 On Reddit: [19] http://goo.gl/cK2N8v
 Original: [20] http://goo.gl/XOMTgQ

   * Conal Elliott: Overloading lambda
 Domain: conal.net, Score: 34, Comments: 4
 On Reddit: [21] http://goo.gl/fQTt1P
 Original: [22] http://goo.gl/oPSQ3R

   * Cost semantics for STG in modern GHC
 Domain: blog.ezyang.com, Score: 31, Comments: 5
 On Reddit: [23] http://goo.gl/mIQQxm
 Original: [24] http://goo.gl/5Sa49T

   * 0install - Python vs. OCaml vs. Haskell
 Domain: roscidus.com, Score: 31, Comments: 23
 On Reddit: [25] http://goo.gl/htCf1x
 Original: [26] http://goo.gl/zhrVp0

   * LogicGrowsOnTrees: a parallel implementation of logic programming
using distributed tree exploration
 Domain: github.com, Score: 31, Comments: 9
 On Reddit: [27] http://goo.gl/zp5lou
 Original: [28] http://goo.gl/5BgYh2

   * RSS reader made by Haskell running on mbed platform (RAM size 64kB,
using Ajhc Haskell compiler).
 Domain: youtube.com, Score: 30, Comments: 5
 On Reddit: [29] http://goo.gl/n0Gkan
 Original: [30] http://goo.gl/cwL4vP

   * Conal Elliott: Optimizing CCCs
 Domain: conal.net, Score: 30, Comments: 12
 On Reddit: [31] http://goo.gl/HVv8dr
 Original: [32] http://goo.gl/MCn0sO

   * Snap (and Heist) 0.13 released
 Domain: snapframework.com, Score: 29, Comments: 7
 On Reddit: [33] http://goo.gl/zW5Sdn
 Original: [34] http://goo.gl/1wSLeJ

   * ANN: threepenny-gui-0.3 – GUI framework that uses the web browser as a
display – now with FRP built-in
 Domain: apfelmus.nfshost.com, Score: 28, Comments: 8
 On Reddit: [35] http://goo.gl/RUDrKD
 Original: [36] http://goo.gl/WZMeZN

Top StackOverflow Questions

   * In Haskell, where does the range ['a'..] stop?
 votes: 20, answers: 2
 Read on SO: [37] http://goo.gl/Oms7lr

   * Why were Haskell 98's standard classes made inferior to Haskell 1.3's?
 votes: 18, answers: 1
 Read on SO: [38] http://goo.gl/WxvdL2

   * 27 different Bool to Bool values in Haskell
 votes: 14, answers: 1
 Read on SO: [39] http://goo.gl/1PcD1g

   * How to reconstruct Haskell expression from type
 votes: 10, answers: 1
 Read on SO: [40] http://goo.gl/Qx06kz

   * Can links to anchors in haddock be labeled?
 votes: 8, answers: 0
 Read on SO: [41] http://goo.gl/5deOMM

   * How to convert between ByteString and Storable Vector?
 votes: 7, answers: 1
 Read on SO: [42] http://goo.gl/zBVVzI

   * Why is not GHC optimizing for constants?
 votes: 7, answers: 2
 Read on SO: [43] http://goo.gl/sfo64S

   * newtype around ST 

[Haskell-cafe] ANN Vigilance: Get notified when periodical tasks fail to run successfully

[Michael Xavier]

Hey Cafe,

Just wanted to announce a project I've been tinkering with for a while
finally got to a state where I felt comfortable releasing it. Vigilance is
a Dead Man's Switch system that notifies you when periodical tasks that
fail to check in when you expected them to.

An example of this could be registering the daily backups you do of your
servers and have them send emails or send HTTP POST requests if backups
ever fail to check in. Vigilance provides an executable for doing check-ins
and inspecting your watches as well as a simple REST API if you need
something embeddable for existing projects.

HackageDB: http://hackage.haskell.org/package/vigilance
Github: http://github.com/michaelxavier/vigilance
Introductory blog post:
http://michaelxavier.net/posts/2013-09-17-Announcing-Vigilance-An-Extensible-Dead-Man-s-Switch-System.html


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

Re: [Haskell-cafe] Proposal: Pragma EXPORT

[Evan Laforge]

 It also makes actual definitions cleaner/shorter rather than
 cluttering them with extra annotations (either PRAGMAs or
 public/private markers), though this is not that big of a deal.

It's true, though you could get it pretty short, e.g. default private
and leading ! for public.  Go uses capitalization, though that's
already taken for haskell.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] plugins fails on a simple example

[Petr Pudlák]

Any ideas what could be causing the problem? I could try creating a 
patch, but I have no clue where to start.


  Best regards,
  Petr

Dne 09/16/2013 11:12 PM, Jeremy Shaw napsal(a):

plugins probably needs to be patched[1]. I'll happily apply such a patch.

- jeremy
[1] or rewritten from the ground up


On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák petr@gmail.com 
mailto:petr@gmail.com wrote:


Hi,

I'm playing with “plugins”, trying to evaluate a simple expression:

|import  Control.Monad
import  System.Eval.Haskell

main  =do
 let  fExpr =1 + 2 :: Int
 r - eval_ fExpr [Prelude] [] [] []
 ::IO  (Either  [String] (Maybe  Int))
 case  rof
 Right  (Just  f)  -do
 print $ f
 Left  err - putStrLn $Error:  ++ unlines err
 _ - putStrLn $Unknown error.|

However, it fails with

|Error:
on the commandline: Warning:
 -fglasgow-exts is deprecated: Use individual extensions instead|

Am I doing something wrong? How can I turn off the flag?

I'm using GHC 7.6.3.

Thanks,
Petr


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org mailto: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] reifying typeclasses

[Evan Laforge]

Thanks to everyone who replied, indeed it looks like GADTs do what I
claimed I wanted. That's neat because I've never been able to think of
a use for them.  However:

On Sun, Sep 15, 2013 at 2:16 AM,  o...@okmij.org wrote:
 Why not to introduce several type classes, even a type class for each
 method if necessary. Grouping methods under one type class is
 appropriate when such a grouping makes sense. Otherwise, Haskell won't
 lose in expressiveness if a type class could have only one method.

That's a very good point too, and one I should have thought of first.
 It's the simplest and I think most idiomatic.  Ok, I guess I'm back
to not being able to think of a use for GADTs, it seems like that
happens whenever I think I have a use for a fancy feature :)

 The main drawback of the intensional type analysis as shown in the
 enclosed code is that it breaks parametricity. The constraint Eq a

I guess what you're saying is that since I'm implementing a
typeswitch, then I lose the nice feature of typeclasses that I know it
can't do anything with the value except what the typeclass provides.
In a sense, it loses type safety because it's too generic.  That's a
good point too.  No free lunch, I guess, you get one thing and lose
another.  Typeclasses, though, don't exploit the closed universe part,
though I can't think offhand how that hurts me.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] reifying typeclasses

[oleg]

 I've been toying with using Data Types a la Carte to get type
 representations, a `Typeable` class and dynamic types parameterized by a
 possibly open universe:

If the universe is potentially open, and if we don't care about
exhaustive pattern-matching check (which is one of the principal
benefits of GADTs -- pronounced in dependently-typed languages), the
problem can be solved far more simply. No type classes, no instances,
no a la Carte, to packages other than the base.

{-# LANGUAGE ScopedTypeVariables #-}

module GG where

import Data.Typeable

argument :: Typeable a = a - Int
argument a
 | Just (x::Int)  - cast a = x
 | Just (x::Char) - cast a = fromEnum x

result :: Typeable a = Int - a
result x
  | Just r  - cast (id x)  = r
  | Just r  - cast ((toEnum x)::Char)  = r

t1 = argument 'a'
t2 = show (result 98 :: Char)


That is it, quite symmetrically. This is essentially how type classes
are implemented on some systems (Chameleoon, for sure, and probably
JHC). By this solution we also gave up on parametricity. Which is why
such a solution is probably better kept `under the hood', as an
implementation of type classes.

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

Re: [Haskell-cafe] Readable GHC 7.6.3 docs (Bootstrapped)

[Obscaenvs]

Update: some of the headers were not anchored, due to there being those
accursed newlines in them. I have now corrected this, and I hope that
now all headers are anchored in the way you suggested (that I found
useful, too - of course. One can only wonder why the official docs
aren't made thus.)

Tarball available as usual, from first page (bugthunk.net).

f

Le 2013-09-11 14:59, Niklas Hambüchen a écrit :
 Looks pleasing! I have one feature request:
 
 Could you make headings links, or add anchors next to them (github 
 readme style), such that I can directly share what I'm reading with 
 people?
 
 On Wed 11 Sep 2013 20:31:30 JST, Obscaenvs wrote:
 At [1] you can find links to the GHC documentation that I use myself,
 since the official version is a bit too TimesNewRoman-y for my
 ...developed taste. It available in a downloadable Bzipped TAR aswell
 as being browsable online.

 [1] http://bugthunk.net/

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

-- 
bugthunk.net
monoid.se
@MonoidSe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6

[Obscaenvs]

Wow, thank you for the heads up!

f

Le 2013-09-17 05:16, Carter Schonwald a écrit :
 Hey everyone,
 
 if you are actively using ghc 7.6 on your mac, 
 for now please do not install xcode 5.
 
 It will break your ghc install, because 7.6 doesn't  know how to
 correctly use Clang for the CPP work. (ghc head / and thus 7.8 will work
 fine with xcode 5, thanks to some outstanding work by Austin Seipp, 7.6
 does not)
 
 if you do not need xcode 5, and you're actively using ghc 7.6, stay with
 xcode 4.6 for now.
 
 if you installed xcode 5 because its there, and now your ghc 7.6 is
 occasionally giving you strange errors involving CPP parse failures on
 fragments  like #-}, you should go to the apple developers website,
 download, and reinstall the xcode 4.6 CLI tools.
 
 
 if you need both xcode 5 and ghc in working order *right now, tomorrow*,
 either
 
 a) live on the wildside: test out using ghc head: also means you could
 play with ghc-ios too!
 
 b) if you need both in working order now, and stabilish, Darin Morrison
 has a set of mac-homebrew taps that should be you use
  https://github.com/darinmorrison/homebrew-haskell 
 these taps should be regarded as more official and canonical than
 the formula's that brew provides (the normal brew ones recurrently have
 problems induced by folks who aren't haskell devs)
 
 c) wait  a wee bit till 7.8 lands in all its glory, and have both the
 freshest of xcodes, and the newest of  awesome ghcs
 
 tl;dr
 
 if you don't  need xcode 5, having xcode 4.6 CLI tools installed will
 stand you in good stead.
 
 if you are on os x mavericks, or absolutely need xcode 5 installed, and
 you want a ghc thats already released, use darin's brew
 formulae https://github.com/darinmorrison/homebrew-haskell
 
 
 Darin and I plan to spend some time next month preparing an unofficial
 patched version of ghc 7.6 that should play nice with clang / xcode 5,
 though at such a time ghc 7.8 will be in RC status at the very least.
 
 
 cheers
 
 -Carter
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 

-- 
bugthunk.net
monoid.se
@MonoidSe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] name lists

[Roman Cheplyaka]

* Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
 Another approach might be to introduce some notion of a name list which
 can appear in the export list. These lists could be built up by either
 user declarations in the source module or in Template Haskell splices
 and would serve as a way to group logically related exports. This
 would allow uses such as (excuse the terrible syntax),
 
 module HelloWorld ( namelist MyDataLenses
   , namelist ArithmeticOps
   ) where
 
 import Control.Lens
 
 data MyData = MyData { ... }
 makeLenses ''MyDataLenses
 -- makeLenses defines a namelist called MyDataLenses
 
 namelist ArithmeticOps (add)
 add = ...
 
 namelist ArithmeticOps (sub)
 sub = ...

Hi Ben,

Isn't this subsumed by ordinary Haskell modules, barring the current
compilers' limitation that modules are in 1-to-1 correspondence with
files (and thus are somewhat heavy-weight)?

E.g. the above could be structured as

  module MyDataLenses where
data MyData = MyData { ... }
makeLenses ''MyData

  module HelloWorld (module MyDataLenses, ...) where
...

Roman


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

Re: [Haskell-cafe] Proposal: Pragma EXPORT

[Ben Gamari]

Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:

 On 17 September 2013 09:35, Evan Laforge qdun...@gmail.com wrote:

snip

 None of this is a big deal, but I'm curious about other's opinions on
 it.  Are there strengths to the separate export list that I'm missing?

 I do like the actual summary aspect as you've noted, as I can at
 times be looking through the actual code rather than haddock
 documentation when exploring new code (or even trying to remember what
 I wrote in old code).

The summary of functionality that the export list provides is a very
nice feature that I often miss in other languages.

That being said, it brings up a somewhat related issue that may become
increasingly problematic with the rising use of libraries such as
lens: exporting members defined by Template Haskell. While we have nice
sugar for exporting all accessors of a record (MyRecord(..)), we have no
way to do the same for analogous TH-generated members such as
lenses. Instead, we require that the user laboriously list each member
of the record, taking care not to forget any.

One approach would be to simply allow TH to add exports as presented in
Ticket #1475 [1]. I can't help but wonder if there's another way, however. 
One (questionable) option would be to allow globbing patterns in export
lists.

Another approach might be to introduce some notion of a name list which
can appear in the export list. These lists could be built up by either
user declarations in the source module or in Template Haskell splices
and would serve as a way to group logically related exports. This
would allow uses such as (excuse the terrible syntax),

module HelloWorld ( namelist MyDataLenses
  , namelist ArithmeticOps
  ) where

import Control.Lens

data MyData = MyData { ... }
makeLenses ''MyDataLenses
-- makeLenses defines a namelist called MyDataLenses

namelist ArithmeticOps (add)
add = ...

namelist ArithmeticOps (sub)
sub = ...

That being said, there are a lot of reasons why we wouldn't want to
introduce such a mechanism,

  * we'd give up the comprehensive summary that the export list
currently provides

  * haddock headings already provides a perfectly fine means for
grouping logically related exports

  * it's hard to envision the implementation of such a feature without
the introduction of new syntax

  * there are arguably few uses for such a mechanism beyond exporting TH
constructs

  * you still have the work of solving the issues presented in #1475

Anyways, just a thought.

Cheers,

- Ben


[1] http://ghc.haskell.org/trac/ghc/ticket/1475


pgpoddlH92BBj.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] name lists

[Ben Gamari]

Roman Cheplyaka r...@ro-che.info writes:

 * Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
 Another approach might be to introduce some notion of a name list which
 can appear in the export list. These lists could be built up by either
 user declarations in the source module or in Template Haskell splices
 and would serve as a way to group logically related exports. This
 would allow uses such as (excuse the terrible syntax),

 Hi Ben,

 Isn't this subsumed by ordinary Haskell modules, barring the current
 compilers' limitation that modules are in 1-to-1 correspondence with
 files (and thus are somewhat heavy-weight)?

 E.g. the above could be structured as

   module MyDataLenses where
 data MyData = MyData { ... }
 makeLenses ''MyData

   module HelloWorld (module MyDataLenses, ...) where
 ...

True. Unfortunately I've not seen much motion towards relaxing this
limitation[1].

Cheers,

- Ben


[1] http://ghc.haskell.org/trac/ghc/ticket/2551


pgpjfzeZUOpNI.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] plugins fails on a simple example

[Jeremy Shaw]

Probably just what it says -- plugins is calling ghc and passing the
-fglasgow-exts flag. I would try just removing that flag.

- jeremy


On Tue, Sep 17, 2013 at 2:08 AM, Petr Pudlák petr@gmail.com wrote:

  Any ideas what could be causing the problem? I could try creating a
 patch, but I have no clue where to start.

   Best regards,
   Petr

 Dne 09/16/2013 11:12 PM, Jeremy Shaw napsal(a):

 plugins probably needs to be patched[1]. I'll happily apply such a patch.

  - jeremy
 [1] or rewritten from the ground up


  On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák petr@gmail.com wrote:

  Hi,

 I'm playing with “plugins”, trying to evaluate a simple expression:

 import Control.Monadimport System.Eval.Haskell
 main = do
 let fExpr = 1 + 2 :: Int
 r - eval_ fExpr [Prelude] [] [] []
 :: IO (Either [String] (Maybe Int))
 case r of
 Right (Just f)  - do
 print $ f
 Left err - putStrLn $ Error:  ++ unlines err
 _ - putStrLn $ Unknown error.

 However, it fails with

 Error:
 on the commandline: Warning:
 -fglasgow-exts is deprecated: Use individual extensions instead

 Am I doing something wrong? How can I turn off the flag?

 I'm using GHC 7.6.3.

 Thanks,
 Petr

 ___
 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] name lists

[Roman Cheplyaka]

* Ben Gamari bgamari.f...@gmail.com [2013-09-17 12:41:05-0400]
 Roman Cheplyaka r...@ro-che.info writes:
 
  * Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
  Another approach might be to introduce some notion of a name list which
  can appear in the export list. These lists could be built up by either
  user declarations in the source module or in Template Haskell splices
  and would serve as a way to group logically related exports. This
  would allow uses such as (excuse the terrible syntax),
 
  Hi Ben,
 
  Isn't this subsumed by ordinary Haskell modules, barring the current
  compilers' limitation that modules are in 1-to-1 correspondence with
  files (and thus are somewhat heavy-weight)?
 
  E.g. the above could be structured as
 
module MyDataLenses where
  data MyData = MyData { ... }
  makeLenses ''MyData
 
module HelloWorld (module MyDataLenses, ...) where
  ...
 
 True. Unfortunately I've not seen much motion towards relaxing this
 limitation[1].
 
 Cheers,
 
 - Ben
 
 
 [1] http://ghc.haskell.org/trac/ghc/ticket/2551

I guess there simply were not many use cases for that. This may be one.

At least if we are talking about changing the compiler anyway, it's
better to stick with a well-understood and standardized mechanism.

Roman


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

[Haskell-cafe] Opportunity with Machine Learning Startup in Northern California

[Charles Weitzer]

Hello,

My name is Charles Weitzer.  I have two friends who have started a
quantitative hedge fund.  One has his PhD in CS from Stanford, while the
other has his PhD in Statistics from Berkeley.  Company has around 12 people
currently. They have made some unpublished discoveries in the field of
Machine Learning and in other areas as well.  

They are looking for an extremely talented software engineer. This position
could be a simple software engineer, but it could also be where you are The
Man, basically the head of systems development.  These guys are going to be
the next big thing in terms of quantitative strategies and systems.  They
are rebuilding their current system and also designing a new system.  You
could work on either or both.  The title and level of seniority is very
flexible.  As well, given their returns, this is a chance to become
extremely wealthy. 

They are currently managing a very healthy amount of capital.  FYI, I am
retained by them.  They are located in Northern California. Their blurb
below is really is just a starting point in terms of possible initial
responsibility and seniority.  They are flexible for the right person.

Talk soon,

Charles Weitzer

CEO\Senior Recruiter
Charles Weitzer and Associates, Inc.
Global Financial Recruiting Services
char...@charlesweitzer.com
Voice: USA (510) 558-9182

Fast-growing systematic-trading firm seeks an exceptional software
developer. You will architect and implement a diverse set of core
infrastructures, including new production systems, scientific-computing
environments, and modern data stores.

We seek candidates with a proven track record of writing correct,
well-designed software, solving hard problems and delivering complex
projects on time. You should preferably have experience with high assurance,
distributed, fault-tolerant systems. Experience with functional programming
as well as soft real-time, low-latency, cache-friendly systems is a bonus.

We are getting big fast. Willingness to take initiative, and a gritty
determination to productize, are essential.

Join a team that includes faculty at premier universities and PhD's from
top-tier schools, led by the founder and CEO of a successful Internet
infrastructure startup. You will have a high impact, and you can expect
frequent interaction with the researchers, officers, and founders.

Compensation and benefits are highly competitive.



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

[Haskell-cafe] Telling Cassava to ignore lines

[Andrew Cowie]

I'm happily using Cassava to parse CSV, only to discover that
non-conforming lines in the input data are causing the parser to error
out.

let e = decodeByName y' :: Either String (Header, Vector Person)

chugs along fine until line 461 of the input when 

parse error (endOfInput) at ...

Ironically when my Person (ha) data type was all fields of :: Text it
just worked, but now that I've specified one or two of the fields as Int
or Float or whatever, it's mis-parsing.

Is there a way to tell it to just ignore lines that don't parse, rather
than it killing the whole run? Cassava understands skipping the *header*
line (and indeed using it to do the -by-name field mapping).

Otherwise the only thing I can see is going back to all the fields
being :: Text, and then running over that as an intermediate structure
and validating whether or not things parse to i.e. float.

AfC
Sydney


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

Re: [Haskell-cafe] Telling Cassava to ignore lines

[Johan Tibell]

Hi,

It depends on what you mean by doesn't parse. From your message is assume
the CSV is valid, but some of the actual values fails to convert (using
FromField). There are a couple of things you could try:

 1. Define a newtype for your field that calls runParser using e.g. the Int
parser and if it fails, return some other value. I should probably add an
Either instance that covers this case, but there's none there now.

newtype MaybeInt = JustI !Int | ParseFailed

instance FromField MaybeInt where
parseField s = case runParser (parseField s) of
Left err - pure ParseFailed
Right (n :: Int) - JustI $ n

(This is from memory, so I might have gotten some of the details wrong.)

 2. Use the Streaming module, which lets you skip whole records that fails
to parse (see the docs for the Cons constructor).

-- Johan



On Tue, Sep 17, 2013 at 6:43 PM, Andrew Cowie 
and...@operationaldynamics.com wrote:

 I'm happily using Cassava to parse CSV, only to discover that
 non-conforming lines in the input data are causing the parser to error
 out.

 let e = decodeByName y' :: Either String (Header, Vector Person)

 chugs along fine until line 461 of the input when

 parse error (endOfInput) at ...

 Ironically when my Person (ha) data type was all fields of :: Text it
 just worked, but now that I've specified one or two of the fields as Int
 or Float or whatever, it's mis-parsing.

 Is there a way to tell it to just ignore lines that don't parse, rather
 than it killing the whole run? Cassava understands skipping the *header*
 line (and indeed using it to do the -by-name field mapping).

 Otherwise the only thing I can see is going back to all the fields
 being :: Text, and then running over that as an intermediate structure
 and validating whether or not things parse to i.e. float.

 AfC
 Sydney


 ___
 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] Telling Cassava to ignore lines

[Andrew Cowie]

On Tue, 2013-09-17 at 19:03 -0700, Johan Tibell wrote:

  2. Use the Streaming module, which lets you skip whole records that
 fails to parse (see the docs for the Cons constructor).

Ah, that's sure to be it. Totally missed Data.Csv.Streaming. Thanks!

AfC
Sydney



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

Re: [Haskell-cafe] reifying typeclasses

[Emil Axelsson]

2013-09-15 11:16, o...@okmij.org skrev:

Evan Laforge wrote:

I have a typeclass which is instantiated across a closed set of 3
types.  It has an ad-hoc set of methods, and I'm not too happy with
them because being a typeclass forces them to all be defined in one
place, breaking modularity.  A sum type, of course, wouldn't have that
problem.  But in other places I want the type-safety that separate
types provide, and packing everything into a sum type would destroy
that.  So, expression problem-like, I guess.

It seems to me like I should be able to replace a typeclass with
arbitrary methods with just two, to reify the type and back.  This
seems to work when the typeclass dispatches on an argument, but not on
a return value.  E.g.:


If the universe (the set of types of interest to instantiate the type
class to) is closed, GADTs spring to mind immediately. See, for
example, the enclosed code. It is totally unproblematic (one should
remember to always write type signatures when programming with
GADTs. Weird error messages otherwise ensue.)

One of the most notable differences between GADT and type-class--based
programming is that GADTs are closed and type classes are open (that
is, new instances can be added at will). In fact, a less popular
technique of implementing type classes (which has been used in some Haskell
systems -- but not GHC)) is intensional type analysis, or typecase.
It is quite similar to the GADT solution.


I've been toying with using Data Types à la Carte to get type 
representations, a `Typeable` class and dynamic types parameterized by a 
possibly open universe:


  https://github.com/emilaxelsson/dsl-factory/blob/master/TypeReify.hs

Using this module (which depends on the syntactic package), Evan's 
problem can be solved easily without setting up any new classes or data 
types, as shown below.


/ Emil



import Language.Syntactic
import TypeReify

type Universe = IntType :+: CharType

argument :: forall a . Typeable Universe a = a - Int
argument a
| Just IntType  - prj t = a
| Just CharType - prj t = fromEnum a
-- Note: All cases are covered, since `Universe` is closed
  where
TypeRep t = typeRep :: TypeRep Universe a

result :: forall a . Typeable Universe a = Int - a
result a
| Just IntType  - prj t = a
| Just CharType - prj t = toEnum a
-- Note: All cases are covered, since `Universe` is closed
  where
TypeRep t = typeRep :: TypeRep Universe a

-- Note that we do not have to use a closed universe. Here's an alternative,
-- open version of `argument`:
argument' :: forall u a . (IntType :: u, CharType :: u) =
 Typeable u a = a - Int
argument' a
| Just IntType  - prj t = a
| Just CharType - prj t = fromEnum a
| otherwise  = 0  -- or whatever :)
  where
TypeRep t = typeRep :: TypeRep u a

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

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[John Lato]

On Fri, Sep 13, 2013 at 12:48 AM, Michael Snoyman mich...@snoyman.comwrote:




 On Thu, Sep 12, 2013 at 2:37 AM, John Lato jwl...@gmail.com wrote:

 I didn't see this message and replied privately to Michael earlier, so
 I'm replicating my comments here.


 Sorry about that, I wrote to you privately first and then thought this
 might be a good discussion for the cafe.


 1.  Sooner or later I expect you'll want something like this:

 class LooseMap c el el' where

   lMap :: (el - el') - c el - c el'



  It covers the case of things like hashmaps/unboxed vectors that have
 class constraints on elements.  Although maybe LooseFunctor or LFunctor is
 a better name.

 Probably something similar for Traversable would be good also, as would a
 default instance in terms of Functor.


 That's interesting. It's quite similar to the CanMap[1] class in
 classy-prelude or Each from lens, except it can drop a type parameter and
 the fundeps by requiring the container to be polymorphic. If we're willing
 to use more exotic extensions, ConstraintKinds could be useful as well:

 class ConstrainedMap t where
 type MapConstraint t e :: Constraint
 cMap :: (MapConstraint t e1, MapConstraint t e2) = (e1 - e2) - t e1
 - t e2
 instance ConstrainedMap Set.Set where
 type MapConstraint Set.Set e = Ord e
 cMap = Set.map

 One reason I'd definitely not want to call this anything with the name
 Functor in it is because Set.map can violate the Functor laws, in
 particular:

 Set.map (f . g) /= Set.map f . Set.map g

 I believe the only law that could be applied to Set.map would be:

 Set.map f = Set.fromList . List.map f . Set.toList

 I would presume this would generalize to any other possible instance.


Would it make more sense to just say that all instances must obey the
Functor laws, thereby not allowing the Set instance?  That might make it
easier to reason about using the class.  Although I've never needed that
when I've used it in the past, so I guess whichever you think is more
useful is fine by me.



 One final idea would be to take your LooseMap and apply the same kind of
 monomorphic conversion the rest of the library uses:

 class MonoLooseMap c1 c2 | c1 - c2, c2 - c1 where
 mlMap :: (Element c1 - Element c2) - c1 - c2
 instance (Ord e1, Ord e2) = MonoLooseMap (Set.Set e1) (Set.Set e2) where
 mlMap = Set.map

 Of all of them, ConstrainedMap seems like it would be the most
 user-friendly, as error messages would just have a single type parameter.
 But I don't have any strong leanings.


I agree that ConstrainedMap would likely be the most user-friendly.  It
also seems to best express the actual relationship between the various
components, so it would be my preferred choice.


 [1]
 http://haddocks.fpcomplete.com/fp/7.4.2/20130829-168/classy-prelude/ClassyPrelude-Classes.html#t:CanMap


 2.  IMHO cMapM_ (and related) should be part of the Foldable class.  This
 is entirely for performance reasons, but there's no downside since you can
 just provide a default instance.


 Makes sense to me, done. By the way, this can't be done for sum/product,
 because those require a constraint on the Element.


 3.  I'm not entirely sure that the length* functions belong here.  I
 understand why, and I think it's sensible reasoning, and I don't have a
 good argument against it, but I just don't like it.  With those, and
 mapM_-like functions, it seems that the foldable class is halfway to being
 another monolithic ListLike.  But I don't have any better ideas either.


 I agree here, but like you said in (2), it's a performance concern. The
 distinction I'd make from ListLike is that you only have to define
 foldr/foldl to get a valid instance (and even that could be dropped to just
 foldr, except for conflicts with the default signatures extension).




 As to the bikeshed color, I would prefer to just call the classes
 Foldable/Traversable.  People can use qualified imports to disambiguate
 when writing instances, and at call sites client code would never need
 Data.{Foldable|Traversable} and can just use these versions instead.  I'd
 still want a separate name for Functor though, since it's in the Prelude,
 so maybe it's better to be consistent.  My $.02.


 I prefer avoiding the name conflict, for a few reasons:

- In something like ClassyPrelude, we can export both typeclasses
without a proper if they have separate names.
- Error messages and documentation will be clearer. Consider how the
type signature `ByteString - foo` doesn't let you know whether it's a
strict or lazy bytestring.
- I got specific feedback from Edward that it would be easier to
include instances for these classes if the names didn't clash with standard
terminology.
- It leaves the door open for including this concept upstream in the
future, even if that's not the goal for now.

 Sounds reasonable.




 On Wed, Sep 11, 2013 at 3:25 PM, Michael Snoyman mich...@snoyman.comwrote:

 That's 

[Haskell-cafe] plugins fails on a simple example

[Petr Pudlák]

Hi,

I'm playing with plugins, trying to evaluate a simple expression:

|import  Control.Monad
import  System.Eval.Haskell

main  =do
let  fExpr =1 + 2 :: Int
r - eval_ fExpr [Prelude] [] [] []
::IO  (Either  [String] (Maybe  Int))
case  rof
Right  (Just  f)  -do
print $ f
Left  err - putStrLn $Error:  ++ unlines err
_ - putStrLn $Unknown error.|

However, it fails with

|Error:
on the commandline: Warning:
-fglasgow-exts is deprecated: Use individual extensions instead|

Am I doing something wrong? How can I turn off the flag?

I'm using GHC 7.6.3.

Thanks,
Petr

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

Re: [Haskell-cafe] [Haskell] ANN: Cabal v1.18.0 released

[Henning Thielemann]

On Wed, 4 Sep 2013, Johan Tibell wrote:


* GHCi support. It's now much easier to use ghci when developing your
packages, especially if those packages require preprocessors (e.g.
hsc2hs).


That's a great feature! How can I configure Cabal to start ghci with 
certain options? I like to enable more warnings. I could not find a 
documentation for the Cabal config file.

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

Re: [Haskell-cafe] [Haskell] ANN: Cabal v1.18.0 released

[Erik Hesselink]

On Mon, Sep 16, 2013 at 10:16 AM, Henning Thielemann
lemm...@henning-thielemann.de wrote:

 On Wed, 4 Sep 2013, Johan Tibell wrote:

 * GHCi support. It's now much easier to use ghci when developing your
 packages, especially if those packages require preprocessors (e.g.
 hsc2hs).

 That's a great feature! How can I configure Cabal to start ghci with certain
 options? I like to enable more warnings. I could not find a documentation
 for the Cabal config file.

I assume a .ghci file, either in the project directory, or in your
home directory, still works. See also
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-dot-files.html

Regards,

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

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Michael Snoyman]

On Mon, Sep 16, 2013 at 10:34 AM, John Lato jwl...@gmail.com wrote:

 On Fri, Sep 13, 2013 at 12:48 AM, Michael Snoyman mich...@snoyman.comwrote:




 On Thu, Sep 12, 2013 at 2:37 AM, John Lato jwl...@gmail.com wrote:

 I didn't see this message and replied privately to Michael earlier, so
 I'm replicating my comments here.


 Sorry about that, I wrote to you privately first and then thought this
 might be a good discussion for the cafe.


 1.  Sooner or later I expect you'll want something like this:

 class LooseMap c el el' where

   lMap :: (el - el') - c el - c el'





  It covers the case of things like hashmaps/unboxed vectors that have
 class constraints on elements.  Although maybe LooseFunctor or LFunctor is
 a better name.

 Probably something similar for Traversable would be good also, as would
 a default instance in terms of Functor.


 That's interesting. It's quite similar to the CanMap[1] class in
 classy-prelude or Each from lens, except it can drop a type parameter and
 the fundeps by requiring the container to be polymorphic. If we're willing
 to use more exotic extensions, ConstraintKinds could be useful as well:

 class ConstrainedMap t where
 type MapConstraint t e :: Constraint
 cMap :: (MapConstraint t e1, MapConstraint t e2) = (e1 - e2) - t
 e1 - t e2
 instance ConstrainedMap Set.Set where
 type MapConstraint Set.Set e = Ord e
 cMap = Set.map

 One reason I'd definitely not want to call this anything with the name
 Functor in it is because Set.map can violate the Functor laws, in
 particular:

 Set.map (f . g) /= Set.map f . Set.map g

 I believe the only law that could be applied to Set.map would be:

 Set.map f = Set.fromList . List.map f . Set.toList

 I would presume this would generalize to any other possible instance.


 Would it make more sense to just say that all instances must obey the
 Functor laws, thereby not allowing the Set instance?  That might make it
 easier to reason about using the class.  Although I've never needed that
 when I've used it in the past, so I guess whichever you think is more
 useful is fine by me.



I think I just made a bad assumption about what you were proposing. If I
was going to introduce a typeclass like this, I'd want it to support `Set`,
since IME it's the most commonly used polymorphic `map` operation that has
constraints. (Note that HashMap and Map are in fact Functors, since mapping
only affects their values, which are unconstrained.) I don't really have
any strong feelings on this topic, just that it would be nice to have
*some* kind
of a map-like function that worked on Set and HashSet.



 One final idea would be to take your LooseMap and apply the same kind of
 monomorphic conversion the rest of the library uses:

 class MonoLooseMap c1 c2 | c1 - c2, c2 - c1 where
 mlMap :: (Element c1 - Element c2) - c1 - c2
 instance (Ord e1, Ord e2) = MonoLooseMap (Set.Set e1) (Set.Set e2) where
 mlMap = Set.map

 Of all of them, ConstrainedMap seems like it would be the most
 user-friendly, as error messages would just have a single type parameter.
 But I don't have any strong leanings.


 I agree that ConstrainedMap would likely be the most user-friendly.  It
 also seems to best express the actual relationship between the various
 components, so it would be my preferred choice.


 [1]
 http://haddocks.fpcomplete.com/fp/7.4.2/20130829-168/classy-prelude/ClassyPrelude-Classes.html#t:CanMap


 2.  IMHO cMapM_ (and related) should be part of the Foldable class.
 This is entirely for performance reasons, but there's no downside since you
 can just provide a default instance.


 Makes sense to me, done. By the way, this can't be done for sum/product,
 because those require a constraint on the Element.


 3.  I'm not entirely sure that the length* functions belong here.  I
 understand why, and I think it's sensible reasoning, and I don't have a
 good argument against it, but I just don't like it.  With those, and
 mapM_-like functions, it seems that the foldable class is halfway to being
 another monolithic ListLike.  But I don't have any better ideas either.


 I agree here, but like you said in (2), it's a performance concern. The
 distinction I'd make from ListLike is that you only have to define
 foldr/foldl to get a valid instance (and even that could be dropped to just
 foldr, except for conflicts with the default signatures extension).




 As to the bikeshed color, I would prefer to just call the classes
 Foldable/Traversable.  People can use qualified imports to disambiguate
 when writing instances, and at call sites client code would never need
 Data.{Foldable|Traversable} and can just use these versions instead.  I'd
 still want a separate name for Functor though, since it's in the Prelude,
 so maybe it's better to be consistent.  My $.02.


 I prefer avoiding the name conflict, for a few reasons:

- In something like ClassyPrelude, we can export both typeclasses
without a proper if they have 

Re: [Haskell-cafe] OS X ghci problem

[Christiaan Baaij]

Hi,

I saw the same issue/crash on my machine using ghc 7.6.3.

I just build a perf build of GHC-head with
85a9e2468dc74b9e5ccde0dd61be86219fd323a2 as the latest commit.

Now running, I get:
1)  cabal install bindings-glfw
2)  ghci
3) ghci :m Bindings.GLFW
4) ghci Bindings.GLFW.c'glfwInit
5) ghci 1

And doing:
1.)  cabal install GLFW-b
2.)  ghci -package GLFW-b
3.) ghci import Graphics.UI.GLFW as GLFW
4.) ghci GLFW.init
5.) ghci True

My platform:
- OSX 10.8.4
- ghc(i) 7.7.20130915
- cabal 1.18.0.1 (using 1.18.0 of the Cabal library)
- xcode cltools 4.6.2

So it seems that the new ghci linking infrastructure fixes things

Cheers,

Christiaan

On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos maxda...@gmail.com wrote:

 What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish 
 linker.
 The only wrinkle is figuring out where you want the dylib.
 I think homebrew will put one in /usr/local/lib, which works out nicely, but 
 they don't have GLFW 3 yet.
 Another option is to build the dylib yourself from the GLFW source bundled 
 with the GLFW-b package, then tell cabal where to find it.
 
 Hi,
 for me the problem relocates now to the bindings-glfw package, since
 the native bindings moved to this package and are wrapped up with
 glfw-b.
 
 My way to the same exception already mentioned by Brian Lewis:
 1)  cabal install bindings-glfw
 2)  ghci
 3) ghci :m Bindings.GLFW
 4) ghci Bindings.GLFW.c'glfwInit
 5) ghci terminates with exception: *** Terminating app due to uncaught
 exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool
 init]: unrecognized selector sent to instance 0x7fc443c01b30'
 
 Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no
 clue how to do this. I built the according glfw version on my own as a
 dylib and loaded ghci with it explicitly, this didn't help. I guess
 the compiled bindings-glfw is already statically packed up.
 
 How can I get ghci to use the native glfw dylib in combination with
 bindings-glfw? If I have to compile bindings-glfw with different
 settings, which settings? I have some oversight over haskell but no
 really deep knowledge according to bindings and lib-loading of ghci,
 but I'm willing to learn it ;)
 
 My Platform:
 - OSX 10.8.5
 - ghc(i) 7.6.3
 - cabal 1.18.0.1
 - xcode dev tools 4.6.3
 
 Thanks and Greetings
 
 Jan
 ___
 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] OS X ghci problem

[Christiaan Baaij]

Here's a binary dist of my build: 
https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2
In case someone wants to confirm my findings.

Cheers,

Christiaan

On Sep 16, 2013, at 2:24 PM, Christiaan Baaij christiaan.ba...@gmail.com 
wrote:

 Hi,
 
 I saw the same issue/crash on my machine using ghc 7.6.3.
 
 I just build a perf build of GHC-head with
 85a9e2468dc74b9e5ccde0dd61be86219fd323a2 as the latest commit.
 
 Now running, I get:
 1)  cabal install bindings-glfw
 2)  ghci
 3) ghci :m Bindings.GLFW
 4) ghci Bindings.GLFW.c'glfwInit
 5) ghci 1
 
 And doing:
 1.)  cabal install GLFW-b
 2.)  ghci -package GLFW-b
 3.) ghci import Graphics.UI.GLFW as GLFW
 4.) ghci GLFW.init
 5.) ghci True
 
 My platform:
 - OSX 10.8.4
 - ghc(i) 7.7.20130915
 - cabal 1.18.0.1 (using 1.18.0 of the Cabal library)
 - xcode cltools 4.6.2
 
 So it seems that the new ghci linking infrastructure fixes things
 
 Cheers,
 
 Christiaan
 
 On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos maxda...@gmail.com wrote:
 
 What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish 
 linker.
 The only wrinkle is figuring out where you want the dylib.
 I think homebrew will put one in /usr/local/lib, which works out nicely, 
 but they don't have GLFW 3 yet.
 Another option is to build the dylib yourself from the GLFW source bundled 
 with the GLFW-b package, then tell cabal where to find it.
 
 Hi,
 for me the problem relocates now to the bindings-glfw package, since
 the native bindings moved to this package and are wrapped up with
 glfw-b.
 
 My way to the same exception already mentioned by Brian Lewis:
 1)  cabal install bindings-glfw
 2)  ghci
 3) ghci :m Bindings.GLFW
 4) ghci Bindings.GLFW.c'glfwInit
 5) ghci terminates with exception: *** Terminating app due to uncaught
 exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool
 init]: unrecognized selector sent to instance 0x7fc443c01b30'
 
 Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no
 clue how to do this. I built the according glfw version on my own as a
 dylib and loaded ghci with it explicitly, this didn't help. I guess
 the compiled bindings-glfw is already statically packed up.
 
 How can I get ghci to use the native glfw dylib in combination with
 bindings-glfw? If I have to compile bindings-glfw with different
 settings, which settings? I have some oversight over haskell but no
 really deep knowledge according to bindings and lib-loading of ghci,
 but I'm willing to learn it ;)
 
 My Platform:
 - OSX 10.8.5
 - ghc(i) 7.6.3
 - cabal 1.18.0.1
 - xcode dev tools 4.6.3
 
 Thanks and Greetings
 
 Jan
 ___
 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] An APL library for Haskell

[MIMUW]

Dear Haskellers  APLers,

On 03/08/2012 02:44 PM, Simon Peyton-Jones wrote:
 Friends
 
 Many of you will know the array language 
 APLhttp://en.wikipedia.org/wiki/APL_%28programming_language%29.   It 
 focuses on arrays and in particular has a rich, carefully-thought-out array 
 algebra.
 
 An obvious idea is: what would a Haskell library that embodies APL's array 
 algebra look like?  In conversation with John Scholes and some of his 
 colleagues in the APL community a group of us developed some ideas for a 
 possible API, which you can find on the Haskell wiki here: 
 http://www.haskell.org/haskellwiki/APL
 
 However, we have all gone our separate ways, and I think it's entirely 
 possible that that the idea will go no further.  So this message is to ask:
 
 * Is anyone interested in an APL-style array library in Haskell?
 
 * If so, would you like to lead the process of developing the API?
 
 I think there are quite a few people who would be willing to contribute, 
 including some core gurus from the APL community: John Scholes,  Arthur 
 Whitney, and Roger Hui.
+1

If it may also be an opportunity to think of a standard, efficient
type-class API for multidimensional arrays numeric programmers would
find a new heaven in Haskell too.

With type-level nats one could also hope to reach efficiency of FiSh or
SAC compiler (if anyone remembers these functional wonders, that used
type-level array shapes to improve efficiency of array computations
beyond that of naive C-code.)

Only one note would be that it is to be ultimately included in Haskell
Platform, one needs a more permissive licence than that of HMatrix
(since all HP packages are BSD3, I believe?)
--
  Best regards
Michał J. Gajda
yi, hPDB

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

Re: [Haskell-cafe] An APL library for Haskell

[Carter Schonwald]

Hey All,

As Dan Peebles remarks, Repa and similar libs give a great haskelly
vocabulary for this. Indeed, most of the examples in the wiki page are very
much expressible with the REPA data model.

I'd like to take this opportunity note that I'll be releasing a prototype
library for numerical arrays / numerical computation / etc that draws from
Repa and adds some ideas i've developed over the past year, later this
month. (yes and the core stuff will be bsd3)

barring irresolvable design flaws, i'm very much committed to building
tools in this space that hopefully can see widespread adoption (and use) by
the community.

I'm pretty buried with some other matters for the next week or so, but I
hope to get that preview out at the end of the month. stay tuned ;)
-Carter






On Sun, Sep 15, 2013 at 9:57 PM, Daniel Peebles pumpkin...@gmail.comwrote:

 Interesting idea. It seems like building this on top of REPA would save a
 lot of work, since it has a native notion of rank encoded in the type
 system. I'd then see the APL-like combinators as a niche API for REPA,
 rather than as a library of their own. And of course, you'd get
 parallelization for free, more or less. I think some of the combinators on
 that wiki page already have counterparts in the REPA API.




 On Thu, Mar 8, 2012 at 8:44 AM, Simon Peyton-Jones 
 simo...@microsoft.comwrote:

  Friends

 ** **

 Many of you will know the array language 
 APLhttp://en.wikipedia.org/wiki/APL_%28programming_language%29.
 It focuses on arrays and in particular has a rich, carefully-thought-out
 array algebra. 

 ** **

 An obvious idea is: *what would a Haskell library that embodies APL’s
 array algebra look like*?  In conversation with John Scholes and some of
 his colleagues in the APL community a group of us developed some ideas for
 a possible API, which you can find on the Haskell wiki here:
 http://www.haskell.org/haskellwiki/APL

 ** **

 However, we have all gone our separate ways, and I think it’s entirely
 possible that that the idea will go no further.  So this message is to ask:
 

 **· **Is anyone interested in an APL-style array library in
 Haskell?

 **· **If so, would you like to lead the process of developing
 the API?

 ** **

 I think there are quite a few people who would be willing to contribute,
 including some core gurus from the APL community: John Scholes,  Arthur
 Whitney, and Roger Hui.   

 ** **

 Simon

 ___
 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] OS X ghci problem

[Carter Schonwald]

Christian,
Yes, ghc 7.7/7.8 *should* fix all the ghci linker related problems on
platforms that support dynamic linking!

If (or anyone else) finds problems with the ghci linker on 7.7, please
report them post haste!

I'm also glad to hear that someone's finally tested out the new ghci
functionality properly!

-Carter


On Mon, Sep 16, 2013 at 8:52 AM, Christiaan Baaij 
christiaan.ba...@gmail.com wrote:

 Here's a binary dist of my build:
 https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2
 In case someone wants to confirm my findings.

 Cheers,

 Christiaan

 On Sep 16, 2013, at 2:24 PM, Christiaan Baaij christiaan.ba...@gmail.com
 wrote:

  Hi,
 
  I saw the same issue/crash on my machine using ghc 7.6.3.
 
  I just build a perf build of GHC-head with
  85a9e2468dc74b9e5ccde0dd61be86219fd323a2 as the latest commit.
 
  Now running, I get:
  1)  cabal install bindings-glfw
  2)  ghci
  3) ghci :m Bindings.GLFW
  4) ghci Bindings.GLFW.c'glfwInit
  5) ghci 1
 
  And doing:
  1.)  cabal install GLFW-b
  2.)  ghci -package GLFW-b
  3.) ghci import Graphics.UI.GLFW as GLFW
  4.) ghci GLFW.init
  5.) ghci True
 
  My platform:
  - OSX 10.8.4
  - ghc(i) 7.7.20130915
  - cabal 1.18.0.1 (using 1.18.0 of the Cabal library)
  - xcode cltools 4.6.2
 
  So it seems that the new ghci linking infrastructure fixes things
 
  Cheers,
 
  Christiaan
 
  On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos maxda...@gmail.com wrote:
 
  What I do for GLFW is use a dylib, then you don't rely on GHCi's
 static-ish linker.
  The only wrinkle is figuring out where you want the dylib.
  I think homebrew will put one in /usr/local/lib, which works out
 nicely, but they don't have GLFW 3 yet.
  Another option is to build the dylib yourself from the GLFW source
 bundled with the GLFW-b package, then tell cabal where to find it.
 
  Hi,
  for me the problem relocates now to the bindings-glfw package, since
  the native bindings moved to this package and are wrapped up with
  glfw-b.
 
  My way to the same exception already mentioned by Brian Lewis:
  1)  cabal install bindings-glfw
  2)  ghci
  3) ghci :m Bindings.GLFW
  4) ghci Bindings.GLFW.c'glfwInit
  5) ghci terminates with exception: *** Terminating app due to uncaught
  exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool
  init]: unrecognized selector sent to instance 0x7fc443c01b30'
 
  Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no
  clue how to do this. I built the according glfw version on my own as a
  dylib and loaded ghci with it explicitly, this didn't help. I guess
  the compiled bindings-glfw is already statically packed up.
 
  How can I get ghci to use the native glfw dylib in combination with
  bindings-glfw? If I have to compile bindings-glfw with different
  settings, which settings? I have some oversight over haskell but no
  really deep knowledge according to bindings and lib-loading of ghci,
  but I'm willing to learn it ;)
 
  My Platform:
  - OSX 10.8.5
  - ghc(i) 7.6.3
  - cabal 1.18.0.1
  - xcode dev tools 4.6.3
 
  Thanks and Greetings
 
  Jan
  ___
  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] plugins fails on a simple example

[Jeremy Shaw]

plugins probably needs to be patched[1]. I'll happily apply such a patch.

- jeremy
[1] or rewritten from the ground up


On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák petr@gmail.com wrote:

  Hi,

 I'm playing with “plugins”, trying to evaluate a simple expression:

 import Control.Monadimport System.Eval.Haskell
 main = do
 let fExpr = 1 + 2 :: Int
 r - eval_ fExpr [Prelude] [] [] []
 :: IO (Either [String] (Maybe Int))
 case r of
 Right (Just f)  - do
 print $ f
 Left err - putStrLn $ Error:  ++ unlines err
 _ - putStrLn $ Unknown error.

 However, it fails with

 Error:
 on the commandline: Warning:
 -fglasgow-exts is deprecated: Use individual extensions instead

 Am I doing something wrong? How can I turn off the flag?

 I'm using GHC 7.6.3.

 Thanks,
 Petr

 ___
 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] An APL library for Haskell

[Austin Seipp]

The message was held by Mailman, because it thought you had too many
recipients in the message. Gershom noticed this while we were doing
some maintenance, and released it. We also bumped the recipient limit
to 20 people, so this shouldn't be a problem again.

On Mon, Sep 16, 2013 at 4:32 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
 PS: Oddly I sent this message in March 2012. I don’t know why it has taken
 over year for it to be delivered!


 Simon



 From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of
 Simon Peyton-Jones
 Sent: 08 March 2012 13:45
 To: hask...@haskell.org; Haskell Cafe
 Cc: Lennart Augustsson; John Scholes; nic...@chalmers.se; Nate Foster; Andy
 Gill; Mary Sheeran; Fritz Henglein
 Subject: [Haskell-cafe] An APL library for Haskell



 Friends



 Many of you will know the array language APL.   It focuses on arrays and in
 particular has a rich, carefully-thought-out array algebra.



 An obvious idea is: what would a Haskell library that embodies APL’s array
 algebra look like?  In conversation with John Scholes and some of his
 colleagues in the APL community a group of us developed some ideas for a
 possible API, which you can find on the Haskell wiki here:
 http://www.haskell.org/haskellwiki/APL



 However, we have all gone our separate ways, and I think it’s entirely
 possible that that the idea will go no further.  So this message is to ask:

 ·   Is anyone interested in an APL-style array library in Haskell?

 ·   If so, would you like to lead the process of developing the API?



 I think there are quite a few people who would be willing to contribute,
 including some core gurus from the APL community: John Scholes,  Arthur
 Whitney, and Roger Hui.



 Simon


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




-- 
Regards,
Austin - PGP: 4096R/0x91384671
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] An APL library for Haskell

[Simon Peyton-Jones]

PS: Oddly I sent this message in March 2012. I don't know why it has taken over 
year for it to be delivered!

Simon

From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Simon 
Peyton-Jones
Sent: 08 March 2012 13:45
To: hask...@haskell.org; Haskell Cafe
Cc: Lennart Augustsson; John Scholes; nic...@chalmers.se; Nate Foster; Andy 
Gill; Mary Sheeran; Fritz Henglein
Subject: [Haskell-cafe] An APL library for Haskell

Friends

Many of you will know the array language 
APLhttp://en.wikipedia.org/wiki/APL_%28programming_language%29.   It focuses 
on arrays and in particular has a rich, carefully-thought-out array algebra.

An obvious idea is: what would a Haskell library that embodies APL's array 
algebra look like?  In conversation with John Scholes and some of his 
colleagues in the APL community a group of us developed some ideas for a 
possible API, which you can find on the Haskell wiki here: 
http://www.haskell.org/haskellwiki/APL

However, we have all gone our separate ways, and I think it's entirely possible 
that that the idea will go no further.  So this message is to ask:

*   Is anyone interested in an APL-style array library in Haskell?

*   If so, would you like to lead the process of developing the API?

I think there are quite a few people who would be willing to contribute, 
including some core gurus from the APL community: John Scholes,  Arthur 
Whitney, and Roger Hui.

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

[Haskell-cafe] Proposal: Pragma EXPORT

[Wvv]

I suggest to add instead of (or with) export section Pragma EXPORT:

We have 3 values: public, abstract and private.
Data(with newtypes and types,..) could be public, like `Data(...)` or
abstract `Data`.
Other cases abstract = public.

{-# EXPORT smth #-} pragma is valid till next {-# EXPORT smth #-}.

We also can add local pragma: 
{-# EXPORT smth from #-}  ... {-# EXPORT smth untill #-}
Outside of block is rule of previous {-# EXPORT smth #-}.

Finally we also have rule for 1: {-# EXPORT smth one #-}

Example

module C where
{-# EXPORT public #-}
data A1...
data A2...
{-# EXPORT abstract from #-}
newtype A3... 
data A4...
{-# EXPORT abstract until #-}
type A5...
{-# EXPORT private one #-}
data A6...

foo = ... 
{-# EXPORT private one #-}
bar = ... 
baz = ... 
lorem = ...   
{-# EXPORT private #-}
insput ...
dolor = ..
sit = ... 
{-# EXPORT public one #-}
amen = ...
consectetur = ... 
adipisicing = ... 
elit = ...
sed = ... 
eiusmod  = ...
tempor  = ... 
incididunt = ...  
{-# EXPORT public from #-}
ut = ...  
labore = ...  
et = ...  
{-# EXPORT public until #-}
dolore = ...  
magna = ...   
aliqua = ...  



is the same as 

module C (
  A1(..)
, A2(..)
, A3
, A4  
, A5(..)
, foo
, baz
, lorem
, amen
, ut
, labore
, et
) where 

data A1...
data A2...
newtype A3... 
data A4...
type A5...
data A6...

foo = ... 
bar = ... 
baz = ... 
lorem = ...   
insput ...
dolor = ..
sit = ... 
amen = ...
consectetur = ... 
adipisicing = ... 
elit = ...
sed = ... 
eiusmod  = ...
tempor  = ... 
incididunt = ...  
ut = ...  
labore = ...  
et = ...  
dolore = ...  
magna = ...   
aliqua = ...


We also could have complex pragma, like
{-# EXPORT inherit one foo #-}
bar=...

Backward compatibility:
module A where  ... ~  module A where {-# EXPORT public #-} ...
module B (  ) where ... ~ module B (  ) where {-# EXPORT private #-}
...



--
View this message in context: 
http://haskell.1045720.n5.nabble.com/Proposal-Pragma-EXPORT-tp5736547.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: New syntax for Haskell

[Albert Y. C. Lai]

A specification language is desirable. (Test cases are special cases of 
specifications. Test-driven development is a revival of the waterfall 
process.) For specifying interactions (computer-computer or 
computer-human), I recommend live sequence charts of David Harel, or 
generally any one based on temporal logics.


The problems with natural languages or sublanguages for anything from 
specification to implementation are:


0. You have to transit to formal languages at some point (the 
implementation is formal). The later you transit, the later you can use 
a computer to analyze and/or simulate for catching mistakes. You catch 
fewer mistakes, and later.


1. To re-gain the benefit of formality above, some people settle for 
restrictive sublanguages. Thus naturalness is lost anyway. The problems 
below, however, are still preserved.


2. Natural languages and sublanguages lack diagrams. For some 
specifications, formal diagrammatic languages are more suitable (e.g., 
live sequence charts).


3. Natural languages and sublanguages lack scoping and parenthesizing 
such as in mathematical notation and formal languages:


  sqrt (sin (x^2 + y) - 2) * z

  (forall r. (Int - M r) - M r) - M Int

  forall r. ((Int - M r) - M r) - M Int

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

Re: [Haskell-cafe] Proposal: Pragma EXPORT

[Evan Laforge]

On Mon, Sep 16, 2013 at 4:09 PM, Wvv vite...@rambler.ru wrote:
 I suggest to add instead of (or with) export section Pragma EXPORT:

I doubt this has much chance, since haskell already made its choice
here a long time ago (and even if it were still up for discussion,
PRAGMA isn't right for it), but this brings up a design question I've
had.

I too prefer to declare visibility on the declaration rather than in a
separate list.  C doesn't really have a proper module system, but
header files are effectively a separate module signature.  C++ and
Java and go preferred to mark visibility on the declaration.  The ML
family keeps visibility and declarations separate, which is where I
assume haskell got it (that or maybe modula?).  In the case of the
MLs, though, it's a much more developed concept, since they have
module signatures and functors and all that.

In light of haskell's very basic module system, is there any
particular philosophical reason to prefer a separate export list?  Or
are those who prefer it for practical reasons?  The only thing I can
think of is that it provides a nice summary of the module, which
haddock capitalizes on.  But when I want a summary, I look at haddock,
which would already be capable of hiding internal definitions.  I have
heard that haskell's module system was originally intended as a kind
of simple-as-possible placeholder (like records... cough cough), maybe
the designers though an ML-style module system might eventually
materialize?

To me it's always been a hassle to have to jump to the top of the file
and fiddle with the export list, so much so that I tend to leave it
off until a module is pretty stabilized.  It can also be confusing
when the export list is in a different order from the declarations.
Sometimes I want to explicitly mark something private, and simply
doesn't happen to be in the export list is too implicit, so I wind
up putting a _ on it.

None of this is a big deal, but I'm curious about other's opinions on
it.  Are there strengths to the separate export list that I'm missing?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Pragma EXPORT

[Ivan Lazar Miljenovic]

On 17 September 2013 09:35, Evan Laforge qdun...@gmail.com wrote:
 On Mon, Sep 16, 2013 at 4:09 PM, Wvv vite...@rambler.ru wrote:
 I suggest to add instead of (or with) export section Pragma EXPORT:

 I doubt this has much chance, since haskell already made its choice
 here a long time ago (and even if it were still up for discussion,
 PRAGMA isn't right for it), but this brings up a design question I've
 had.

 I too prefer to declare visibility on the declaration rather than in a
 separate list.  C doesn't really have a proper module system, but
 header files are effectively a separate module signature.  C++ and
 Java and go preferred to mark visibility on the declaration.  The ML
 family keeps visibility and declarations separate, which is where I
 assume haskell got it (that or maybe modula?).  In the case of the
 MLs, though, it's a much more developed concept, since they have
 module signatures and functors and all that.

 In light of haskell's very basic module system, is there any
 particular philosophical reason to prefer a separate export list?  Or
 are those who prefer it for practical reasons?  The only thing I can
 think of is that it provides a nice summary of the module, which
 haddock capitalizes on.  But when I want a summary, I look at haddock,
 which would already be capable of hiding internal definitions.  I have
 heard that haskell's module system was originally intended as a kind
 of simple-as-possible placeholder (like records... cough cough), maybe
 the designers though an ML-style module system might eventually
 materialize?

 To me it's always been a hassle to have to jump to the top of the file
 and fiddle with the export list, so much so that I tend to leave it
 off until a module is pretty stabilized.  It can also be confusing
 when the export list is in a different order from the declarations.
 Sometimes I want to explicitly mark something private, and simply
 doesn't happen to be in the export list is too implicit, so I wind
 up putting a _ on it.

 None of this is a big deal, but I'm curious about other's opinions on
 it.  Are there strengths to the separate export list that I'm missing?

I do like the actual summary aspect as you've noted, as I can at
times be looking through the actual code rather than haddock
documentation when exploring new code (or even trying to remember what
I wrote in old code).

It also makes actual definitions cleaner/shorter rather than
cluttering them with extra annotations (either PRAGMAs or
public/private markers), though this is not that big of a deal.

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



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[John Lato]

On Mon, Sep 16, 2013 at 4:57 AM, Michael Snoyman mich...@snoyman.comwrote:




 On Mon, Sep 16, 2013 at 10:34 AM, John Lato jwl...@gmail.com wrote:

 On Fri, Sep 13, 2013 at 12:48 AM, Michael Snoyman mich...@snoyman.comwrote:




 On Thu, Sep 12, 2013 at 2:37 AM, John Lato jwl...@gmail.com wrote:

 I didn't see this message and replied privately to Michael earlier, so
 I'm replicating my comments here.


 Sorry about that, I wrote to you privately first and then thought this
 might be a good discussion for the cafe.


 1.  Sooner or later I expect you'll want something like this:

 class LooseMap c el el' where

   lMap :: (el - el') - c el - c el'






  It covers the case of things like hashmaps/unboxed vectors that have
 class constraints on elements.  Although maybe LooseFunctor or LFunctor is
 a better name.

 Probably something similar for Traversable would be good also, as would
 a default instance in terms of Functor.


 That's interesting. It's quite similar to the CanMap[1] class in
 classy-prelude or Each from lens, except it can drop a type parameter and
 the fundeps by requiring the container to be polymorphic. If we're willing
 to use more exotic extensions, ConstraintKinds could be useful as well:

 class ConstrainedMap t where
 type MapConstraint t e :: Constraint
 cMap :: (MapConstraint t e1, MapConstraint t e2) = (e1 - e2) - t
 e1 - t e2
 instance ConstrainedMap Set.Set where
 type MapConstraint Set.Set e = Ord e
 cMap = Set.map

 One reason I'd definitely not want to call this anything with the name
 Functor in it is because Set.map can violate the Functor laws, in
 particular:

 Set.map (f . g) /= Set.map f . Set.map g

 I believe the only law that could be applied to Set.map would be:

 Set.map f = Set.fromList . List.map f . Set.toList

 I would presume this would generalize to any other possible instance.


 Would it make more sense to just say that all instances must obey the
 Functor laws, thereby not allowing the Set instance?  That might make it
 easier to reason about using the class.  Although I've never needed that
 when I've used it in the past, so I guess whichever you think is more
 useful is fine by me.



 I think I just made a bad assumption about what you were proposing. If I
 was going to introduce a typeclass like this, I'd want it to support `Set`,
 since IME it's the most commonly used polymorphic `map` operation that has
 constraints. (Note that HashMap and Map are in fact Functors, since mapping
 only affects their values, which are unconstrained.) I don't really have
 any strong feelings on this topic, just that it would be nice to have *
 some* kind of a map-like function that worked on Set and HashSet.


Ok, understood.  I most often use this with Data.Vector.Unboxed and
Data.Vector.Storable, and that it would be useful for Set didn't really
occur to me.

Given that, I agree that a non-Functor name is a workable choice.





 One final idea would be to take your LooseMap and apply the same kind of
 monomorphic conversion the rest of the library uses:

 class MonoLooseMap c1 c2 | c1 - c2, c2 - c1 where
 mlMap :: (Element c1 - Element c2) - c1 - c2
 instance (Ord e1, Ord e2) = MonoLooseMap (Set.Set e1) (Set.Set e2) where
 mlMap = Set.map

 Of all of them, ConstrainedMap seems like it would be the most
 user-friendly, as error messages would just have a single type parameter.
 But I don't have any strong leanings.


 I agree that ConstrainedMap would likely be the most user-friendly.  It
 also seems to best express the actual relationship between the various
 components, so it would be my preferred choice.


 [1]
 http://haddocks.fpcomplete.com/fp/7.4.2/20130829-168/classy-prelude/ClassyPrelude-Classes.html#t:CanMap


 2.  IMHO cMapM_ (and related) should be part of the Foldable class.
 This is entirely for performance reasons, but there's no downside since you
 can just provide a default instance.


 Makes sense to me, done. By the way, this can't be done for sum/product,
 because those require a constraint on the Element.


 3.  I'm not entirely sure that the length* functions belong here.  I
 understand why, and I think it's sensible reasoning, and I don't have a
 good argument against it, but I just don't like it.  With those, and
 mapM_-like functions, it seems that the foldable class is halfway to being
 another monolithic ListLike.  But I don't have any better ideas either.


 I agree here, but like you said in (2), it's a performance concern. The
 distinction I'd make from ListLike is that you only have to define
 foldr/foldl to get a valid instance (and even that could be dropped to just
 foldr, except for conflicts with the default signatures extension).




 As to the bikeshed color, I would prefer to just call the classes
 Foldable/Traversable.  People can use qualified imports to disambiguate
 when writing instances, and at call sites client code would never need
 Data.{Foldable|Traversable} and can just use these 

[Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6

[Carter Schonwald]

Hey everyone,

if you are actively using ghc 7.6 on your mac,
for now please do not install xcode 5.

It will break your ghc install, because 7.6 doesn't  know how to correctly
use Clang for the CPP work. (ghc head / and thus 7.8 will work fine with
xcode 5, thanks to some outstanding work by Austin Seipp, 7.6 does not)

if you do not need xcode 5, and you're actively using ghc 7.6, stay with
xcode 4.6 for now.

if you installed xcode 5 because its there, and now your ghc 7.6 is
occasionally giving you strange errors involving CPP parse failures on
fragments  like #-}, you should go to the apple developers website,
download, and reinstall the xcode 4.6 CLI tools.


if you need both xcode 5 and ghc in working order *right now, tomorrow*,
either

a) live on the wildside: test out using ghc head: also means you could play
with ghc-ios too!

b) if you need both in working order now, and stabilish, Darin Morrison has
a set of mac-homebrew taps that should be you use
 https://github.com/darinmorrison/homebrew-haskell
these taps should be regarded as more official and canonical than the
formula's that brew provides (the normal brew ones recurrently have
problems induced by folks who aren't haskell devs)

c) wait  a wee bit till 7.8 lands in all its glory, and have both the
freshest of xcodes, and the newest of  awesome ghcs

tl;dr

if you don't  need xcode 5, having xcode 4.6 CLI tools installed will stand
you in good stead.

if you are on os x mavericks, or absolutely need xcode 5 installed, and you
want a ghc thats already released, use darin's brew formulae
https://github.com/darinmorrison/homebrew-haskell


Darin and I plan to spend some time next month preparing an unofficial
patched version of ghc 7.6 that should play nice with clang / xcode 5,
though at such a time ghc 7.8 will be in RC status at the very least.


cheers

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

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Michael Snoyman]

On Tue, Sep 17, 2013 at 4:25 AM, John Lato jwl...@gmail.com wrote:

 On Mon, Sep 16, 2013 at 4:57 AM, Michael Snoyman mich...@snoyman.comwrote:


 I think I just made a bad assumption about what you were proposing. If I
 was going to introduce a typeclass like this, I'd want it to support `Set`,
 since IME it's the most commonly used polymorphic `map` operation that has
 constraints. (Note that HashMap and Map are in fact Functors, since mapping
 only affects their values, which are unconstrained.) I don't really have
 any strong feelings on this topic, just that it would be nice to have *
 some* kind of a map-like function that worked on Set and HashSet.


 Ok, understood.  I most often use this with Data.Vector.Unboxed and
 Data.Vector.Storable, and that it would be useful for Set didn't really
 occur to me.

 Given that, I agree that a non-Functor name is a workable choice.



OK, I've added both LooseMap, and storable vector instances:

https://github.com/snoyberg/mono-traversable/commit/3f1c78eb12433a1e65d53b51a7fe1eb69ff80eec

Does that look reasonable?

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

reifying typeclasses (resend)

[Evan Laforge]

[ This is the second time I sent this, the first time it said it was
awaiting moderation because I'm not subscribed to haskell-cafe, which
is weird because I thought I was.  Did a bunch of people get
unsubscribed? ]

I'm sure this is old-hat to typeclass wizards, but I've managed to get
pretty far without understanding them too well, so here's a basic
question.  I haven't seen it phrased this way before though:

I have a typeclass which is instantiated across a closed set of 3
types.  It has an ad-hoc set of methods, and I'm not too happy with
them because being a typeclass forces them to all be defined in one
place, breaking modularity.  A sum type, of course, wouldn't have that
problem.  But in other places I want the type-safety that separate
types provide, and packing everything into a sum type would destroy
that.  So, expression problem-like, I guess.

It seems to me like I should be able to replace a typeclass with
arbitrary methods with just two, to reify the type and back.  This
seems to work when the typeclass dispatches on an argument, but not on
a return value.  E.g.:

{-# LANGUAGE ScopedTypeVariables #-}

class Taggable a where
toTagged :: a - Tagged
toTaggedType :: a - TaggedType
fromTagged :: Tagged - Maybe a

m_argument :: a - Int
m_result :: Int - a

data Tagged = TInt Int | TChar Char deriving (Show)
data TaggedType = TypeInt | TypeChar deriving (Show)

instance Taggable Int where
toTagged = TInt
toTaggedType _ = TypeInt
fromTagged (TInt x) = Just x
fromTagged _ = Nothing

m_argument = id
m_result = id

instance Taggable Char where
toTagged = TChar
toTaggedType _ = TypeChar
fromTagged (TChar x) = Just x
fromTagged _ = Nothing

m_argument = fromEnum
m_result = toEnum

argument :: (Taggable a) = a - Int
argument a = case toTagged a of
TInt x - x
TChar c - fromEnum c

result :: forall a. (Taggable a) = Int - a
result val = case toTaggedType (undefined :: a) of
TypeInt - val
TypeChar - toEnum val


Say m_argument and m_result are the ad-hoc methods I'd like to get out
of the typeclass.  I can do that well enough for 'argument', but
'result' runs into trouble.  One is the ugly undefined trick with
toTaggedType, but the bigger one is that ghc says 'Could not deduce (a
~ Int) from the context (Taggable a)'.  I wasn't really expecting it
to work, because it would entail a case with multiple types.  As far
as I know, the only way for that to happen is with GADTs.  But I don't
see how they could help me here.

So, perhaps my intuition was wrong.  toTagged and fromTagged methods
give you the power to go between value and type level, but apparently
that's not enough power to express what typeclasses give you.  Also it
seems like there's a fundamental difference between dispatching on
argument vs dispatching on result.

Is there a way to more formally understand the extents of what
typeclasses provide, and what a toTagged fromTagged scheme gives me,
so I can have a better intuition for how to go between value and type
levels?

Also, the toTaggedType thing is pretty ugly.  Not just passing it
undefined, but how it has to repeat the types.  I don't really see a
way to get around that though.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Recent problems with -cafe -- Fixed (I hope)

[Gershom Bazerman]

There were problems with the -cafe mailinglist today.

Best I can tell, we had an unplanned system reboot last night. In the 
course of it going down and back up, the configuration for -cafe got 
corrupted and the auto-fixed configuration had roughly 3/4 of the 
membership deleted.


I've gone in and replaced it with a recent backup config, which should 
have fixed the problem.


If this email goes through, then we're in good shape -- sorry about the 
mess.


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

Re: [Haskell-cafe] reifying typeclasses (resend)

[Timon Gehr]

On 09/15/2013 09:38 AM, Evan Laforge wrote:

...

It seems to me like I should be able to replace a typeclass with
arbitrary methods with just two, to reify the type and back.  This
seems to work when the typeclass dispatches on an argument, but not on
a return value.  E.g.:

...

Say m_argument and m_result are the ad-hoc methods  I'd like to get out
of the typeclass.  I can do that well enough for 'argument', but
'result' runs into trouble.  One is the ugly undefined trick with
toTaggedType, but the bigger one is that ghc says 'Could not deduce (a
~ Int) from the context (Taggable a)'.  I wasn't really expecting it
to work, because it would entail a case with multiple types.  As far
as I know, the only way for that to happen is with GADTs.  But I don't
see how they could help me here.



As follows:

{-# LANGUAGE GADTs, StandaloneDeriving #-}

class Taggable a where
toTagged :: a - Tagged a
toTaggedType :: TaggedType a
fromTagged :: Tagged b - Maybe a

data Tagged a where -- (example works if this is not a GADT)
  TInt  :: Int - Tagged Int
  TChar :: Char - Tagged Char

deriving instance Show (Tagged a)

data TaggedType a where
  TypeInt :: TaggedType Int
  TypeChar :: TaggedType Char

deriving instance Show (TaggedType a)

instance Taggable Int where
toTagged = TInt
toTaggedType = TypeInt
fromTagged (TInt x) = Just x
fromTagged _ = Nothing

instance Taggable Char where
toTagged = TChar
toTaggedType = TypeChar
fromTagged (TChar x) = Just x
fromTagged _ = Nothing

argument :: (Taggable a) = a - Int
argument a = case toTagged a of
TInt x - x
TChar c - fromEnum c

result :: (Taggable a) = Int - a
result val = go val $ toTaggedType
  where
go :: (Taggable a) = Int - TaggedType a - a
go val TypeInt = val
go val TypeChar = toEnum val



So, perhaps my intuition was wrong.  toTagged and fromTagged methods
give you the power to go between value and type level,  but apparently
that's not enough power to express what typeclasses give you.


You do get enough power to write that second function, but the result is 
necessarily uglier than if you use GADTs as there are less invariants 
expressed in the type system.


result :: (Taggable a) = Int - a
result val = case fromTagged (TInt val) of
  Just a - a
  Nothing - case fromTagged (TChar $ toEnum val) of
Just a - a
Nothing - case error matches are non-exhaustive of
  TInt _ - undefined
  TChar _ - undefined

(The last pattern match allows the compiler to warn you if 'result' gets 
out of sync with 'Tagged'.)



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

[Haskell-cafe] LATA 2014: 3rd call for papers

[GRLMC]

*To be removed from our mailing list, please respond to this message with
UNSUBSCRIBE in the subject line*


*

8th INTERNATIONAL CONFERENCE ON LANGUAGE AND AUTOMATA THEORY AND
APPLICATIONS

LATA 2014

Madrid, Spain

March 10-14, 2014

Organized by:

Research Group on Implementation of Language-Driven Software and
Applications (ILSA)
Complutense University of Madrid

Research Group on Mathematical Linguistics (GRLMC)
Rovira i Virgili University

http://grammars.grlmc.com/lata2014/

*


AIMS:

LATA is a yearly conference on theoretical computer science and its
applications. Following the tradition of the diverse PhD training events in
the field developed at Rovira i Virgili University in Tarragona since 2002,
LATA 2014 will reserve significant room for young scholars at the beginning
of their career. It will aim at attracting contributions from both classical
theory fields and application areas (bioinformatics, language technology,
artificial intelligence, etc.).

VENUE:

LATA 2014 will take place in Madrid, the capital of Spain. The venue will be
the School of Informatics of Complutense University.

SCOPE:

Topics of either theoretical or applied interest include, but are not
limited to:

algebraic language theory
algorithms for semi-structured data mining
algorithms on automata and words
automata and logic
automata for system analysis and programme verification
automata, concurrency and Petri nets
automatic structures
cellular automata
codes
combinatorics on words
compilers
computability
computational complexity
data and image compression
decidability issues on words and languages
descriptional complexity
DNA and other models of bio-inspired computing
digital libraries and document engineering
foundations of finite state technology
foundations of XML
fuzzy and rough languages
grammars (Chomsky hierarchy, contextual, unification, categorial, etc.)
grammatical inference and algorithmic learning
graphs and graph transformation
language varieties and semigroups
language-based cryptography
language-theoretic foundations of artificial intelligence and artificial
life
natural language and speech automatic processing
parallel and regulated rewriting
parsing
patterns
power series
quantum, chemical and optical computing
semantics
string and combinatorial issues in computational biology and bioinformatics
string processing algorithms
symbolic dynamics
symbolic neural networks
term rewriting
transducers
trees, tree languages and tree automata
weighted automata

STRUCTURE:

LATA 2014 will consist of:

invited talks
invited tutorials
peer-reviewed contributions

INVITED SPEAKERS:

Javier Esparza (Munich Tech, DE), On Trees and Fixed Point Equations
(tutorial)
Leslie A. Goldberg (Oxford, UK), The Complexity of Approximate Counting
Oscar H. Ibarra (Santa Barbara, US), tba
Sanjeev Khanna (Philadelphia, US), tba
Helmut Seidl (Munich Tech, DE), tba

PROGRAMME COMMITTEE:

Dana Angluin (Yale, US)
Eugene Asarin (Paris Diderot, FR)
Jos Baeten (Amsterdam, NL)
Christel Baier (Dresden, DE)
Jan Bergstra (Amsterdam, NL)
Jin-Yi Cai (Madison, US)
Marek Chrobak (Riverside, US)
Andrea Corradini (Pisa, IT)
Mariangiola Dezani (Turin, IT)
Ding-Zhu Du (Dallas, US)
Michael R. Fellows (Darwin, AU)
Jörg Flum (Freiburg, DE)
Nissim Francez (Technion, IL)
Jürgen Giesl (Aachen, DE)
Annegret Habel (Oldenburg, DE)
Kazuo Iwama (Kyoto, JP)
Sampath Kannan (Philadelphia, US)
Ming-Yang Kao (Northwestern, US)
Deepak Kapur (Albuquerque, US)
Joost-Pieter Katoen (Aachen, DE)
S. Rao Kosaraju (Johns Hopkins, US)
Evangelos Kranakis (Carleton, CA)
Gad M. Landau (Haifa, IL)
Andrzej Lingas (Lund, SE)
Jack Lutz (Iowa State, US)
Ian Mackie (École Polytechnique, FR)
Carlos Martín-Vide (Tarragona, ES, chair)
Giancarlo Mauri (Milan, IT)
Faron G. Moller (Swansea, UK)
Paliath Narendran (Albany, US)
Enno Ohlebusch (Ulm, DE)
Helmut Prodinger (Stellenbosch, ZA)
Jean-François Raskin (Brussels, BE)
Wolfgang Reisig (Humboldt Berlin, DE)
Marco Roveri (Bruno Kessler, Trento, IT)
Michaël Rusinowitch (LORIA, Nancy, FR)
Yasubumi Sakakibara (Keio, JP)
Davide Sangiorgi (Bologna, IT)
Colin Stirling (Edinburgh, UK)
Jianwen Su (Santa Barbara, US)
Jean-Pierre Talpin (IRISA, Rennes, FR)
Andrzej Tarlecki (Warsaw, PL)
Rick Thomas (Leicester, UK)
Sophie Tison (Lille, FR)
Rob van Glabbeek (NICTA, Sydney, AU)
Helmut Veith (Vienna Tech, AT)

ORGANIZING COMMITTEE:

Adrian Horia Dediu (Tarragona)
Ana Fernández-Pampillón (Madrid)
Carlos Martín-Vide (Tarragona, co-chair)
Antonio Sarasa (Madrid)
José-Luis Sierra (Madrid, co-chair)
Bianca Truthe (Magdeburg)
Florentina Lilica Voicu (Tarragona)

SUBMISSIONS:

Authors are invited to submit non-anonymized papers in English presenting
original and unpublished research. Papers should not exceed 12 single-spaced
pages (including eventual appendices) and should be formatted according to
the standard format for Springer 

Re: [Haskell-cafe] reifying typeclasses

[oleg]

Evan Laforge wrote:
 I have a typeclass which is instantiated across a closed set of 3
 types.  It has an ad-hoc set of methods, and I'm not too happy with
 them because being a typeclass forces them to all be defined in one
 place, breaking modularity.  A sum type, of course, wouldn't have that
 problem.  But in other places I want the type-safety that separate
 types provide, and packing everything into a sum type would destroy
 that.  So, expression problem-like, I guess.

 It seems to me like I should be able to replace a typeclass with
 arbitrary methods with just two, to reify the type and back.  This
 seems to work when the typeclass dispatches on an argument, but not on
 a return value.  E.g.:


If the universe (the set of types of interest to instantiate the type
class to) is closed, GADTs spring to mind immediately. See, for
example, the enclosed code. It is totally unproblematic (one should
remember to always write type signatures when programming with
GADTs. Weird error messages otherwise ensue.)

One of the most notable differences between GADT and type-class--based
programming is that GADTs are closed and type classes are open (that
is, new instances can be added at will). In fact, a less popular
technique of implementing type classes (which has been used in some Haskell
systems -- but not GHC)) is intensional type analysis, or typecase.
It is quite similar to the GADT solution.


The main drawback of the intensional type analysis as shown in the
enclosed code is that it breaks parametricity. The constraint Eq a
does not let one find out what the type 'a' is and so what other
operations it may support. (Eq a) says that the type a supports (==),
and does not say any more than that. OTH, Representable a tells quite
a lot about type a, essentially, everything.

 types.  It has an ad-hoc set of methods, and I'm not too happy with
 them because being a typeclass forces them to all be defined in one
 place, breaking modularity.  A sum type, of course, wouldn't have that
Why not to introduce several type classes, even a type class for each
method if necessary. Grouping methods under one type class is
appropriate when such a grouping makes sense. Otherwise, Haskell won't
lose in expressiveness if a type class could have only one method.

{-# LANGUAGE GADTs #-}

module G where

data TRep a where
TInt  :: TRep Int
TChar :: TRep Char

class Representable a where
repr :: TRep a

instance Representable Int where
repr = TInt

instance Representable Char where
repr = TChar

argument :: Representable a = a - Int
argument x = go repr x
 where
 -- For GADTs, signatures are important!
 go :: TRep a - a - Int
 go TInt  x = x
 go TChar x = fromEnum x

-- just the `mirror inverse'
result :: Representable a = Int - a
result x = go repr x
 where
 -- For GADTs, signatures are important!
 go :: TRep a - Int - a
 go TInt  x = x
 go TChar x = toEnum x

t1 = argument 'a'
t2 = show (result 98 :: Char)

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

Re: [Haskell-cafe] reifying typeclasses (resend)

[Bas van Dijk]

You can indeed use GADTs to solve this:

{-# LANGUAGE GADTs #-}

data Universe a where
UInt  :: Int  - Universe Int
UChar :: Char - Universe Char

class Universal a where
universe :: a - Universe a

instance Universal Int where
universe = UInt

instance Universal Char where
universe = UChar

argument :: (Universal a) = a - Int
argument x = case universe x of
   UInt  n - n
   UChar c - fromEnum c

result :: (Universal a) = Int - a
result val = x
  where
x = case universe x of
  UInt  _ - val
  UChar _ - toEnum val

On 15 September 2013 09:38, Evan Laforge qdun...@gmail.com wrote:
 [ This is the second time I sent this, the first time it said it was
 awaiting moderation because I'm not subscribed to haskell-cafe, which
 is weird because I thought I was.  Did a bunch of people get
 unsubscribed? ]

 I'm sure this is old-hat to typeclass wizards, but I've managed to get
 pretty far without understanding them too well, so here's a basic
 question.  I haven't seen it phrased this way before though:

 I have a typeclass which is instantiated across a closed set of 3
 types.  It has an ad-hoc set of methods, and I'm not too happy with
 them because being a typeclass forces them to all be defined in one
 place, breaking modularity.  A sum type, of course, wouldn't have that
 problem.  But in other places I want the type-safety that separate
 types provide, and packing everything into a sum type would destroy
 that.  So, expression problem-like, I guess.

 It seems to me like I should be able to replace a typeclass with
 arbitrary methods with just two, to reify the type and back.  This
 seems to work when the typeclass dispatches on an argument, but not on
 a return value.  E.g.:

 {-# LANGUAGE ScopedTypeVariables #-}

 class Taggable a where
 toTagged :: a - Tagged
 toTaggedType :: a - TaggedType
 fromTagged :: Tagged - Maybe a

 m_argument :: a - Int
 m_result :: Int - a

 data Tagged = TInt Int | TChar Char deriving (Show)
 data TaggedType = TypeInt | TypeChar deriving (Show)

 instance Taggable Int where
 toTagged = TInt
 toTaggedType _ = TypeInt
 fromTagged (TInt x) = Just x
 fromTagged _ = Nothing

 m_argument = id
 m_result = id

 instance Taggable Char where
 toTagged = TChar
 toTaggedType _ = TypeChar
 fromTagged (TChar x) = Just x
 fromTagged _ = Nothing

 m_argument = fromEnum
 m_result = toEnum

 argument :: (Taggable a) = a - Int
 argument a = case toTagged a of
 TInt x - x
 TChar c - fromEnum c

 result :: forall a. (Taggable a) = Int - a
 result val = case toTaggedType (undefined :: a) of
 TypeInt - val
 TypeChar - toEnum val


 Say m_argument and m_result are the ad-hoc methods I'd like to get out
 of the typeclass.  I can do that well enough for 'argument', but
 'result' runs into trouble.  One is the ugly undefined trick with
 toTaggedType, but the bigger one is that ghc says 'Could not deduce (a
 ~ Int) from the context (Taggable a)'.  I wasn't really expecting it
 to work, because it would entail a case with multiple types.  As far
 as I know, the only way for that to happen is with GADTs.  But I don't
 see how they could help me here.

 So, perhaps my intuition was wrong.  toTagged and fromTagged methods
 give you the power to go between value and type level, but apparently
 that's not enough power to express what typeclasses give you.  Also it
 seems like there's a fundamental difference between dispatching on
 argument vs dispatching on result.

 Is there a way to more formally understand the extents of what
 typeclasses provide, and what a toTagged fromTagged scheme gives me,
 so I can have a better intuition for how to go between value and type
 levels?

 Also, the toTaggedType thing is pretty ugly.  Not just passing it
 undefined, but how it has to repeat the types.  I don't really see a
 way to get around that though.
 ___
 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] reifying typeclasses

[oleg]

[I too had the problem sending this e-mail to Haskell list.
I got a reply saying the message awaits moderator approval]

Evan Laforge wrote:
 I have a typeclass which is instantiated across a closed set of 3
 types.  It has an ad-hoc set of methods, and I'm not too happy with
 them because being a typeclass forces them to all be defined in one
 place, breaking modularity.  A sum type, of course, wouldn't have that
 problem.  But in other places I want the type-safety that separate
 types provide, and packing everything into a sum type would destroy
 that.  So, expression problem-like, I guess.

 It seems to me like I should be able to replace a typeclass with
 arbitrary methods with just two, to reify the type and back.  This
 seems to work when the typeclass dispatches on an argument, but not on
 a return value.  E.g.:


If the universe (the set of types of interest to instantiate the type
class to) is closed, GADTs spring to mind immediately. See, for
example, the enclosed code. It is totally unproblematic (one should
remember to always write type signatures when programming with
GADTs. Weird error messages otherwise ensue.)

One of the most notable differences between GADT and type-class--based
programming is that GADTs are closed and type classes are open (that
is, new instances can be added at will). In fact, a less popular
technique of implementing type classes (which has been used in some Haskell
systems -- but not GHC)) is intensional type analysis, or typecase.
It is quite similar to the GADT solution.


The main drawback of the intensional type analysis as shown in the
enclosed code is that it breaks parametricity. The constraint Eq a
does not let one find out what the type 'a' is and so what other
operations it may support. (Eq a) says that the type a supports (==),
and does not say any more than that. OTH, Representable a tells quite
a lot about type a, essentially, everything.

 types.  It has an ad-hoc set of methods, and I'm not too happy with
 them because being a typeclass forces them to all be defined in one
 place, breaking modularity.  A sum type, of course, wouldn't have that
Why not to introduce several type classes, even a type class for each
method if necessary. Grouping methods under one type class is
appropriate when such a grouping makes sense. Otherwise, Haskell won't
lose in expressiveness if a type class could have only one method.

{-# LANGUAGE GADTs #-}

module G where

data TRep a where
TInt  :: TRep Int
TChar :: TRep Char

class Representable a where
repr :: TRep a

instance Representable Int where
repr = TInt

instance Representable Char where
repr = TChar

argument :: Representable a = a - Int
argument x = go repr x
 where
 -- For GADTs, signatures are important!
 go :: TRep a - a - Int
 go TInt  x = x
 go TChar x = fromEnum x

-- just the `mirror inverse'
result :: Representable a = Int - a
result x = go repr x
 where
 -- For GADTs, signatures are important!
 go :: TRep a - Int - a
 go TInt  x = x
 go TChar x = toEnum x

t1 = argument 'a'
t2 = show (result 98 :: Char)

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

[Haskell-cafe] An APL library for Haskell

[Simon Peyton-Jones]

Friends

Many of you will know the array language 
APLhttp://en.wikipedia.org/wiki/APL_%28programming_language%29.   It focuses 
on arrays and in particular has a rich, carefully-thought-out array algebra.

An obvious idea is: what would a Haskell library that embodies APL's array 
algebra look like?  In conversation with John Scholes and some of his 
colleagues in the APL community a group of us developed some ideas for a 
possible API, which you can find on the Haskell wiki here: 
http://www.haskell.org/haskellwiki/APL

However, we have all gone our separate ways, and I think it's entirely possible 
that that the idea will go no further.  So this message is to ask:

* Is anyone interested in an APL-style array library in Haskell?

* If so, would you like to lead the process of developing the API?

I think there are quite a few people who would be willing to contribute, 
including some core gurus from the APL community: John Scholes,  Arthur 
Whitney, and Roger Hui.

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

[Haskell-cafe] ANNOUNCE: New OpenGL packages

[Sven Panne]

New versions of the OpenGL packages are available on Hackage:

   * OpenGLRaw 1.4.0.0
   * GLURaw 1.4.0.0
   * OpenGL 2.9.0.0
   * GLUT 2.5.0.0

The mid-term goal is to make all these packages conform to the latest
OpenGL 4.4 specification, and while we're not yet there, this release
is nevertheless an important stepping stone towards that goal. The
packages contain a few non-backwards compatible changes, something
which is never nice for a public API, but it has been necessary:
OpenGL has come a long way from its initial fixed function pipeline to
its current form flexible form centered around shaders and buffers.
Because of this, a few design decisions on the Haskell side were not a
good fit anymore and simply had to change. Nevertheless, almost all
changes needed in the applications and libraries using the OpenGL
packages should be mechanical and straightforward. If not:
hope...@haskell.org is the place to get help if needed.

Hopefully the new packages will make it into the next Haskell Platform
release (2013.4.0.0), at least if I find out how to make it through
the proposal process... ;-)

Cheers,
   S.

P.S.: Here a list of the changes for each package:

==
Changes in the OpenGLRaw package
==

* Added support for the following extensions:

 GL_ARB_occlusion_query2
 GL_ARB_timer_query
 GL_ARB_draw_indirect
 GL_ARB_gpu_shader5
 GL_ARB_tesselllation_shader
 GL_ARB_transform_feedback3
 GL_ARB_ES2_compatibility
 GL_ARB_get_program_binary
 GL_ARB_separate_shader_objects
 GL_ARB_shader_atomic_counters
 GL_ARB_compute_shader
 GL_ARB_ES3_compatibility
 GL_ARB_framebuffer_no_attachments
 GL_ARB_shader_storage_buffer_object
 GL_ARB_query_buffer_object

* Added GLfixed type from OpenGL 4.1.

* Moved GLhandle type to
Graphics.Rendering.OpenGL.Raw.ARB.ShaderObjects where it belongs and
fixed its representation on Mac OS X.

* Added new Graphics.Rendering.OpenGL.Raw.Type module which exports
all GL types. Core31 and Core32 export only their respective subset
now.

* Correctly typed bitfield tokens as, well, GLbitfield instead of GLenum.

* Consistently use ‘Ptr a’ for ‘void*’ which are not opaque.

* Use ccall instead of stdcall on x86_64-windows.

* Use the OpenGLES framework on iOS.

==
Changes in the GLURaw package
==

* Use ccall instead of stdcall on x86_64-windows.

* Use the OpenGLES framework on iOS.

==
Changes in the OpenGL package
==

* Added sync object support.

* Added full support for OpenGL 4.4 query objects, extending and
changing the previous query object API a bit.

* Split ObjectName class into ObjectName + GeneratableObjectName
classes. Added single-name variants deleteObjectName and
genObjectName, they are a very common use case.

* Made BufferObject and TextureObject abstract. Now all GL objects
names are abstract and have to be explicitly generated. The only
exception is DisplayList, which is required to be non-abstract by the
spec.

* Shader is not a class anymore, but a data type with an ObjectName
instance and a creation action. Added ShaderType and shaderType.

* Added partial support for tessellation/geometry/compute shaders.

* Program is not a GeneratableObjectName, but has a createProgram
action now. Added attachShader and detachShader for incremental
changes.

* Deprecated shaderSource and added shaderSourceBS instead. Using
ByteString is more efficient and forces the caller to think about
encodings, e.g. via Data.Text.Encoding.

* Added support for shader/program binaries and shader precision queries.

* Revamped texture targets, adding partial support for texture buffer
objects and texture arrays.

* OpenGL 3.1 deprecated separate polygon draw modes, so use
GL_FRONT_AND_BACK internally in polygonMode whenever possible.

* Added missing Eq/Ord/Show instances for lots of data types.

* Simplified TransformFeedbackVaryings API, making it a bit more
similar to the one for activeAttribs and activeUniforms.

* Exported ContextProfile’.

* Renamed BlitFramebufferMask (to BlitBuffer) and its constructors.

* Renamed BufferRangeAccessBit (to MapBufferUsage) and its constructors

* Removed currentMatrix, genLists, deleteLists and isList, they have
been deprecated for ages.

* Full internal support for UTF-8.

* Do not expose internal #hidden modules.

* Lots of Haddock fixes and improvements.

* Renamed IndexedTransformFeedbackBuffer to IndexedTransformFeedbackBuffer.

* Fixed clip plane query.

==
Changes in the GLUT package

Re: [Haskell-cafe] An APL library for Haskell

[Daniel Peebles]

Interesting idea. It seems like building this on top of REPA would save a
lot of work, since it has a native notion of rank encoded in the type
system. I'd then see the APL-like combinators as a niche API for REPA,
rather than as a library of their own. And of course, you'd get
parallelization for free, more or less. I think some of the combinators on
that wiki page already have counterparts in the REPA API.




On Thu, Mar 8, 2012 at 8:44 AM, Simon Peyton-Jones simo...@microsoft.comwrote:

  Friends

 ** **

 Many of you will know the array language 
 APLhttp://en.wikipedia.org/wiki/APL_%28programming_language%29.
 It focuses on arrays and in particular has a rich, carefully-thought-out
 array algebra. 

 ** **

 An obvious idea is: *what would a Haskell library that embodies APL’s
 array algebra look like*?  In conversation with John Scholes and some of
 his colleagues in the APL community a group of us developed some ideas for
 a possible API, which you can find on the Haskell wiki here:
 http://www.haskell.org/haskellwiki/APL

 ** **

 However, we have all gone our separate ways, and I think it’s entirely
 possible that that the idea will go no further.  So this message is to ask:
 

 **· **Is anyone interested in an APL-style array library in
 Haskell?

 **· **If so, would you like to lead the process of developing the
 API?

 ** **

 I think there are quite a few people who would be willing to contribute,
 including some core gurus from the APL community: John Scholes,  Arthur
 Whitney, and Roger Hui.   

 ** **

 Simon

 ___
 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] OS X ghci problem

[Jan-Philip Loos]

 What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish 
 linker.
 The only wrinkle is figuring out where you want the dylib.
 I think homebrew will put one in /usr/local/lib, which works out nicely, but 
 they don't have GLFW 3 yet.
 Another option is to build the dylib yourself from the GLFW source bundled 
 with the GLFW-b package, then tell cabal where to find it.

Hi,
for me the problem relocates now to the bindings-glfw package, since
the native bindings moved to this package and are wrapped up with
glfw-b.

My way to the same exception already mentioned by Brian Lewis:
1)  cabal install bindings-glfw
2)  ghci
3) ghci :m Bindings.GLFW
4) ghci Bindings.GLFW.c'glfwInit
5) ghci terminates with exception: *** Terminating app due to uncaught
exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool
init]: unrecognized selector sent to instance 0x7fc443c01b30'

Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no
clue how to do this. I built the according glfw version on my own as a
dylib and loaded ghci with it explicitly, this didn't help. I guess
the compiled bindings-glfw is already statically packed up.

How can I get ghci to use the native glfw dylib in combination with
bindings-glfw? If I have to compile bindings-glfw with different
settings, which settings? I have some oversight over haskell but no
really deep knowledge according to bindings and lib-loading of ghci,
but I'm willing to learn it ;)

My Platform:
- OSX 10.8.5
- ghc(i) 7.6.3
- cabal 1.18.0.1
- xcode dev tools 4.6.3

Thanks and Greetings

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

[Haskell-cafe] Quick Angel User's Survey

[Michael Xavier]

Hey Cafe,

I am the maintainer of Angel, the process monitoring daemon. Angel's job is
to start a configured set of processes and restart them when they go away.
I was responding to a ticket and realized that the correct functionality is
not obvious in one case, so I figured I'd ask the stakeholders: people who
use Angel. From what I know, most people who use Angel are Haskellers so
this seemed like the place.

When Angel is terminated, it tries to cleanly shut down any processes it is
monitoring. It also shuts down processes that it spawned when they are
removed from the config and the config is reloaded via the HUP signal. It
uses terminateProcess from System.Process which sends a SIGTERM to the
program on *nix systems.

The trouble is that SIGTERM can be intercepted and a process can still fail
to shut down. Currently Angel issues the SIGTERM and hopes for the best. It
also cleans pidfiles if there were any, which may send a misleading
message. There are a couple of routes I could take:

1. Leave it how it is. Leave it to the user to make sure stubborn processes
go away. I don't like this solution so much as it makes Angel harder to
reason about from a user's perspective.
2. Send a TERM signal then wait for a certain number of seconds, then send
an uninterruptable signal like SIGKILL.

There are some caveats with #2. I think I'd prefer the timeout to be
configurable per-process. I think I'd also prefer that if no timeout is
specified, we assume the user does not want us to use a SIGKILL. SIGKILL
can be very dangerous for some processes like databases. I want explicit
user permission to do something like this. If Angel generated a pidfile for
the process, if it should only be cleaned if Angel can confirm the process
is dead. Otherwise they should be left so the user can handle it.

So the real question: is the extra burden of an optional configuration flag
per process worth this feature? Are my assumptions about path #2 reasonable.

Thanks for your feedback!

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

Re: [Haskell-cafe] Proposal: New syntax for Haskell

[Michael Xavier]

I just want to chime in to defend Cucumber, which I use in Ruby at my day
job. I see a lot of people put up the strawman that it can only be used as
a way for business people to write acceptance tests. That idea is
questionable and I've never worked at a company big enough to require that,
or with business people who have ever wanted to write my tests for me.

In Ruby, I use Cucumber purely for myself to drive high level acceptance
tests for products. I think the sweet spot for it is when you're starting
work on a high level feature and you have NO idea how it will be
implemented or even how it will work in detail. I find that writing in the
limited language that Gherkin provides keeps my brain from going right to
implementation details. I write out tests that explore how the system
should work. I write them in the perspective of the user (which you should
be doing in your head regardless because the user is the one who will
actually interact with your program). I then read them back and make sure
they make logical sense. Only then do I start hooking up the steps I wrote
to code that drives integration/acceptance tests, via a browser for
instance. At the end I have a failing cucumber test that describes the
system in an intuitive manner with zero line noise (programming language
syntax). I am now free to think about implementation details, write lower
level unit tests and implement things that can be described in much less
verbose fashion. I really like that process and if I ever had a job to
develop products in Haskell, I'd probably take a similar approach.

Do note that I advocate using Cucumber to create/drive user stories, not to
unit test low level functions like folds. If you don't have a customer of a
particular function who could describe how they interact with it in
layman's term, then Cucumber is the wrong tool. Use quickcheck/hunit/hspec
for that.


On Thu, Sep 12, 2013 at 3:42 PM, Bob Ippolito b...@redivi.com wrote:

 Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's
 easy to read.


 On Thursday, September 12, 2013, David Thomas wrote:

 I've long been interested in a scripting language designed to be spoken.
 Not interested enough to go about making it happen... but the idea is
 fascinating and possibly useful.


 On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote:

 **

 +1

 Cucumber seems to be great if you mainly want to read your code over the
 telephone, distribute it via national radio broadcast, or dictate it to
 your secretary or your voice recognition software.  You can program thus
 without having to use you fingers.  You can lie on your back on your sofa,
 close your eyes, and utter your programs...

 We could have blind Haskell/Cucumber programming contests...

 Tons of new possiblilities...

 Strongly support this proposal. ;-)

 Andreas

 On 2013-09-10 22:57, Artyom Kazak wrote:

 On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote:

 I hope these jokes do not cause people to be afraid to post new ideas.

 Agreed. I would also like to clarify that my message was much more a joke
 on
 the incomprehensibility of legal acts than on the original proposal.

 By the way, I am pretty impressed with this piece of Cucumber
 description/code:

Scenario: Mislav creates a valid task with an upload
  When I go to the Awesome Ruby Yahh task list page of the Ruby
 Rockstars project
  When I follow + Add Task
  And I fill in Task title with Ohhh upload
  And I follow Attachment
  When I attach the file features/support/sample_files/dragon.jpg to
 upload_file
  And I press Add Task
  And I wait for 1 second
  And I should see Ohhh upload as a task name

 I was much more sceptical when I had only seen the example in Niklas’s
 message.
 ___
 Haskell-Cafe mailing 
 listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe



 --
 Andreas Abel   Du bist der geliebte Mensch.

 Theoretical Computer Science, University of Munich 
 http://www.tcs.informatik.uni-muenchen.de/~abel/


 ___
 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




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

Re: [Haskell-cafe] Proposal: New syntax for Haskell

[David Thomas]

Honestly, I've not.  Worth looking at, probably.


On Thu, Sep 12, 2013 at 3:42 PM, Bob Ippolito b...@redivi.com wrote:

 Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's
 easy to read.


 On Thursday, September 12, 2013, David Thomas wrote:

 I've long been interested in a scripting language designed to be spoken.
 Not interested enough to go about making it happen... but the idea is
 fascinating and possibly useful.


 On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote:

 **

 +1

 Cucumber seems to be great if you mainly want to read your code over the
 telephone, distribute it via national radio broadcast, or dictate it to
 your secretary or your voice recognition software.  You can program thus
 without having to use you fingers.  You can lie on your back on your sofa,
 close your eyes, and utter your programs...

 We could have blind Haskell/Cucumber programming contests...

 Tons of new possiblilities...

 Strongly support this proposal. ;-)

 Andreas

 On 2013-09-10 22:57, Artyom Kazak wrote:

 On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote:

 I hope these jokes do not cause people to be afraid to post new ideas.

 Agreed. I would also like to clarify that my message was much more a joke
 on
 the incomprehensibility of legal acts than on the original proposal.

 By the way, I am pretty impressed with this piece of Cucumber
 description/code:

Scenario: Mislav creates a valid task with an upload
  When I go to the Awesome Ruby Yahh task list page of the Ruby
 Rockstars project
  When I follow + Add Task
  And I fill in Task title with Ohhh upload
  And I follow Attachment
  When I attach the file features/support/sample_files/dragon.jpg to
 upload_file
  And I press Add Task
  And I wait for 1 second
  And I should see Ohhh upload as a task name

 I was much more sceptical when I had only seen the example in Niklas’s
 message.
 ___
 Haskell-Cafe mailing 
 listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe



 --
 Andreas Abel   Du bist der geliebte Mensch.

 Theoretical Computer Science, University of Munich 
 http://www.tcs.informatik.uni-muenchen.de/~abel/


 ___
 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] Proposal: New syntax for Haskell

[Tikhon Jelvis]

My problem with cucumber is not the idea of a high-level DSL for tests. Au
contraire--I think this is a perfect place for a little language. I could
easily see a similar tool being useful for Haskell.

Rather, my issue is with the syntax. Not gherkin in particular but rather
languages that try to look like English in general. For one, these
languages tend to hit the uncanny valley--they're somewhat natural, but not
entirely. Perhaps the code reads like poorly written prose, but you
certainly can't write it in a natural fashion!

More importantly, I do not think prose is a good format for this sort of
thing at all. It's good for reading code, but I almost never read code
directly. Instead, I usually look over large parts of code at a time. I
want code where I can get the structure at a glance and easily separate the
parts that are specific to the current application from ones that aren't.
With prose-like syntax, this is very difficult because everything is made
of words. That programming language syntax you dismiss as line noise? It's
actually the structure of the code, which makes it much *faster* to read!

There's a reason mathematicians user equations and diagrams so much. A
single equation can replace literally pages of text, and you can have a
pretty good idea of what's going on without having to look too closely at
all the details. Think about an integral, for example: from the equation,
you can easily see what sort of equation it is (trigonometric, polynomial,
exponential...), what domain you're integrating over, what the limits are
and, very importantly, that it *is* an integral rather than something
completely different. All just from what the equation looks like, before
you've had to expend much attention on it.

One way to think about it is that the notation factors out the repeated
parts of an integral so that it's easy to visually separate from the
meat--the function you're actually integrating. A good DSL uses symbols
to do the same thing.

The main cost, of course, is that you have to learn the notation. But this
is really a one-time cost; if you're going to be seeing a lot of integrals,
it's more than worth doing, especially because there's so much shared
structure between them. Similarly, it's worth doing for tests, for the same
reasons. There's a lot of shared structure--just look at how many
relatively long phrases got repeated even in the simple examples given
here--and you want to look over that structure without actually reading it.
Much easier with actual syntax than prose. In any real app, you will have
hundreds of tests, and learning to deal with the line noise gets
amortized over all of them, whereas the benefits (shorter code that's
easier to scan) scale at least linearly.

So I think we should really avoid the faux-natural-language syntax as much
as possible.
I just want to chime in to defend Cucumber, which I use in Ruby at my day
job. I see a lot of people put up the strawman that it can only be used as
a way for business people to write acceptance tests. That idea is
questionable and I've never worked at a company big enough to require that,
or with business people who have ever wanted to write my tests for me.

In Ruby, I use Cucumber purely for myself to drive high level acceptance
tests for products. I think the sweet spot for it is when you're starting
work on a high level feature and you have NO idea how it will be
implemented or even how it will work in detail. I find that writing in the
limited language that Gherkin provides keeps my brain from going right to
implementation details. I write out tests that explore how the system
should work. I write them in the perspective of the user (which you should
be doing in your head regardless because the user is the one who will
actually interact with your program). I then read them back and make sure
they make logical sense. Only then do I start hooking up the steps I wrote
to code that drives integration/acceptance tests, via a browser for
instance. At the end I have a failing cucumber test that describes the
system in an intuitive manner with zero line noise (programming language
syntax). I am now free to think about implementation details, write lower
level unit tests and implement things that can be described in much less
verbose fashion. I really like that process and if I ever had a job to
develop products in Haskell, I'd probably take a similar approach.

Do note that I advocate using Cucumber to create/drive user stories, not to
unit test low level functions like folds. If you don't have a customer of a
particular function who could describe how they interact with it in
layman's term, then Cucumber is the wrong tool. Use quickcheck/hunit/hspec
for that.


On Thu, Sep 12, 2013 at 3:42 PM, Bob Ippolito b...@redivi.com wrote:

 Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's
 easy to read.


 On Thursday, September 12, 2013, David Thomas wrote:

 I've long been interested in a scripting language 

Re: [Haskell-cafe] Quick Angel User's Survey

[Alexander V Vershilov]

Hello, Michael.

I'm a potential angel user, and I'd like to add a possibility of optional
angel usage as a
supervisor for openrc services, when I'll have time.

Common practise is:

send SIGTERM for a couple of times, then send SIGQUIT for a couple of
times, then SIGKILL.
You will need to wait for some time between each actions. If your program
is the parent of
a service than it's easy to wait for child death otherwise your need prctl
PR_{SET,GET}_CHILD_SUBREAPER [1]
in order to correctly wait for service. Or sending 0 signal to check if
process still alive, it's
non reliable but portable solution.
As a additional possible solution (may lead to a problems) it's possible to
traverse service
tree and kill processes starting with leafs.

In any can overriding service kill functionality is vastly needed, as most
of supervision systems
have a very limited approach to it.

[1] https://lkml.org/lkml/2013/1/10/521



On 14 September 2013 23:20, Michael Xavier mich...@michaelxavier.netwrote:

 Hey Cafe,

 I am the maintainer of Angel, the process monitoring daemon. Angel's job
 is to start a configured set of processes and restart them when they go
 away. I was responding to a ticket and realized that the correct
 functionality is not obvious in one case, so I figured I'd ask the
 stakeholders: people who use Angel. From what I know, most people who use
 Angel are Haskellers so this seemed like the place.

 When Angel is terminated, it tries to cleanly shut down any processes it
 is monitoring. It also shuts down processes that it spawned when they are
 removed from the config and the config is reloaded via the HUP signal. It
 uses terminateProcess from System.Process which sends a SIGTERM to the
 program on *nix systems.

 The trouble is that SIGTERM can be intercepted and a process can still
 fail to shut down. Currently Angel issues the SIGTERM and hopes for the
 best. It also cleans pidfiles if there were any, which may send a
 misleading message. There are a couple of routes I could take:

 1. Leave it how it is. Leave it to the user to make sure stubborn
 processes go away. I don't like this solution so much as it makes Angel
 harder to reason about from a user's perspective.
 2. Send a TERM signal then wait for a certain number of seconds, then send
 an uninterruptable signal like SIGKILL.

 There are some caveats with #2. I think I'd prefer the timeout to be
 configurable per-process. I think I'd also prefer that if no timeout is
 specified, we assume the user does not want us to use a SIGKILL. SIGKILL
 can be very dangerous for some processes like databases. I want explicit
 user permission to do something like this. If Angel generated a pidfile for
 the process, if it should only be cleaned if Angel can confirm the process
 is dead. Otherwise they should be left so the user can handle it.

 So the real question: is the extra burden of an optional configuration
 flag per process worth this feature? Are my assumptions about path #2
 reasonable.

 Thanks for your feedback!

 --
 Michael Xavier
 http://www.michaelxavier.net

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




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

[Haskell-cafe] Trouble installing haskeline: ExitFailure 139

[David Banas]

Has anyone else hit an unexplained *ExitFailure 139* when trying to install
the *haskeline* package?

Thanks,
-db

dbanas@dbanas-lap:~/prj$ cabal install -v haskeline
Reading available packages...
Choosing modular solver.
Resolving dependencies...
Extracting
/home/dbanas/.cabal/packages/
hackage.haskell.org/haskeline/0.7.0.3/haskeline-0.7.0.3.tar.gz
to /tmp/haskeline-0.7.0.3-16574...
creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup
creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist
creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup
/usr/local/bin/ghc --make
/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs -o
/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup -odir
/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -hidir
/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -i
-i/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3 -package Cabal-1.16.0
[1 of 1] Compiling Main (
/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs,
/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/Main.o )
Linking /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup ...
/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup configure
--verbose=2 --ghc --prefix=/home/dbanas/.cabal --user --flags=terminfo
--flags=-libiconv --flags=-legacy-encoding --constraint=unix ==2.6.0.1
--constraint=transformers ==0.3.0.0 --constraint=terminfo ==0.3.2.5
--constraint=filepath ==1.3.0.1 --constraint=directory ==1.2.0.1
--constraint=containers ==0.5.0.0 --constraint=bytestring ==0.10.0.2
--constraint=base ==4.6.0.1 --disable-tests --disable-benchmarks
World file is already up to date.
cabal: Error: some packages failed to install:
haskeline-0.7.0.3 failed during the configure step. The exception was:
ExitFailure 139
dbanas@dbanas-lap:~/prj$
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Trouble installing haskeline: ExitFailure 139

[Brandon Allbery]

On Sat, Sep 14, 2013 at 4:57 PM, David Banas capn.fre...@gmail.com wrote:

 Has anyone else hit an unexplained *ExitFailure 139* when trying to
 install the *haskeline* package?


139 sounds like how the shell passes on Segmentation fault (core dumped).

-- 
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] Quick Angel User's Survey

[Alexander Kjeldaas]

You can use cgroups on linux to ensure that everything is shut down. See
systemd.

Alexander
On Sep 14, 2013 9:21 PM, Michael Xavier mich...@michaelxavier.net wrote:

 Hey Cafe,

 I am the maintainer of Angel, the process monitoring daemon. Angel's job
 is to start a configured set of processes and restart them when they go
 away. I was responding to a ticket and realized that the correct
 functionality is not obvious in one case, so I figured I'd ask the
 stakeholders: people who use Angel. From what I know, most people who use
 Angel are Haskellers so this seemed like the place.

 When Angel is terminated, it tries to cleanly shut down any processes it
 is monitoring. It also shuts down processes that it spawned when they are
 removed from the config and the config is reloaded via the HUP signal. It
 uses terminateProcess from System.Process which sends a SIGTERM to the
 program on *nix systems.

 The trouble is that SIGTERM can be intercepted and a process can still
 fail to shut down. Currently Angel issues the SIGTERM and hopes for the
 best. It also cleans pidfiles if there were any, which may send a
 misleading message. There are a couple of routes I could take:

 1. Leave it how it is. Leave it to the user to make sure stubborn
 processes go away. I don't like this solution so much as it makes Angel
 harder to reason about from a user's perspective.
 2. Send a TERM signal then wait for a certain number of seconds, then send
 an uninterruptable signal like SIGKILL.

 There are some caveats with #2. I think I'd prefer the timeout to be
 configurable per-process. I think I'd also prefer that if no timeout is
 specified, we assume the user does not want us to use a SIGKILL. SIGKILL
 can be very dangerous for some processes like databases. I want explicit
 user permission to do something like this. If Angel generated a pidfile for
 the process, if it should only be cleaned if Angel can confirm the process
 is dead. Otherwise they should be left so the user can handle it.

 So the real question: is the extra burden of an optional configuration
 flag per process worth this feature? Are my assumptions about path #2
 reasonable.

 Thanks for your feedback!

 --
 Michael Xavier
 http://www.michaelxavier.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

Re: [Haskell-cafe] Trouble installing haskeline: ExitFailure 139

[Judah Jacobson]

Can you try running the setup script manually?

ghc --make Setup.hs
./Setup configure

and see if it prints an error that's any more helpful?

Also, what operating system and version of ghc do you have?

-Judah



On Sat, Sep 14, 2013 at 1:57 PM, David Banas capn.fre...@gmail.com wrote:

 Has anyone else hit an unexplained *ExitFailure 139* when trying to
 install the *haskeline* package?

 Thanks,
 -db

 dbanas@dbanas-lap:~/prj$ cabal install -v haskeline
 Reading available packages...
 Choosing modular solver.
 Resolving dependencies...
 Extracting
 /home/dbanas/.cabal/packages/
 hackage.haskell.org/haskeline/0.7.0.3/haskeline-0.7.0.3.tar.gz
 to /tmp/haskeline-0.7.0.3-16574...
 creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup
 creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist
 creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup
 /usr/local/bin/ghc --make
 /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs -o
 /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup -odir
 /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -hidir
 /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -i
 -i/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3 -package Cabal-1.16.0
 [1 of 1] Compiling Main (
 /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs,
 /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/Main.o )
 Linking /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup ...
 /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup configure
 --verbose=2 --ghc --prefix=/home/dbanas/.cabal --user --flags=terminfo
 --flags=-libiconv --flags=-legacy-encoding --constraint=unix ==2.6.0.1
 --constraint=transformers ==0.3.0.0 --constraint=terminfo ==0.3.2.5
 --constraint=filepath ==1.3.0.1 --constraint=directory ==1.2.0.1
 --constraint=containers ==0.5.0.0 --constraint=bytestring ==0.10.0.2
 --constraint=base ==4.6.0.1 --disable-tests --disable-benchmarks
 World file is already up to date.
 cabal: Error: some packages failed to install:
 haskeline-0.7.0.3 failed during the configure step. The exception was:
 ExitFailure 139
 dbanas@dbanas-lap:~/prj$



 ___
 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] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Mario Blažević]

On 09/13/13 01:51, Michael Snoyman wrote:
On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević blama...@acanac.net 
mailto:blama...@acanac.net wrote:


On 09/11/13 19:37, John Lato wrote:


3.  I'm not entirely sure that the length* functions belong
here.  I
understand why, and I think it's sensible reasoning, and I
don't have a
good argument against it, but I just don't like it.  With
those, and
mapM_-like functions, it seems that the foldable class is
halfway to
being another monolithic ListLike.  But I don't have any
better ideas
either.


If monolithic classes bother you, my monoid-subclasses
package manages to break down the functionality into several
classes. One big difference is that everything is based off Monoid
rather than Foldable, and that has some big effects on the interface.



I'd point out what I'd consider a bigger difference: the type 
signatures have changed in a significant way. With MonoFoldable, 
folding on a ByteString would be:


(Word8 - b - b) - b - ByteString - b

With monoid-subclasses, you get:

(ByteString - b - b) - b - ByteString - b

There's certainly a performance issue to discuss, but I'm more worried 
about semantics. Word8 tells me something very specific: I have one, 
and precisely one, octet. ByteString tells me I have anywhere from 0 
to 2^32 or 2^64  octets. Yes, we know from context that it will always 
be of size one, but the type system can't enforce that invariant.


All true, but we can also use this generalization to our advantage. 
For example, the same monoid-subclasses package provides ByteStringUTF8, 
a newtype wrapper around ByteString. It behaves the same as the plain 
ByteString except its atomic factors are not of size 1, instead it folds 
on UTF-8 encoded character boundaries. You can't represent that in 
Haskell's type system.


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

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Michael Snoyman]

On Fri, Sep 13, 2013 at 9:18 AM, Mario Blažević blama...@acanac.net wrote:

 On 09/13/13 01:51, Michael Snoyman wrote:

 On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević blama...@acanac.netmailto:
 blama...@acanac.net wrote:

 On 09/11/13 19:37, John Lato wrote:


 3.  I'm not entirely sure that the length* functions belong
 here.  I
 understand why, and I think it's sensible reasoning, and I
 don't have a
 good argument against it, but I just don't like it.  With
 those, and
 mapM_-like functions, it seems that the foldable class is
 halfway to
 being another monolithic ListLike.  But I don't have any
 better ideas
 either.


 If monolithic classes bother you, my monoid-subclasses
 package manages to break down the functionality into several
 classes. One big difference is that everything is based off Monoid
 rather than Foldable, and that has some big effects on the interface.



 I'd point out what I'd consider a bigger difference: the type signatures
 have changed in a significant way. With MonoFoldable, folding on a
 ByteString would be:

 (Word8 - b - b) - b - ByteString - b

 With monoid-subclasses, you get:

 (ByteString - b - b) - b - ByteString - b

 There's certainly a performance issue to discuss, but I'm more worried
 about semantics. Word8 tells me something very specific: I have one, and
 precisely one, octet. ByteString tells me I have anywhere from 0 to 2^32 or
 2^64  octets. Yes, we know from context that it will always be of size one,
 but the type system can't enforce that invariant.


 All true, but we can also use this generalization to our advantage.
 For example, the same monoid-subclasses package provides ByteStringUTF8, a
 newtype wrapper around ByteString. It behaves the same as the plain
 ByteString except its atomic factors are not of size 1, instead it folds on
 UTF-8 encoded character boundaries. You can't represent that in Haskell's
 type system.



I can think of two different ways of achieving this approach with
MonoFoldable instead: by setting `Element` to either `Char` or
`ByteStringUTF8`. The two approaches would look like:

newtype ByteStringUTF8A = ByteStringUTF8A S.ByteString
type instance Element ByteStringUTF8A = Char
instance MonoFoldable ByteStringUTF8A where
ofoldr f b (ByteStringUTF8A bs) = ofoldr f b (decodeUtf8 bs)
ofoldl' = undefined

newtype ByteStringUTF8B = ByteStringUTF8B S.ByteString
type instance Element ByteStringUTF8B = ByteStringUTF8B
instance MonoFoldable ByteStringUTF8B where
ofoldr f b (ByteStringUTF8B bs) = ofoldr (f . ByteStringUTF8B .
encodeUtf8 . T.singleton) b (decodeUtf8 bs)
ofoldl' = undefined

I'd personally prefer the first approach, as that gives the right
guarantees at the type level: each time the function is called, it will be
provided with precisely one character. I believe the second approach
provides the same behavior as monoid-subclasses does right now.

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

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Mario Blažević]

On 09/13/13 02:28, Michael Snoyman wrote:




On Fri, Sep 13, 2013 at 9:18 AM, Mario Blažević blama...@acanac.net 
mailto:blama...@acanac.net wrote:


On 09/13/13 01:51, Michael Snoyman wrote:

On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević
blama...@acanac.net mailto:blama...@acanac.net
mailto:blama...@acanac.net mailto:blama...@acanac.net wrote:

On 09/11/13 19:37, John Lato wrote:


3.  I'm not entirely sure that the length* functions
belong
here.  I
understand why, and I think it's sensible reasoning, and I
don't have a
good argument against it, but I just don't like it.  With
those, and
mapM_-like functions, it seems that the foldable class is
halfway to
being another monolithic ListLike.  But I don't have any
better ideas
either.


If monolithic classes bother you, my monoid-subclasses
package manages to break down the functionality into several
classes. One big difference is that everything is based
off Monoid
rather than Foldable, and that has some big effects on the
interface.



I'd point out what I'd consider a bigger difference: the type
signatures have changed in a significant way. With
MonoFoldable, folding on a ByteString would be:

(Word8 - b - b) - b - ByteString - b

With monoid-subclasses, you get:

(ByteString - b - b) - b - ByteString - b

There's certainly a performance issue to discuss, but I'm more
worried about semantics. Word8 tells me something very
specific: I have one, and precisely one, octet. ByteString
tells me I have anywhere from 0 to 2^32 or 2^64  octets. Yes,
we know from context that it will always be of size one, but
the type system can't enforce that invariant.


All true, but we can also use this generalization to our
advantage. For example, the same monoid-subclasses package
provides ByteStringUTF8, a newtype wrapper around ByteString. It
behaves the same as the plain ByteString except its atomic factors
are not of size 1, instead it folds on UTF-8 encoded character
boundaries. You can't represent that in Haskell's type system.



I can think of two different ways of achieving this approach with 
MonoFoldable instead: by setting `Element` to either `Char` or 
`ByteStringUTF8`. The two approaches would look like:


newtype ByteStringUTF8A = ByteStringUTF8A S.ByteString
type instance Element ByteStringUTF8A = Char
instance MonoFoldable ByteStringUTF8A where
ofoldr f b (ByteStringUTF8A bs) = ofoldr f b (decodeUtf8 bs)
ofoldl' = undefined

newtype ByteStringUTF8B = ByteStringUTF8B S.ByteString
type instance Element ByteStringUTF8B = ByteStringUTF8B
instance MonoFoldable ByteStringUTF8B where
ofoldr f b (ByteStringUTF8B bs) = ofoldr (f . ByteStringUTF8B . 
encodeUtf8 . T.singleton) b (decodeUtf8 bs)

ofoldl' = undefined

I'd personally prefer the first approach, as that gives the right 
guarantees at the type level: each time the function is called, it 
will be provided with precisely one character. I believe the second 
approach provides the same behavior as monoid-subclasses does right now.




Right now monoid-subclasses actually provides both approaches. 
You're correct that it provides the second one as instance 
FactorialMonoid ByteStringUTF8, but it also provides the former as 
instance TextualMonoid ByteStringUTF8. The TextualMonoid class is 
basically what you'd get if you restricted MonoFoldable to type 
Elem=Char. I wanted to keep the package extension-free, you see.


My main point is that it's worth considering basing MonoFoldable on 
FactorialMonoid, because it can be considered its specialization. 
Methods like length, take, or reverse, which never mention the item type 
in their signature, can be inherited from the FactorialMonoid superclass 
with no change whatsoever. Other methods would differ in their 
signatures (and performance), but the semantics would carry over.


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

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Michael Snoyman]

On Fri, Sep 13, 2013 at 10:07 AM, Mario Blažević blama...@acanac.netwrote:

 On 09/13/13 02:28, Michael Snoyman wrote:




 On Fri, Sep 13, 2013 at 9:18 AM, Mario Blažević blama...@acanac.netmailto:
 blama...@acanac.net wrote:

 On 09/13/13 01:51, Michael Snoyman wrote:

 On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević
 blama...@acanac.net mailto:blama...@acanac.net
 mailto:blama...@acanac.net mailto:blama...@acanac.net wrote:

 On 09/11/13 19:37, John Lato wrote:


 3.  I'm not entirely sure that the length* functions
 belong
 here.  I
 understand why, and I think it's sensible reasoning, and I
 don't have a
 good argument against it, but I just don't like it.  With
 those, and
 mapM_-like functions, it seems that the foldable class is
 halfway to
 being another monolithic ListLike.  But I don't have any
 better ideas
 either.


 If monolithic classes bother you, my monoid-subclasses
 package manages to break down the functionality into several
 classes. One big difference is that everything is based
 off Monoid
 rather than Foldable, and that has some big effects on the
 interface.



 I'd point out what I'd consider a bigger difference: the type
 signatures have changed in a significant way. With
 MonoFoldable, folding on a ByteString would be:

 (Word8 - b - b) - b - ByteString - b

 With monoid-subclasses, you get:

 (ByteString - b - b) - b - ByteString - b

 There's certainly a performance issue to discuss, but I'm more
 worried about semantics. Word8 tells me something very
 specific: I have one, and precisely one, octet. ByteString
 tells me I have anywhere from 0 to 2^32 or 2^64  octets. Yes,
 we know from context that it will always be of size one, but
 the type system can't enforce that invariant.


 All true, but we can also use this generalization to our
 advantage. For example, the same monoid-subclasses package
 provides ByteStringUTF8, a newtype wrapper around ByteString. It
 behaves the same as the plain ByteString except its atomic factors
 are not of size 1, instead it folds on UTF-8 encoded character
 boundaries. You can't represent that in Haskell's type system.



 I can think of two different ways of achieving this approach with
 MonoFoldable instead: by setting `Element` to either `Char` or
 `ByteStringUTF8`. The two approaches would look like:

 newtype ByteStringUTF8A = ByteStringUTF8A S.ByteString
 type instance Element ByteStringUTF8A = Char
 instance MonoFoldable ByteStringUTF8A where
 ofoldr f b (ByteStringUTF8A bs) = ofoldr f b (decodeUtf8 bs)
 ofoldl' = undefined

 newtype ByteStringUTF8B = ByteStringUTF8B S.ByteString
 type instance Element ByteStringUTF8B = ByteStringUTF8B
 instance MonoFoldable ByteStringUTF8B where
 ofoldr f b (ByteStringUTF8B bs) = ofoldr (f . ByteStringUTF8B .
 encodeUtf8 . T.singleton) b (decodeUtf8 bs)
 ofoldl' = undefined

 I'd personally prefer the first approach, as that gives the right
 guarantees at the type level: each time the function is called, it will be
 provided with precisely one character. I believe the second approach
 provides the same behavior as monoid-subclasses does right now.


 Right now monoid-subclasses actually provides both approaches. You're
 correct that it provides the second one as instance FactorialMonoid
 ByteStringUTF8, but it also provides the former as instance TextualMonoid
 ByteStringUTF8. The TextualMonoid class is basically what you'd get if you
 restricted MonoFoldable to type Elem=Char. I wanted to keep the package
 extension-free, you see.


Got it, that makes sense.


 My main point is that it's worth considering basing MonoFoldable on
 FactorialMonoid, because it can be considered its specialization. Methods
 like length, take, or reverse, which never mention the item type in their
 signature, can be inherited from the FactorialMonoid superclass with no
 change whatsoever. Other methods would differ in their signatures (and
 performance), but the semantics would carry over.



My immediate concern is that this would enforce a number of restrictions on
what could be a MonoFoldable. For example, you couldn't have an instance
for `Identity a`. Being able to fold over any arbitrary container, even if
it's not a Monoid, can be very useful.

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

Re: [Haskell-cafe] Package compatibility (SemVer, PVP, ECT)

[Gregory Collins]

On Fri, Sep 13, 2013 at 5:25 AM, Thiago Negri evoh...@gmail.com wrote:

 Is PVP the one that every package on Hackage should use?


Yes.

G
-- 
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Do you want to maintain bindings-DSL?

[Maurício Antunes]

Hi,

bindings-DSL[1] is a stable and reliable macro package for FFI. It just
got a new tutorial and its repository is now in git. If no one else
wants to maintain it, I'll still be looking at issue reports and fixing
possible problems, but I've not been actively using Haskell for some time,
and won't add anything new or make plans for future changes.

The original idea behind bindings-DSL was to build a wide set of community
maintained raw bindings to interesting C libraries, on which Haskell
programmers could safely depend when creating their own higher level
packages. Although that idea never really took off, bindings-DSL itself
got some popularity, probably because it makes instancing Storable easy.

If you want to take maintenance, you have some options. You could just
kill the bindings-* idea and add some flexibility to new macros, which
I always avoided to enforce consistency. Or you could keep the original
goal, and maybe add a mailing list and a web page where users could
request new libraries and discuss solutions to trick issues. A possible
plan for version 2 is to be independent of hsc2hs, and use a new syntax
instead of C macros.

Thanks. Best,
Maurício

[1]: http://bitbucket.org/mauricio/bindings-dsl
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Bytestring map/zipWith rationale

[Scott Lawrence]

Hello all,

Something's always bothered me about map and zipWith for ByteString. Why is it

map :: (Word8 - Word8) - ByteString - ByteString

but

zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]

? Obviously they can be transformed into each other with pack/unpack, and as I 
understand it, the compiler performs sufficient optimizations so that there's 
no performance hit to doing things like (pack $ zipWith xor a b), but it still 
seems inconsistent. Is there a deep reason for this?


--
Scott Lawrence

Linux baidar 3.10.9-1-ARCH #1 SMP PREEMPT Wed Aug 21 13:49:35 CEST 2013 x86_64 
GNU/Linux
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bytestring map/zipWith rationale

[Scott Lawrence]

On Thu, 12 Sep 2013, Tom Ellis wrote:


On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:

Something's always bothered me about map and zipWith for ByteString. Why is it

map :: (Word8 - Word8) - ByteString - ByteString

but

zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]


Well, what if you wanted to zipWith a function of type Word8 - Word8 -
Foo instead of Word8 - Word8 - Word8?


Then I would do what I do with map, and call `unpack` first.

Either of the two options is usable:

 map :: (Word8 - Word8) - ByteString - ByteString
 zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString - ByteString
   (or)
 map :: (Word8 - a) - ByteString - [a]
 zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]

I just don't understand why we have one from each.

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

Re: [Haskell-cafe] Bytestring map/zipWith rationale

[Tom Ellis]

On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:
 Something's always bothered me about map and zipWith for ByteString. Why is it
 
 map :: (Word8 - Word8) - ByteString - ByteString
 
 but
 
 zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]

Well, what if you wanted to zipWith a function of type Word8 - Word8 -
Foo instead of Word8 - Word8 - Word8?

Tom

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

Re: [Haskell-cafe] Bytestring map/zipWith rationale

[Artyom Kazak]

On Thu, 12 Sep 2013 18:24:24 +0400, Tom Ellis  
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:



On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:
Something's always bothered me about map and zipWith for ByteString.  
Why is it


map :: (Word8 - Word8) - ByteString - ByteString

but

zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]


Well, what if you wanted to zipWith a function of type Word8 - Word8 -
Foo instead of Word8 - Word8 - Word8?


Then why doesn’t map take “Word8 - a”, but only “Word8 - Word8”?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bytestring map/zipWith rationale

[Carter Schonwald]

Scott: benchmark the two and you'll see why we have both :-)

On Thursday, September 12, 2013, Scott Lawrence wrote:

 On Thu, 12 Sep 2013, Tom Ellis wrote:

  On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:

 Something's always bothered me about map and zipWith for ByteString. Why
 is it

 map :: (Word8 - Word8) - ByteString - ByteString

 but

 zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]


 Well, what if you wanted to zipWith a function of type Word8 - Word8 -
 Foo instead of Word8 - Word8 - Word8?


 Then I would do what I do with map, and call `unpack` first.

 Either of the two options is usable:

  map :: (Word8 - Word8) - ByteString - ByteString
  zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString -
 ByteString
(or)
  map :: (Word8 - a) - ByteString - [a]
  zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]

 I just don't understand why we have one from each.

 --
 Scott Lawrence
 __**_
 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] Bytestring map/zipWith rationale

[John Lato]

Carter: we don't have both.  We have one function from each category.  My
guess is nobody's ever really needed a really fast zipWith ::
(Word8-Word8-Word8) - ByteString - ByteString - ByteString; that's the
only reason I can think of for its omission.


On Thu, Sep 12, 2013 at 10:45 AM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 Scott: benchmark the two and you'll see why we have both :-)


 On Thursday, September 12, 2013, Scott Lawrence wrote:

 On Thu, 12 Sep 2013, Tom Ellis wrote:

  On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:

 Something's always bothered me about map and zipWith for ByteString.
 Why is it

 map :: (Word8 - Word8) - ByteString - ByteString

 but

 zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]


 Well, what if you wanted to zipWith a function of type Word8 - Word8 -
 Foo instead of Word8 - Word8 - Word8?


 Then I would do what I do with map, and call `unpack` first.

 Either of the two options is usable:

  map :: (Word8 - Word8) - ByteString - ByteString
  zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString -
 ByteString
(or)
  map :: (Word8 - a) - ByteString - [a]
  zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]

 I just don't understand why we have one from each.

 --
 Scott Lawrence
 __**_
 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


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

Re: [Haskell-cafe] Bytestring map/zipWith rationale

[Nicolas Trangez]

I did use that a couple of times (`xor`ing 2 ByteStrings together), and was
surprised by the omission back then, but IIRC (can't validate now), there's
a specialised zipWith (as proposed) in the module (with some other name,
obviously), which is not exported, but used when you 'pack' the result of
'zipWith' when the result is '[Word8]'... You might want to look into that.

Nicolas
On Sep 12, 2013 8:11 PM, John Lato jwl...@gmail.com wrote:

 Carter: we don't have both.  We have one function from each category.  My
 guess is nobody's ever really needed a really fast zipWith ::
 (Word8-Word8-Word8) - ByteString - ByteString - ByteString; that's the
 only reason I can think of for its omission.


 On Thu, Sep 12, 2013 at 10:45 AM, Carter Schonwald 
 carter.schonw...@gmail.com wrote:

 Scott: benchmark the two and you'll see why we have both :-)


 On Thursday, September 12, 2013, Scott Lawrence wrote:

 On Thu, 12 Sep 2013, Tom Ellis wrote:

  On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:

 Something's always bothered me about map and zipWith for ByteString.
 Why is it

 map :: (Word8 - Word8) - ByteString - ByteString

 but

 zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]


 Well, what if you wanted to zipWith a function of type Word8 - Word8
 -
 Foo instead of Word8 - Word8 - Word8?


 Then I would do what I do with map, and call `unpack` first.

 Either of the two options is usable:

  map :: (Word8 - Word8) - ByteString - ByteString
  zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString -
 ByteString
(or)
  map :: (Word8 - a) - ByteString - [a]
  zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]

 I just don't understand why we have one from each.

 --
 Scott Lawrence
 __**_
 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



 ___
 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] Hackage 2 now available for beta testing

[Andreas Abel]

 

On 09.09.2013 20:24, Duncan Coutts wrote:
 Well-Typed and the
Industrial Haskell Group (IHG) are very pleased
 to announce that
Hackage 2 is now available for public beta testing.
 
 [new features]:
http://beta.hackage.haskell.org/new-features
 
 Package candidates.
You may have noticed that package versions are
 often uploaded in quick
succession -- sometimes just minutes apart --
 because a mistake is
only noticed after the author uploaded. This
 feature lets you upload a
candidate, giving it a URL that others
 can download from, and gives
an opportunity for build bots and
 documentation builders to try the
package out. Once the author is
 satisfied then they can publish to the
main package index. We think
 this feature is about 90% complete. See
issue #41.

That sound so good! Thanks for putting out this
feature!

Andreas 

On 2013-09-09 20:24, Duncan Coutts wrote: 


Well-Typed and the Industrial Haskell Group (IHG) are very pleased to

announce that Hackage 2 is now available for public beta testing. The

plan is to do the final switchover in late September, to coincide
 with
ICFP.
 
 http://beta.hackage.haskell.org/ [1]
 
 Read on for details
of how to help with the public beta, an overview
 of the new features
and what the IHG has been doing to help.
 
 Support from the
Industrial Haskell Group
 =


 The IHG is a consortium of companies that rely on Haskell. The IHG

members have funded the effort to get Hackage 2 up to feature parity

and get it ready for the switchover. The IHG funded this effort
because
 while the volunteer effort got us the first 90% of the way
there
 (including adding a number of new features) there was still the
last
 90% to do to get it production ready.
 
 The IHG members
decided to fund Hackage 2 not just because they are
 good citizens, but
out of enlightened self-interest. Hackage has over
 5000 packages
written by over 1000 people -- including the world's best
 Haskell
developers. This is a massive resource. The IHG members
 recognise that
improvements to the tools and infrastructure that the
 community uses
helps the community to produce more and better code.
 This is a benefit
to everyone in the community -- including the
 commercial users.
 

The IHG is keen to increase its membership so that more resources can

be dedicated to improving the Haskell development platform. If your

organisation relies on Haskell in some way then you may want to

consider joining. See the IHG website for more details or contact

i...@industry.haskell.org.
 
 [IHG website]:
http://industry.haskell.org/ [2]
 
 Despite the help of the IHG in
getting to this point, Hackage is a
 community project, and its success
depends on the community maintaining
 and further improving the new
server. The code is now on github so it
 is easier to contribute, and
now that the server is live there is more
 immediate gratification for
volunteers contributing fixes and new
 features.
 
 Public beta

===
 
 We would like to encourage you to take part in the
public beta testing.
 We need help both from package authors as well as
other users of the
 site.
 
 Please report any problems you find
using the issue tracker on the
 hackage-server github site.
 
 [issue
tracker]: https://github.com/haskell/hackage-server/issues [3]
 [github
site]: https://github.com/haskell/hackage-server [4]
 
 We are
mirroring packages from the old server (every 30min) so it is
 suitable
to use as your main hackage server with some caveats: we are
 allowing
package authors to upload (as well as doing the mirroring) so
 you may
find a slightly different set of packages on this server.
 
 If you
are a package author then you are welcome to poke about and
 upload
packages. We have imported user accounts from the old server
 (except
for a small number of early adopters of the original server who
 will
need to contact an administrator). Note that before we do the
 final
switchover we will *delete everything* from the beta instance
 and do a
fresh import from the old hackage server.
 
 Configuring
cabal-install
 -
 
 Edit your ~/.cabal/config
file. Comment-out the existing remote-repo
 line near the top of the
file and add in a new one like this:
 
 --remote-repo:
hackage.haskell.org:http://hackage.haskell.org/packages/archive [5]
 

remote-repo: beta.hackage.haskell.org:http://beta.hackage.haskell.org/
[1]
 
 New features
 
 
 Though our main priority has
been feature parity so that we can switch
 over, volunteers have
contributed several new features, including
 better package search, a
new site theme, improved security, the ability
 to fix package
dependencies after a release, changelogs, and a
 REST-style
interface.
 
 See the beta site for more details on these new
features, plus details
 of other features that are partially
implemented or are in need of
 improvement.
 
 [new features]:
http://beta.hackage.haskell.org/new-features [6]
 
 

Re: [Haskell-cafe] Proposal: New syntax for Haskell

[Andreas Abel]

 

+1 

Cucumber seems to be great if you mainly want to read your code
over the telephone, distribute it via national radio broadcast, or
dictate it to your secretary or your voice recognition software. You can
program thus without having to use you fingers. You can lie on your back
on your sofa, close your eyes, and utter your programs... 

We could
have blind Haskell/Cucumber programming contests... 

Tons of new
possiblilities... 

Strongly support this proposal. ;-) 

Andreas 

On
2013-09-10 22:57, Artyom Kazak wrote: 

 On Wed, 11 Sep 2013 00:20:26
+0400, Thiago Negri evoh...@gmail.com wrote:
 
 I hope these jokes
do not cause people to be afraid to post new ideas.
 
 Agreed. I would
also like to clarify that my message was much more a joke 
 on
 the
incomprehensibility of legal acts than on the original proposal.
 
 By
the way, I am pretty impressed with this piece of Cucumber 

description/code:
 
 Scenario: Mislav creates a valid task with an
upload
 When I go to the Awesome Ruby Yahh task list page of the
Ruby 
 Rockstars project
 When I follow + Add Task
 And I fill in
Task title with Ohhh upload
 And I follow Attachment
 When I
attach the file features/support/sample_files/dragon.jpg to 

upload_file
 And I press Add Task
 And I wait for 1 second
 And I
should see Ohhh upload as a task name
 
 I was much more sceptical
when I had only seen the example in Niklas's 
 message.

___
 Haskell-Cafe mailing
list
 Haskell-Cafe@haskell.org

http://www.haskell.org/mailman/listinfo/haskell-cafe [1]

-- 
Andreas
Abel  Du bist der geliebte Mensch. 

Theoretical Computer Science,
University of Munich http://www.tcs.informatik.uni-muenchen.de/~abel/



Links:
--
[1]
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] Proposal: New syntax for Haskell

[David Thomas]

I've long been interested in a scripting language designed to be spoken.
Not interested enough to go about making it happen... but the idea is
fascinating and possibly useful.


On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote:

 **

 +1

 Cucumber seems to be great if you mainly want to read your code over the
 telephone, distribute it via national radio broadcast, or dictate it to
 your secretary or your voice recognition software.  You can program thus
 without having to use you fingers.  You can lie on your back on your sofa,
 close your eyes, and utter your programs...

 We could have blind Haskell/Cucumber programming contests...

 Tons of new possiblilities...

 Strongly support this proposal. ;-)

 Andreas

 On 2013-09-10 22:57, Artyom Kazak wrote:

 On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote:

 I hope these jokes do not cause people to be afraid to post new ideas.

 Agreed. I would also like to clarify that my message was much more a joke
 on
 the incomprehensibility of legal acts than on the original proposal.

 By the way, I am pretty impressed with this piece of Cucumber
 description/code:

Scenario: Mislav creates a valid task with an upload
  When I go to the Awesome Ruby Yahh task list page of the Ruby
 Rockstars project
  When I follow + Add Task
  And I fill in Task title with Ohhh upload
  And I follow Attachment
  When I attach the file features/support/sample_files/dragon.jpg to
 upload_file
  And I press Add Task
  And I wait for 1 second
  And I should see Ohhh upload as a task name

 I was much more sceptical when I had only seen the example in Niklas’s
 message.
 ___
 Haskell-Cafe mailing 
 listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe



 --
 Andreas Abel   Du bist der geliebte Mensch.

 Theoretical Computer Science, University of Munich 
 http://www.tcs.informatik.uni-muenchen.de/~abel/


 ___
 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] Proposal: New syntax for Haskell

[Brandon Allbery]

On Thu, Sep 12, 2013 at 6:00 PM, David Thomas davidleotho...@gmail.comwrote:

 I've long been interested in a scripting language designed to be spoken.
 Not interested enough to go about making it happen... but the idea is
 fascinating and possibly useful.


http://en.wikipedia.org/wiki/Shakespeare_(programming_language) ?   :)

-- 
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] GLFW not working in Cabal 1.18

[Albert Y. C. Lai]

On 13-09-10 09:27 PM, Thiago Negri wrote:

The package GLFW is not building in Cabal 1.18.

Setup.hs [1] depends on `rawSystemStdInOut` [2] that changed signature
between 1.16 and 1.18.


Consider cabal install --cabal-lib-version=1.16.

Replace 1.16 by the correct number. Use ghc-pkg list Cabal to find the 
correct number.


http://www.haskell.org/haskellwiki/PVP allows 1.16-1.18 to change 
public API.

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

Re: [Haskell-cafe] Proposal: New syntax for Haskell

[Bob Ippolito]

Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's
easy to read.

On Thursday, September 12, 2013, David Thomas wrote:

 I've long been interested in a scripting language designed to be spoken.
 Not interested enough to go about making it happen... but the idea is
 fascinating and possibly useful.


 On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel 
 andreas.a...@ifi.lmu.dejavascript:_e({}, 'cvml', 
 'andreas.a...@ifi.lmu.de');
  wrote:

 **

 +1

 Cucumber seems to be great if you mainly want to read your code over the
 telephone, distribute it via national radio broadcast, or dictate it to
 your secretary or your voice recognition software.  You can program thus
 without having to use you fingers.  You can lie on your back on your sofa,
 close your eyes, and utter your programs...

 We could have blind Haskell/Cucumber programming contests...

 Tons of new possiblilities...

 Strongly support this proposal. ;-)

 Andreas

 On 2013-09-10 22:57, Artyom Kazak wrote:

 On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com 
 javascript:_e({}, 'cvml', 'evoh...@gmail.com'); wrote:

 I hope these jokes do not cause people to be afraid to post new ideas.

 Agreed. I would also like to clarify that my message was much more a joke
 on
 the incomprehensibility of legal acts than on the original proposal.

 By the way, I am pretty impressed with this piece of Cucumber
 description/code:

Scenario: Mislav creates a valid task with an upload
  When I go to the Awesome Ruby Yahh task list page of the Ruby
 Rockstars project
  When I follow + Add Task
  And I fill in Task title with Ohhh upload
  And I follow Attachment
  When I attach the file features/support/sample_files/dragon.jpg to
 upload_file
  And I press Add Task
  And I wait for 1 second
  And I should see Ohhh upload as a task name

 I was much more sceptical when I had only seen the example in Niklas’s
 message.
 ___
 Haskell-Cafe mailing listhaskell-c...@haskell.org javascript:_e({}, 'cvml', 
 'Haskell-Cafe@haskell.org');http://www.haskell.org/mailman/listinfo/haskell-cafe



 --
 Andreas Abel   Du bist der geliebte Mensch.

 Theoretical Computer Science, University of Munich 
 http://www.tcs.informatik.uni-muenchen.de/~abel/


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org javascript:_e({}, 'cvml',
 '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] dns library version 1.0.0

[山本和彦]

Hi all,

I have released dns library version 1.0.0.

This version provides new APIs. Thus, version is now 1.0.0. The design
and implementation was done by Michael Orlitzky based on his
experience. 

Enjoy!

--Kazu

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

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Mario Blažević]

On 09/11/13 19:37, John Lato wrote:

I didn't see this message and replied privately to Michael earlier, so
I'm replicating my comments here.

1.  Sooner or later I expect you'll want something like this:

class LooseMap c el el' where


lMap :: (el - el') - c el - c el'

It covers the case of things like hashmaps/unboxed vectors that have
class constraints on elements.  Although maybe LooseFunctor or LFunctor
is a better name.

Probably something similar for Traversable would be good also, as would
a default instance in terms of Functor.

2.  IMHO cMapM_ (and related) should be part of the Foldable class.
This is entirely for performance reasons, but there's no downside since
you can just provide a default instance.

3.  I'm not entirely sure that the length* functions belong here.  I
understand why, and I think it's sensible reasoning, and I don't have a
good argument against it, but I just don't like it.  With those, and
mapM_-like functions, it seems that the foldable class is halfway to
being another monolithic ListLike.  But I don't have any better ideas
either.


	If monolithic classes bother you, my monoid-subclasses package manages 
to break down the functionality into several classes. One big difference 
is that everything is based off Monoid rather than Foldable, and that 
has some big effects on the interface.



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

Re: [Haskell-cafe] Bytestring map/zipWith rationale

[Thomas DuBuisson]

On Thu, Sep 12, 2013 at 12:44 PM, Nicolas Trangez nico...@incubaid.com wrote:
 I did use that a couple of times (`xor`ing 2 ByteStrings together), and was
 surprised by the omission back then, but IIRC (can't validate now), there's
 a specialised zipWith (as proposed) in the module (with some other name,
 obviously), which is not exported, but used when you 'pack' the result of
 'zipWith' when the result is '[Word8]'... You might want to look into that.

This is correct - there is a RULES pragma that rewrites `pack (zipWith
f)` into a more efficient `zipWith'` function of the type desired (see
the bytestring package).  I was very concerned about this when writing
lots of bytestring xor code for crypto-api and was pleased to find
that, if the syntactic form matches, things get optimized as you
desire.

Thomas


 Nicolas

 On Sep 12, 2013 8:11 PM, John Lato jwl...@gmail.com wrote:

 Carter: we don't have both.  We have one function from each category.  My
 guess is nobody's ever really needed a really fast zipWith ::
 (Word8-Word8-Word8) - ByteString - ByteString - ByteString; that's the
 only reason I can think of for its omission.


 On Thu, Sep 12, 2013 at 10:45 AM, Carter Schonwald
 carter.schonw...@gmail.com wrote:

 Scott: benchmark the two and you'll see why we have both :-)


 On Thursday, September 12, 2013, Scott Lawrence wrote:

 On Thu, 12 Sep 2013, Tom Ellis wrote:

 On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote:

 Something's always bothered me about map and zipWith for ByteString.
 Why is it

 map :: (Word8 - Word8) - ByteString - ByteString

 but

 zipWith :: (Word8 - Word8 - a) - ByteString - ByteString -
 [a]


 Well, what if you wanted to zipWith a function of type Word8 - Word8
 -
 Foo instead of Word8 - Word8 - Word8?


 Then I would do what I do with map, and call `unpack` first.

 Either of the two options is usable:

  map :: (Word8 - Word8) - ByteString - ByteString
  zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString -
 ByteString
(or)
  map :: (Word8 - a) - ByteString - [a]
  zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a]

 I just don't understand why we have one from each.

 --
 Scott Lawrence
 ___
 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


 ___
 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] Package compatibility (SemVer, PVP, ECT)

[Thiago Negri]

I've just read Semantic Versioning (SemVer) [1], Package Versioning Policy
(PVP) [2] and Eternal Compatibility in Theory (ECT) [3].

Is PVP the one that every package on Hackage should use?
SemVer seems to make more sense to me.

Also, ECT looks very promising, but it is dated back to 2005 and I didn't
see any package using it. Why?

If Cabal could map the package version number to the versioned module name,
there will be no need to uglify the client code. I mean, when I import
module A and define in dependencies a == 1.8.3, Cabal would map that to
module A_7 and bind that to the A I've imported. We would be locked in
with Cabal, but that seems to be a good tradeoff.

[1] http://semver.org
[2] http://www.haskell.org/haskellwiki/Pvp
[3]
http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/EternalCompatibilityInTheory
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Michael Snoyman]

On Thu, Sep 12, 2013 at 2:37 AM, John Lato jwl...@gmail.com wrote:

 I didn't see this message and replied privately to Michael earlier, so I'm
 replicating my comments here.


Sorry about that, I wrote to you privately first and then thought this
might be a good discussion for the cafe.


 1.  Sooner or later I expect you'll want something like this:

 class LooseMap c el el' where

   lMap :: (el - el') - c el - c el'


  It covers the case of things like hashmaps/unboxed vectors that have
 class constraints on elements.  Although maybe LooseFunctor or LFunctor is
 a better name.

 Probably something similar for Traversable would be good also, as would a
 default instance in terms of Functor.


That's interesting. It's quite similar to the CanMap[1] class in
classy-prelude or Each from lens, except it can drop a type parameter and
the fundeps by requiring the container to be polymorphic. If we're willing
to use more exotic extensions, ConstraintKinds could be useful as well:

class ConstrainedMap t where
type MapConstraint t e :: Constraint
cMap :: (MapConstraint t e1, MapConstraint t e2) = (e1 - e2) - t e1
- t e2
instance ConstrainedMap Set.Set where
type MapConstraint Set.Set e = Ord e
cMap = Set.map

One reason I'd definitely not want to call this anything with the name
Functor in it is because Set.map can violate the Functor laws, in
particular:

Set.map (f . g) /= Set.map f . Set.map g

I believe the only law that could be applied to Set.map would be:

Set.map f = Set.fromList . List.map f . Set.toList

I would presume this would generalize to any other possible instance.

One final idea would be to take your LooseMap and apply the same kind of
monomorphic conversion the rest of the library uses:

class MonoLooseMap c1 c2 | c1 - c2, c2 - c1 where
mlMap :: (Element c1 - Element c2) - c1 - c2
instance (Ord e1, Ord e2) = MonoLooseMap (Set.Set e1) (Set.Set e2) where
mlMap = Set.map

Of all of them, ConstrainedMap seems like it would be the most
user-friendly, as error messages would just have a single type parameter.
But I don't have any strong leanings.

[1]
http://haddocks.fpcomplete.com/fp/7.4.2/20130829-168/classy-prelude/ClassyPrelude-Classes.html#t:CanMap


 2.  IMHO cMapM_ (and related) should be part of the Foldable class.  This
 is entirely for performance reasons, but there's no downside since you can
 just provide a default instance.


Makes sense to me, done. By the way, this can't be done for sum/product,
because those require a constraint on the Element.


 3.  I'm not entirely sure that the length* functions belong here.  I
 understand why, and I think it's sensible reasoning, and I don't have a
 good argument against it, but I just don't like it.  With those, and
 mapM_-like functions, it seems that the foldable class is halfway to being
 another monolithic ListLike.  But I don't have any better ideas either.


I agree here, but like you said in (2), it's a performance concern. The
distinction I'd make from ListLike is that you only have to define
foldr/foldl to get a valid instance (and even that could be dropped to just
foldr, except for conflicts with the default signatures extension).


 As to the bikeshed color, I would prefer to just call the classes
 Foldable/Traversable.  People can use qualified imports to disambiguate
 when writing instances, and at call sites client code would never need
 Data.{Foldable|Traversable} and can just use these versions instead.  I'd
 still want a separate name for Functor though, since it's in the Prelude,
 so maybe it's better to be consistent.  My $.02.


I prefer avoiding the name conflict, for a few reasons:

   - In something like ClassyPrelude, we can export both typeclasses
   without a proper if they have separate names.
   - Error messages and documentation will be clearer. Consider how the
   type signature `ByteString - foo` doesn't let you know whether it's a
   strict or lazy bytestring.
   - I got specific feedback from Edward that it would be easier to include
   instances for these classes if the names didn't clash with standard
   terminology.
   - It leaves the door open for including this concept upstream in the
   future, even if that's not the goal for now.




 On Wed, Sep 11, 2013 at 3:25 PM, Michael Snoyman mich...@snoyman.comwrote:

 That's really funny timing. I started work on a very similar project just
 this week:

  https://github.com/snoyberg/mono-traversable

 It's not refined yet, which is why I haven't discussed it too publicly,
 but it's probably at the point where some review would make sense. There's
 been a bit of a discussion on a separate Github issue[1] about it.

 A few caveats:

- The names are completely up for debate, many of them could be
improved.
- The laws aren't documented yet, but they mirror the laws for the
polymorphic classes these classes are based on.
- The Data.MonoTraversable module is the main module to look at. The
other two are far 

Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Michael Snoyman]

On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević blama...@acanac.net wrote:

 On 09/11/13 19:37, John Lato wrote:

 I didn't see this message and replied privately to Michael earlier, so
 I'm replicating my comments here.

 1.  Sooner or later I expect you'll want something like this:

 class LooseMap c el el' where


 lMap :: (el - el') - c el - c el'

 It covers the case of things like hashmaps/unboxed vectors that have
 class constraints on elements.  Although maybe LooseFunctor or LFunctor
 is a better name.

 Probably something similar for Traversable would be good also, as would
 a default instance in terms of Functor.

 2.  IMHO cMapM_ (and related) should be part of the Foldable class.
 This is entirely for performance reasons, but there's no downside since
 you can just provide a default instance.

 3.  I'm not entirely sure that the length* functions belong here.  I
 understand why, and I think it's sensible reasoning, and I don't have a
 good argument against it, but I just don't like it.  With those, and
 mapM_-like functions, it seems that the foldable class is halfway to
 being another monolithic ListLike.  But I don't have any better ideas
 either.


 If monolithic classes bother you, my monoid-subclasses package
 manages to break down the functionality into several classes. One big
 difference is that everything is based off Monoid rather than Foldable, and
 that has some big effects on the interface.



I'd point out what I'd consider a bigger difference: the type signatures
have changed in a significant way. With MonoFoldable, folding on a
ByteString would be:

(Word8 - b - b) - b - ByteString - b

With monoid-subclasses, you get:

(ByteString - b - b) - b - ByteString - b

There's certainly a performance issue to discuss, but I'm more worried
about semantics. Word8 tells me something very specific: I have one, and
precisely one, octet. ByteString tells me I have anywhere from 0 to 2^32 or
2^64  octets. Yes, we know from context that it will always be of size one,
but the type system can't enforce that invariant.

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