Re: [Haskell-cafe] Data-Type Serialization

[Stephen Tetley]

I think both ATerms and the Zephyr project's ASDL could handle
recursive types - certainly ASDL was a sum and product representation
like ML or Haskell's algebraic types (ATerms were a bit more like
Prolog). Both never gained much traction and for better or worse JSON
won the game.

I implemented generators for both a very long time ago when I was
staring out with Haskell. I didn't use TH or a generics library. If I
were doing it again now I'd start with a generics library and see how
that pans out - basically you want a type representation and generics
libraries have that already. Also I'm no fan of TH.

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

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Sjoerd Visscher]

I don't think max would be a good choice, as that would mean that the default 
multiplicity would have to be negative infinity (the identity element of max) 
instead of 0, and then using Int as the type for multiplicity would not cut it.

greetings,

Sjoerd

On Apr 20, 2012, at 11:02 AM, Stefan Holdermans wrote:

> Wren,
> 
>>> For a specific example, I haven't the faintest intuition about
>>> what 'map' should do.  Suppose we have
>>> {(k1)x1, (k2)x2}
>>> and f x1 == f x2 = y.  Should the value of map f {...} be
>>> {(k1+k2)y} or {(k1`max`k2)y} or what?
>> 
>> Good question. I'd suppose that they should be parametrized by any 
>> (Abelian?) group on the weights/multiplicities, where (+) is the canonical 
>> one since we're talking about "negative" membership.
> 
> Any groupoid on the multiplicities would do, I guess.
> 
> As I wrote in my answer to Richard, max seems a better choise, as it nicely 
> generalises mapping on sets.
> 
> Cheers,
> 
>  Stefan
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

--
Sjoerd Visscher
sjo...@w3future.com




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

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Stefan Holdermans]

Sjoerd,

 For a specific example, I haven't the faintest intuition about
 what 'map' should do.  Suppose we have
{(k1)x1, (k2)x2}
 and f x1 == f x2 = y.  Should the value of map f {...} be
 {(k1+k2)y} or {(k1`max`k2)y} or what?

> I don't think max would be a good choice, as that would mean that the default 
> multiplicity would have to be negative infinity (the identity element of max) 
> instead of 0, and then using Int as the type for multiplicity would not cut 
> it.

Why would one need such an identity element for map?

Note that the monoidal structure isn't defined over the "maximum of 
multiplicites" but over the "maximum of *nonzero* multiplicites". (For ordinary 
sets and ordinary multisets these operations happen to coincide.)

Cheers,

  Stefan

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

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Sjoerd Visscher]

This is not just about map, but it also a problem for the Monoid instance. You 
are basically adding an extra identity element, 0, to the max monoid, which 
works but is weird. You'll have to call norm everywhere to make it work, f.e. 
you would expect this to work:

empty' = insert () $ delete () empty

but:

empty' <> delete () empty == empty'

while:

empty <> delete () empty == delete () empty

(I couldn't test it as I don't have base 4.5, so I hope I didn't make a mistake 
here.)

greetings,
Sjoerd

On Apr 23, 2012, at 2:07 PM, Stefan Holdermans wrote:

> Sjoerd,
> 
> For a specific example, I haven't the faintest intuition about
> what 'map' should do.  Suppose we have
>   {(k1)x1, (k2)x2}
> and f x1 == f x2 = y.  Should the value of map f {...} be
> {(k1+k2)y} or {(k1`max`k2)y} or what?
> 
>> I don't think max would be a good choice, as that would mean that the 
>> default multiplicity would have to be negative infinity (the identity 
>> element of max) instead of 0, and then using Int as the type for 
>> multiplicity would not cut it.
> 
> Why would one need such an identity element for map?
> 
> Note that the monoidal structure isn't defined over the "maximum of 
> multiplicites" but over the "maximum of *nonzero* multiplicites". (For 
> ordinary sets and ordinary multisets these operations happen to coincide.)
> 
> Cheers,
> 
>  Stefan
> 





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

[Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Paul Graphov]

Hello Cafe!

I am using protocol-buffers and hprotoc packages but they fail to
compile with recent GHC due to trivial errors. Hackage names
Christopher Edward Kuklewicz as their maintainer. I've sent him
patches more than a month ago but neiter they were applied nor I got
any response. It's quite inconvenient to keep patched versions all the
time. Does anybody know if he is still interested in maintaining those
packages? Is it possible to contact him? And what should I do if he is
unreachable?

Thanks!

Links:

http://hackage.haskell.org/package/protocol-buffers
http://hackage.haskell.org/package/hprotoc

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

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Stefan Holdermans]

Sjoerd,

> This is not just about map, but it also a problem for the Monoid instance. 
> You are basically adding an extra identity element, 0, to the max monoid, 
> which works but is weird.

Still that's how union is typically defined for hybrid sets. It's what happens 
if want union and empty to behave as generalisations of these concepts for 
ordinary (multi)sets.

> empty' = insert () $ delete () empty
> 
> but:
> 
> empty' <> delete () empty == empty'
> 
> while:
> 
> empty <> delete () empty == delete () empty
> 
> (I couldn't test it as I don't have base 4.5, so I hope I didn't make a 
> mistake here.)

*Data.SignedMultiset> let empty' = insert () $ delete () empty

*Data.SignedMultiset> empty' `union` delete () empty == empty'
False

*Data.SignedMultiset> empty `union` delete () empty == delete () empty
True

Cheers,

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

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Sjoerd Visscher]

On Apr 23, 2012, at 3:18 PM, Stefan Holdermans wrote:

> Sjoerd,
> 
>> This is not just about map, but it also a problem for the Monoid instance. 
>> You are basically adding an extra identity element, 0, to the max monoid, 
>> which works but is weird.
> 
> Still that's how union is typically defined for hybrid sets. It's what 
> happens if want union and empty to behave as generalisations of these 
> concepts for ordinary (multi)sets.

Then why would you want that?

> *Data.SignedMultiset> let empty' = insert () $ delete () empty
> 
> *Data.SignedMultiset> empty' `union` delete () empty == empty'
> False
> 
> *Data.SignedMultiset> empty `union` delete () empty == delete () empty
> True


Ah, I missed the check in insertMany.

What about the same with

let empty' = multiply 0 $ delete () empty

greetings,
Sjoerd



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

[Haskell-cafe] ANNOUNCE: hsx-0.10.1, hjscript-0.6.0, hsp-0.7.0

[Niklas Broberg]

Hi all,

I'm pleased to announce the release of the latest versions of the libraries
in the Haskell Server Pages suite.

Haskell Server Pages enables literal XML syntax to be used mixed with
Haskell code (like e.g. PHP), in a sane way (unlike said PHP). In principle
the functionality could be used together with any Haskell web framework,
but is (currently) best integrated in and supported by Happstack. For this
release I owe much to Jeremy Shaw, both for inspiration and for actual
patches.

There are some grand plans in the pipeline for some more extensive changes
to the suite, to shape it up to be worthy of the current exciting
state-of-the-art of Haskell web development. Stay tuned!

Cheers,

/Niklas


Specific changes in this release:

* In the XMLGen class, the following associated types have been renamed to
avoid frequent name clashes, and to better match the intention of those
types: XML => XMLType, Child => ChildType, Attribute => AttributeType.

* Literal CDATA strings are now given an explicit type signature in the
post-processed code. This to avoid ambiguities when OverloadedStrings is
enabled.

* class XMLGenerator m now has EmbedAsChild m () as another premise.

* HSX.Transform now exports a method transformExp :: Exp -> Exp, intended
to be used with quasi-quotation.

* trhsx no longer performs fixity resolution before transforming, allowing
the tool to be used on files using operators with (locally) unknown fixity.

* hsp and hjscript updated to work with hsx-0.10.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Stefan Holdermans]

Sjoerd,

>>> This is not just about map, but it also a problem for the Monoid instance. 
>>> You are basically adding an extra identity element, 0, to the max monoid, 
>>> which works but is weird.

>> Still that's how union is typically defined for hybrid sets. It's what 
>> happens if want union and empty to behave as generalisations of these 
>> concepts for ordinary (multi)sets.

> Then why would you want that?

You don't have to. (SignedMultiset a, additiveUnion, empty) gives you the 
Monoid that you seem to have a preference for. The library supplies it through 
the Additive wrapper. The point is that you have a choice: different 
applications may ask for different monoidal structures.

>> *Data.SignedMultiset> let empty' = insert () $ delete () empty
>> 
>> *Data.SignedMultiset> empty' `union` delete () empty == empty'
>> False
>> 
>> *Data.SignedMultiset> empty `union` delete () empty == delete () empty
>> True

> Ah, I missed the check in insertMany.
> 
> What about the same with
> 
> let empty' = multiply 0 $ delete () empty

*Data.SignedMultiset> let empty' = multiply 0 $ delete () empty

*Data.SignedMultiset> empty' `union` delete () empty == empty'
True

*Data.SignedMultiset> empty `union` delete () empty == delete () empty
True

Cheers,

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

[Haskell-cafe] No email verification token from trac.haskell.org

[Niklas Broberg]

Hi all,

I have problems with my trac for haskell-src-exts. When I log in, I am
asked to verify my email address, but no verification token is ever sent to
my email address. And before I verify my address, I'm not allowed to do
anything on the trac.

Help? :-)

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

Re: [Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Aleksey Khudyakov]

On 23.04.2012 17:01, Paul Graphov wrote:

Hello Cafe!

I am using protocol-buffers and hprotoc packages but they fail to
compile with recent GHC due to trivial errors. Hackage names
Christopher Edward Kuklewicz as their maintainer. I've sent him
patches more than a month ago but neiter they were applied nor I got
any response. It's quite inconvenient to keep patched versions all the
time. Does anybody know if he is still interested in maintaining those
packages? Is it possible to contact him? And what should I do if he is
unreachable?

I've too tried to contact him almost year ago about same issue. Never 
got an answer.


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

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Sjoerd Visscher]

On Apr 23, 2012, at 4:34 PM, Stefan Holdermans wrote:

> Sjoerd,
> 
 This is not just about map, but it also a problem for the Monoid instance. 
 You are basically adding an extra identity element, 0, to the max monoid, 
 which works but is weird.
> 
>>> Still that's how union is typically defined for hybrid sets. It's what 
>>> happens if want union and empty to behave as generalisations of these 
>>> concepts for ordinary (multi)sets.
> 
>> Then why would you want that?
> 
> You don't have to. (SignedMultiset a, additiveUnion, empty) gives you the 
> Monoid that you seem to have a preference for. The library supplies it 
> through the Additive wrapper. The point is that you have a choice: different 
> applications may ask for different monoidal structures.

Agreed. But I just can't imagine that the other instance is in any way useful. 
You basically define a function max':

max' :: Int -> Int -> Int
max' 0 b = b
max' a 0 = a
max' a b = max a b

i.e.

max' -2 -1 = -1 
max' -2 0 = -2
max' -2 1 = 1

Wouldn't you agree that if you saw this defined in some code, you'd think 
something is wrong?

> *Data.SignedMultiset> let empty' = multiply 0 $ delete () empty
> 
> *Data.SignedMultiset> empty' `union` delete () empty == empty'
> True
> 
> *Data.SignedMultiset> empty `union` delete () empty == delete () empty
> True


And this doesn't bother you?

greetings,
Sjoerd

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

Re: [Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Max Rabkin]

On Mon, Apr 23, 2012 at 15:01, Paul Graphov  wrote:
> And what should I do if he is
> unreachable?

My feeling is that if you are willing to take it on, you should ask
this list if anybody objects to your taking over the maintainership,
and if they do not, take it over (on Hackage, this just means
uploading a new version of the package).

--Max

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

Re: [Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Johan Tibell]

On Mon, Apr 23, 2012 at 7:53 AM, Max Rabkin  wrote:
> On Mon, Apr 23, 2012 at 15:01, Paul Graphov  wrote:
>> And what should I do if he is
>> unreachable?
>
> My feeling is that if you are willing to take it on, you should ask
> this list if anybody objects to your taking over the maintainership,
> and if they do not, take it over (on Hackage, this just means
> uploading a new version of the package).

If Chris is indeed out of the loop we should find a new maintainer.
Mark and I are also interested in the future of protocol buffers in
Haskell.

-- Johan

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

Re: [Haskell-cafe] No email verification token from trac.haskell.org

[Johan Tibell]

On Mon, Apr 23, 2012 at 7:42 AM, Niklas Broberg
 wrote:
> Hi all,
>
> I have problems with my trac for haskell-src-exts. When I log in, I am asked
> to verify my email address, but no verification token is ever sent to my
> email address. And before I verify my address, I'm not allowed to do
> anything on the trac.
>
> Help? :-)
>
> /Niklas

I've had the same problem for a long time. I assume the Trac instance is broken.

-- Johan

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

Re: [Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Vo Minh Thu]

For what it's worth, I think he is active on stackoverflow.

Thu

Le 23 avril 2012 17:13, Johan Tibell  a écrit :
> On Mon, Apr 23, 2012 at 7:53 AM, Max Rabkin  wrote:
>> On Mon, Apr 23, 2012 at 15:01, Paul Graphov  wrote:
>>> And what should I do if he is
>>> unreachable?
>>
>> My feeling is that if you are willing to take it on, you should ask
>> this list if anybody objects to your taking over the maintainership,
>> and if they do not, take it over (on Hackage, this just means
>> uploading a new version of the package).
>
> If Chris is indeed out of the loop we should find a new maintainer.
> Mark and I are also interested in the future of protocol buffers in
> Haskell.
>
> -- Johan
>
> ___
> 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] No email verification token from trac.haskell.org

[Niklas Broberg]

On Mon, Apr 23, 2012 at 5:13 PM, Johan Tibell wrote:

> On Mon, Apr 23, 2012 at 7:42 AM, Niklas Broberg
>  wrote:
>   > I have problems with my trac for haskell-src-exts. When I log in, I am
> asked
> > to verify my email address, but no verification token is ever sent to my
> > email address. And before I verify my address, I'm not allowed to do
> > anything on the trac.
>
> I've had the same problem for a long time. I assume the Trac instance is
> broken
>

Certainly sounds plausible - but how to fix it? There are some possible
fixes listed on the Trac homepage, but I don't seem to have enough
permissions to do anything at all.

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

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

On 04/23/2012 12:03 AM, wren ng thornton wrote:

However, until better technical support is implemented (not just for
GHC, but also jhc, UHC,...) it's best to follow social practice.


Wren, I am new to Haskell and not aware of all of the conventions. Is 
there a place where I can find information on these social practices? 
Are they documented some place?



However, centralization is prone to bottlenecks and systemic failure.
As such, while it would be nice to ensure that a given module is
provided by only one package, there is no mechanism in place to
enforce this (except at compile time for the code that links the
conflicting modules together).


From someone new to the community, it seems that yes centralization has 
its issues, but it also seems that practices could be put in place that 
minimize the bottlenecks and systemic failures.


Unless I greatly misunderstand the challenges,  there seem to be lot of 
ways to approach this problem and none of them are new. We all use 
systems that are composed of many modules neatly combined into complete 
systems. Linux distributions do this well. So does Java. Maybe should 
borough from their experiences and think about how we put packages 
together and what mechanisms we need to resolve inter-package dependencies.


Am I missing something that makes this problem harder than other systems 
and languages? Is anyone currently working on the packaging  and 
distribution issues? If not, does anyone else want to work on it?


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

Re: [Haskell-cafe] "desactivate" my Show instance implementations temporarily

[Evan Laforge]

I use a custom Pretty class along with HughesPJ, ala ghc's Outputable.
 It means I can omit data or print it out in a more readable form
(even just rounding floats to %.03f can help a lot), and also get nice
layout and wrapping.  The downside is a certain amount of boilerplate
to write output routines for records.  Actually, types with multiple
constructors are the most annoying.  At some point I should
investigate the new generic deriving feature to see if some of that
can be automated.

As a user of libraries, I get annoyed when they implement Show to
something nonstandard.  It makes it harder to figure out how the
library works.

On Sun, Apr 22, 2012 at 4:20 AM, Ivan Lazar Miljenovic
 wrote:
> On 22 April 2012 19:55, TP  wrote:
>> On Sunday 22 April 2012 19:37:19 Ivan Lazar Miljenovic wrote:
>>
>>> Is there any particular reason you're *not* using the defaults?
>>
>> This is a good question which I have asked myself. I have searched about the
>> topic, and found that:
>>
>> http://blog.romanandreg.com/post/13545420287/haskells-show-and-pretty-
>> printing-bad-practice
>>
>> So, according to this address, Show implementation should be used with Read 
>> so
>> as to have show.read equal to identity: this is the only "good practice
>> requirement".
>>
>> In my case, I use Show to print mathematical expressions, but it is not
>> strictly pretty printing (not over several lines as in classical Computer
>> Algebra Sytems). Why not using my own Show implementation to do that?
>
> For exactly the same reason you're discovering: Show/Read exist for debugging.
>
> Show and Read are meant to produce/read valid Haskell code (modulo
> [qualified] imports) so that you can work out what code is going wrong
> (and coincidentally used as a quick`n`dirty serialisation method).
>
> The term "pretty-printing" is meant in regards to producing
> _human-readable_ versions of your data (though the pretty-printing
> libraries can also be used to produce code formatted for some other
> tool to parse, etc.).  Show/Read happen to be auto-derivable classes
> that implement one such form of pretty-printing (i.e. "printing"
> values that look like the actual source code that represents them).
>
> Let me provide you with a personal anecdote: when I took over
> maintaining the graphviz library, it was still using the Show class
> for printing (but a proper parser library for parsing), and it was
> working with the limited functionality it had.  However, whenever I
> tried to do something new, I found problems:
>
> * Existing Show instances meant that it was very difficult to extend
> what the library could represent and then print properly.
>
> * As you've found, it can then be a PITA to debug because you have no
> idea what the internal values actually are.
>
> In the end, I eventually wrote a custom pretty-printing class (the
> existing pretty-printing classes had instances that didn't suit, just
> like Show) and it's worked a lot better since.
>
> The only time it's valid to override the default Show/Read instances
> is when the constructors aren't exported (e.g. Data.Map), but even
> then it should be valid Haskell (if you ignore imports, etc.).
>
> So leave Show/Read as they are, and write a custom function[s] that
> does the actual pretty-printing you want.
>
> --
> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Stefan Holdermans]

Sjoerd,

>>> Then why would you want that?
>> 
>> You don't have to. (SignedMultiset a, additiveUnion, empty) gives you the 
>> Monoid that you seem to have a preference for. The library supplies it 
>> through the Additive wrapper. The point is that you have a choice: different 
>> applications may ask for different monoidal structures.
> 
> Agreed. But I just can't imagine that the other instance is in any way 
> useful. You basically define a function max':
> 
> max' :: Int -> Int -> Int
> max' 0 b = b
> max' a 0 = a
> max' a b = max a b
> 
> i.e.
> 
> max' -2 -1 = -1 
> max' -2 0 = -2
> max' -2 1 = 1
> 
> Wouldn't you agree that if you saw this defined in some code, you'd think 
> something is wrong?

If max' is supposed to implement the maximum of two nonzero values, I wouldn't 
be the slightest bit concerned. Seriously: if this is what people have agreed 
on to be a sensible semantics for hybrid sets, I am fine implementing it like 
this.

>> *Data.SignedMultiset> let empty' = multiply 0 $ delete () empty
>> 
>> *Data.SignedMultiset> empty' `union` delete () empty == empty'
>> True
>> 
>> *Data.SignedMultiset> empty `union` delete () empty == delete () empty
>> True
> 
> 
> And this doesn't bother you?

Of course it does; it pinpoints a bug in multiply. It's fixed now:

*Data.SignedMultiset> let empty' = multiply 0 $ delete () empty

*Data.SignedMultiset> empty' `union` delete () empty == empty'
False

*Data.SignedMultiset> empty `union` delete () empty == delete () empty
True

Cheers,

  Stefan

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

[Haskell-cafe] Need feedback on my EDSL attempt for writing test scripts

[C K Kashyap]

Dear cafe,
Recently, I decided to use Haskell to drive the testing of a C++ DLL that
we develop. After getting the FFI etc working, I thought it might be a good
idea to expose an EDSL for the testers to alter the flow of invocations of
the functions in the DLL. I've tried to demonstrate the approach I am
contemplating here - http://hpaste.org/67495

The outcome is that I'll have a set of "Instructions" for the testers can
arrange to create a sequence of calls.

> data Command = Void | Init | Get3Numbers Int Int Int| GetName String |
PrintName | PrintSum | Close | PrintMessage String
> deriving (Show)

> mainloop :: StateT (ScriptState Command) IO ()
> mainloop = do
> liftIO $ putStrLn "Hello World"
> executeCommand Init
> executeCommand Init
> executeCommand $ PrintMessage "Enter name"
> executeCommand $ GetName "abcd"
> return ()


I'd like to ensure that some level of validation done. For example, if Init
is called twice, the tester should get to know about it. Similarly, GeName
should not be called unless PrintMessage has been called.

> executeCommand :: Command -> StateT (ScriptState Command) IO ()
> executeCommand Init = do
>(ScriptState c) <- get
>case c of
> Void -> liftIO $ putStrLn (show c)
> _-> liftIO $ putStrLn "Init already called"
>put (ScriptState Init)
>return ()
> executeCommand (GetName x) = do
>(ScriptState c) <- get
>case c of
> PrintMessage _ -> do { str <- liftIO $ getLine; put
(ScriptState (GetName str)); return ()}
> _  -> liftIO $ putStrLn "PrintMessage not
called"
> executeCommand (PrintMessage m) = do
>liftIO $ putStrLn m
>put (ScriptState (PrintMessage m))


I'd appreciate it very much if you could give me some feedback on my
approach. I get this feeling that I am wrapping up the whole program inside
a State monad - does this mean that I am giving up the functional goodies.

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

[Haskell-cafe] Is it only one data structure per ST monad?

[KC]

Is it only one data structure per ST monad?

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

Re: [Haskell-cafe] Is it only one data structure per ST monad?

[MigMit]

I would argue that there is just one ST monad, which makes the question even 
more strange.

On 23 Apr 2012, at 22:32, KC wrote:

> Is it only one data structure per ST monad?
> 
> -- 
> --
> Regards,
> KC
> ___
> 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] Correspondence between libraries and modules

[Alvaro Gutierrez]

Thanks for the write-up -- it's been very helpful!

On Mon, Apr 23, 2012 at 12:03 AM, wren ng thornton wrote:

> Consider one of my own libraries (chosen randomly via Safari's url
> autocompletion):
>

>
> http://hackage.haskell.org/**package/bytestring-lexing
>
> When I inherited this package there were the Data.ByteString.Lex.Double
> and Data.ByteString.Lex.Lazy.**Double modules, which were separated
> because they provide the same API but for strict vs lazy ByteStrings. Both
> of those modules are concerned with lexing floating point numbers. I
> inherited the package because I wanted to publicize some code I had for
> lexing integers in various formats. Since that's quite a different task
> than lexing floating point numbers, I put it in its own module:
> Data.ByteString.Lex.Integral.
>

I see. The first thing that comes to mind is the notion of module
granularity, which of course is subjective, so whether a single module or
multiple ones should handle e.g. doubles and integrals is a good question;
are there guidelines as to how those choices are made?

At any rate, why do these modules, with sufficiently-different
functionality, live in the same library -- is it that they share some
common bits of implementation, or to ease the management of source code?

When dealing with FFI code, because of the impedance mismatch between
> Haskell and imperative languages like C, it's clear that there's going to
> be some massaging of the API beyond simply declaring FFI calls. As such,
> clearly we'd like to have separate modules for doing the low-level binding
> vs presenting a high-level API. Moreover, depending on what you're
> interfacing with, you may be forced to have multiple low-level modules.


Ah, that's a good use case. Is the lower-level module usually made "public"
as well, or is it only an implementation detail?


> On the other hand, the main purpose of packages or libraries is as unit of
> distribution, code reuse, and separate compilation. Even with the Haskell
> culture of making small libraries, most worthwhile units of
> distribution/reuse/compilation tend to be larger than a single
> namespace/concern. Thus, it makes sense to have more than one module per
> package, because otherwise we'd need some higher level mechanism in order
> to manage the collections of package-modules which should be considered a
> single unit (i.e., clients will almost always want the whole bunch of them).
>

This is the part that I'm trying to get a better sense of. I can see how in
some cases, it makes sense for more than one module to form a unit, because
they are tightly coupled semantically or implementation-wise -- so clients
will indeed want the whole bunch. On the other hand, several libraries
provide modules that are all over the place, in a way that doesn't form a
"unit" of any kind (e.g. MissingH), and it's not clear that you would want
any Network stuff when all you need is String utilities.

However, centralization is prone to bottlenecks and systemic failure. As
> such, while it would be nice to ensure that a given module is provided by
> only one package, there is no mechanism in place to enforce this (except at
> compile time for the code that links the conflicting modules together).
> With few exceptions, it's considered bad form to knowingly use the same
> module name as is being used by another package. In part, it's bad form
> because egos are involved; but it's also bad form because there's poor
> technical support for resolving namespace collisions for module names. In
> GHC you can use -XPackageImports, which is workable but conflates issues of
> code with issues of provenance, which the Haskell Report intentionally
> keeps separate. However, until better technical support is implemented (not
> just for GHC, but also jhc, UHC,...) it's best to follow social practice.
>
>
But the way you describe it, it seems that despite centralization having
those disadvantages, it is more or less the way the system works, socially
(egos, bad form, etc.) and technically (because of the lack of compiler
support) -- except that it is ad-hoc instead of mechanically enforced. In
other words, I don't see what the advantages of allowing ambiguity
currently are.

Some people figured to solve the new issue by implementing it both ways in
> separate packages, but reusing the same module names. (Witness for example
> mtl-2 aka monads-fd, vs monads-tf.) In practice, that didn't work out so
> well. Part of the reason for failure is that although fundeps and TF/ATs
> are formally equivalent in theory, in practice the implementation of TF/ATs
> has(had?) been missing some necessary machinery, and consequentially the
> TF/AT versions were not as powerful as the original fundep versions. Though
> the butterfly dependency issues certainly didn't help.


Ah, interesting. So, perhaps I misunderstand, but this seems like an
argument in favor of having uniquely-named modules

[Haskell-cafe] Announce: Hackager - new version of hackage-test

[David Terei]

Hi all,

I've updated the old hackage-test tool and renamed to hackager.

http://hackage.haskell.org/package/hackager

Hackager is a tool to automate the compiling of all packages on
Hackage. It builds each package on hackage in isolation and records
the results. The purpose being to catch regressions caused by changes
to GHC (and Cabal although this was not the motivation). Two runs of
Hackager can be compared, so the first run is done with a known
version of GHC and the next run with a new, experimental version of
GHC... ect.

The improvements to Hackager over hackage-test are:
* Parallelized the build process. Can now specify how many packages to
build in parallel, which cuts total run time down greatly (e.g 2 days
-> 5 hours)
* hackage-test and hackage-report are now one tool, 'hackager' that
works as a mutli-command tool.
* Proper option handling
* Fixed some stability issues

The new homepage for development can be found here:
https://github.com/dterei/Hackager

Cheers,
David

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

Re: [Haskell-cafe] Correspondence between libraries and modules

[Brandon Allbery]

On Mon, Apr 23, 2012 at 11:39, Gregg Lebovitz  wrote:

> Am I missing something that makes this problem harder than other systems
> and languages? Is anyone currently working on the packaging  and
> distribution issues? If not, does anyone else want to work on it?
>

The other dirty little secret that is carefully being avoided here is the
battle between the folks for whom Haskell is a language research platform
and those who use it to get work done.  It's not entirely inaccurate to say
the former group would regard a fragmented module namespace as a good
thing, specifically because it discourages people from considering it to be
stable

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Paul Graphov]

I'm not sure about being a maintainer - I don't even know how those
packages work and have no experience in preparing package for hackage.
But fixes are really trivial - maybe I'll just upload patched versions
if it is possible?

Is it possible to contact StackOverflow user?

On Mon, Apr 23, 2012 at 7:26 PM, Vo Minh Thu  wrote:
> For what it's worth, I think he is active on stackoverflow.
>
> Thu
>
> Le 23 avril 2012 17:13, Johan Tibell  a écrit :
>> On Mon, Apr 23, 2012 at 7:53 AM, Max Rabkin  wrote:
>>> On Mon, Apr 23, 2012 at 15:01, Paul Graphov  wrote:
 And what should I do if he is
 unreachable?
>>>
>>> My feeling is that if you are willing to take it on, you should ask
>>> this list if anybody objects to your taking over the maintainership,
>>> and if they do not, take it over (on Hackage, this just means
>>> uploading a new version of the package).
>>
>> If Chris is indeed out of the loop we should find a new maintainer.
>> Mark and I are also interested in the future of protocol buffers in
>> Haskell.
>>
>> -- Johan
>>
>> ___
>> 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] [Haskell-beginners] Is it only one data structure per ST monad?

[Edward Z. Yang]

If you mean, per 'ST s a', no: you can generate as many
STRefs as you want.

Edward

Excerpts from KC's message of Mon Apr 23 14:32:57 -0400 2012:
> Is it only one data structure per ST monad?
> 

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

[Haskell-cafe] (no subject)

[KC]

buildPair =
do
arr <- newArray ((1,1),(1,10)) 37 :: ST s (STArray s (Int,Int) Int)
a <- readArray arr (1,1)
writeArray arr (1,1) 64
b <- readArray arr (1,1)
return (a,b)


main = print $ runST buildPair


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

[Haskell-cafe] The last statement in a 'do' construct must be an expression: a <- readArray arr (1, 1)

[KC]

I'm getting the above error message and I cannot figure out why?


buildPair =
do
arr <- newArray ((1,1),(1,10)) 37 :: ST s (STArray s (Int,Int) Int)
a <- readArray arr (1,1)
writeArray arr (1,1) 64
b <- readArray arr (1,1)
return (a,b)


main = print $ runST buildPair


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

Re: [Haskell-cafe] The last statement in a 'do' construct must be an expression: a <- readArray arr (1, 1)

[Ryan Yates]

Perhaps you are mixing tabs and spaces?

On Mon, Apr 23, 2012 at 4:52 PM, KC  wrote:

> I'm getting the above error message and I cannot figure out why?
>
>
> buildPair =
> do
> arr <- newArray ((1,1),(1,10)) 37 :: ST s (STArray s (Int,Int) Int)
>  a <- readArray arr (1,1)
> writeArray arr (1,1) 64
> b <- readArray arr (1,1)
> return (a,b)
>
>
> main = print $ runST buildPair
>
>
> --
> --
> Regards,
> KC
>
> ___
> 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] HaL-7, 2012-07-13, Call for submissions

[Henning Thielemann]

Call for submissions and Save the date

for our local Haskell Workshop in Halle/Saale, Germany.

Tutorials, talks, demonstrations ... everything welcome.

Workshop language is German (mainly), and English (by request).

Submission deadline: May, 21, Workshop date: July, 13



Workshop homepage: http://iba-cg.de/hal7.html


The complete call in German:

-

Aufruf zum Einreichen von Beiträgen
und Hinweis zum Vormerken des Termins

Was: Haskell-Treffen HaL-7
Wann: Freitag, 13.07.2012
Wo: Institut für Informatik an der Martin-Luther-Universität in Halle an
der Saale

Wir suchen Vorträge zu Haskell im Besonderen und der funktionalen
Programmierung im Allgemeinen, zum Beispiel zu den Themen

* Neues von Sprache, Bibliotheken, Werkzeugen,
* Anwendungen von Kunst bis Industrie,
* Lehre an Schulen und Hochschulen,

gerne aber auch zu anderen Themen.

Die Beiträge können präsentiert werden als

* Tutorium (60 .. 90 min)
* Vortrag (30 min)
* Demonstration, künstlerische Aufführung

Die Veranstaltungssprache ist Deutsch, in begründeten Ausnahmen
Englisch. Presentations will be given in German but we can switch to
English if requested.

Bitte reichen Sie Kurzfassungen der Beiträge ein (2 bis 4 Seiten), die
dem Programmkomitee eine Einschätzung ermöglichen. Die Kurzfassung soll
mit einer Zusammenfassung (10 Zeilen) beginnen und einem
Literaturverzeichnis enden.

Teilnehmer des Workshops sind Interessenten (keine Erfahrung mit
Haskell/FP), Anfänger (wenig Erfahrung) und Experten. Wir bitten die
Vortragenden, die Zielgruppe des Beitrags anzugeben und die nötigen
Vorkenntnisse zu beschreiben. Bei Tutorien sollen Teilnehmer auf eigenen
Rechnern arbeiten. Bitte beschreiben Sie dazu die vorher zu
installierende Software.

Schicken Sie Beitragsvorschläge als PDF-Dokument bis zum

21.05.2012

per Mail an hal-committee at iba-cg punkt de oder an ein Mitglied des
Programmkomitees.


Programmkomitee

* Henning Thielemann - Univ. Halle (Vorsitzender),

* Petra Hofstedt - BTU Cottbus,
* Alf Richter - iba CG Leipzig,
* Uwe Schmidt - FH Wedel,
* Janis Voigtländer - Univ. Bonn,
* Johannes Waldmann - HTWK Leipzig.



Mit besten Grüßen
Henning Thielemann

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

Re: [Haskell-cafe] The last statement in a 'do' construct must be an expression: a <- readArray arr (1, 1)

[KC]

Thank you, that was it.

I was mixing up and tabs and spaces.

I expected new versions of NotePad++ to keep my old settings.


On Mon, Apr 23, 2012 at 1:54 PM, Ryan Yates  wrote:

> Perhaps you are mixing tabs and spaces?
>
> On Mon, Apr 23, 2012 at 4:52 PM, KC  wrote:
>
>> I'm getting the above error message and I cannot figure out why?
>>
>>
>> buildPair =
>> do
>> arr <- newArray ((1,1),(1,10)) 37 :: ST s (STArray s (Int,Int) Int)
>>  a <- readArray arr (1,1)
>> writeArray arr (1,1) 64
>> b <- readArray arr (1,1)
>> return (a,b)
>>
>>
>> main = print $ runST buildPair
>>
>>
>> --
>> --
>> Regards,
>> KC
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>


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

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

  
  


On 4/23/2012 3:39 PM, Brandon Allbery wrote:

  
On Mon, Apr 23, 2012 at 11:39, Gregg
  Lebovitz 
  wrote:
  

  Am I missing something that makes this
problem harder than other systems and languages? Is
anyone currently working on the packaging  and
distribution issues? If not, does anyone else want to
work on it?



The other dirty little secret that is carefully being
  avoided here is the battle between the folks for whom
  Haskell is a language research platform and those who use
  it to get work done.  It's not entirely inaccurate to say
  the former group would regard a fragmented module
  namespace as a good thing, specifically because it
  discourages people from considering it to be stable
  

  


Brandon, I find that a little hard to believe.  If the issues are
similar to other systems and languages, then  I think it is more
likely that no one has volunteered to work on it.  You volunteering
to help?


  

  
  
  
  
  -- 
  brandon s allbery                                      allber...@gmail.com
  wandering unix systems administrator (available)     (412)
  475-9364 vm/sms
  

  

  


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

Re: [Haskell-cafe] Announce: Hackager - new version of hackage-test

[Duncan Coutts]

Good work David.

I used to do something like this for Cabal regression testing but the
method I used didn't scale well as hackage grew. I'll look into using
your tool next time for testing a major Cabal / cabal-install release.

Duncan

On 23 April 2012 21:37, David Terei  wrote:
> Hi all,
>
> I've updated the old hackage-test tool and renamed to hackager.
>
> http://hackage.haskell.org/package/hackager
>
> Hackager is a tool to automate the compiling of all packages on
> Hackage. It builds each package on hackage in isolation and records
> the results. The purpose being to catch regressions caused by changes
> to GHC (and Cabal although this was not the motivation). Two runs of
> Hackager can be compared, so the first run is done with a known
> version of GHC and the next run with a new, experimental version of
> GHC... ect.
>
> The improvements to Hackager over hackage-test are:
> * Parallelized the build process. Can now specify how many packages to
> build in parallel, which cuts total run time down greatly (e.g 2 days
> -> 5 hours)
> * hackage-test and hackage-report are now one tool, 'hackager' that
> works as a mutli-command tool.
> * Proper option handling
> * Fixed some stability issues
>
> The new homepage for development can be found here:
> https://github.com/dterei/Hackager
>
> Cheers,
> David
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] ANN: signed-multiset-0.1

[Sjoerd Visscher]

On Apr 23, 2012, at 7:04 PM, Stefan Holdermans wrote:

> if this is what people have agreed on to be a sensible semantics for hybrid 
> sets, I am fine implementing it like this.

I have a hard time believing you have implemented the semantics that people 
have agreed on to be a sensible semantics for hybrid sets.

I would expect that multiplicity k (m `union` n) == multiplicity k m `max` 
multiplicity k n. Which means that an element of m with negative multiplicity 
is not a member of m `union` n if it is not a member of n. So that would mean 
that union would have to be implemented something like this:

SMS m `union` SMS n = SMS $ Map.intersectionWith max m n `Map.union` Map.filter 
(>= 0) ((m Map.\\ n) `Map.union` (n Map.\\ m))

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

Re: [Haskell-cafe] Correspondence between libraries and modules

[Brandon Allbery]

On Mon, Apr 23, 2012 at 17:16, Gregg Lebovitz  wrote:

> On 4/23/2012 3:39 PM, Brandon Allbery wrote:
>
>  The other dirty little secret that is carefully being avoided here is
> the battle between the folks for whom Haskell is a language research
> platform and those who use it to get work done.  It's not entirely
> inaccurate to say the former group would regard a fragmented module
> namespace as a good thing, specifically because it discourages people from
> considering it to be stable
>
> Brandon, I find that a little hard to believe.  If the issues are similar
> to other systems and languages, then  I think it is more likely that no one
> has volunteered to work on it.  You volunteering to help?
>

Yes, you do find it hard to believe; so hard that you went straight past it
and tried to point to the "easy" technical solution to the problem you
decided to see in place of the real one, which doesn't have a technical
solution.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe