[Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, November 2010 edition

[Janis Voigtländer]

Dear all,

It is time to collect contributions for the 19th edition of the


 Haskell Communities & Activities Report
   http://www.haskell.org/communities/

  Submission deadline: 1 November 2010

  (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
May 2010 edition -- you will find interesting topics 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/11-2010/template.tex

There is also a LaTeX style file at

 http://haskell.org/communities/11-2010/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 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. If you have several entries
to submit, it helps if you send them in separate emails.

Q: How much should I write?

A: Authors are asked to limit entries to about one column of text. This
corresponds to approximately one page, or 40 lines of text, with the
above style and template.

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 length of an entry!
The report aims for being as complete as possible, so please consider
writing an entry, even if it is only a few lines long.

Q: Which topics are relevant?

A: All topics which are related to Haskell in some way are relevant. We
usually had reports from users of Haskell (private, academic, or
commercial), from authors or contributors to projects related to
Haskell, from people working on the Haskell language, libraries, on
language extensions or variants. We also like reports about
distributions of Haskell software, Haskell infrastructure, books and
tutorials on Haskell. Reports on past and upcoming events related to
Haskell are also relevant. Finally, there might be new topics we do not
even think about. As a rule of thumb: if in doubt, then it probably is
relevant and has a place in the HCAR. You can also ask the editor.

Q: Is unfinished work relevant? Are ideas for projects relevant?

A: Yes! You can use the HCAR to talk about projects you are currently
working on. You can use it to look for other developers that might help
you. You can use it to write "wishlist" items for libraries and
language features you would like to see implemented.

Q: If I do not update my entry, but want to keep it in the report, what
should I do?

A: Tell the editor that there are no changes. The old entry will
typically be reused in this case, but it might be dropped if it is older
than a year, to give more room and more attention to projects that
change a lot. Do not resend complete entries if you have not changed them.

___

Re: [Haskell-cafe] Re: A question regarding cmdargs package

[Ivan Lazar Miljenovic]

On 12 October 2010 16:32, Magnus Therning  wrote:
>
> This makes me curious.  What's the use case where you want to allow the user
> to pass arguments on the command line, but you don't want that user to
> be able
> to use '--help' to find out what arguments may be passed?

When you don't want to bother defining the help options/descriptions? :p

(alternatively, you may wish to provide a more full-featured version
like what darcs does by using a pager)

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

Re: [Haskell-cafe] Re: A question regarding cmdargs package

[Magnus Therning]

On 11/10/10 22:04, Neil Mitchell wrote:
> Hi Ben,
>
 How can I disable the standard arguments 'help' and 'version'?
>
> In general I suggest you email the author of the cmdargs package
> directly, as well as cc'ing the mailing list (otherwise the author
> might miss this message, as I did!)
>
> In CmdArgs there is currently no way to suppress either --help or
> --version, but I am currently reviewing a patch (from you!) and expect
> that the next version will have both these features. The hard part is
> making sure the defaults match what people expect and that the options
> to modify the behaviour are discoverable and natural, but I'm sure
> I'll find something.

This makes me curious.  What's the use case where you want to allow the user
to pass arguments on the command line, but you don't want that user to
be able
to use '--help' to find out what arguments may be passed?

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org   Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe



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

Re: [Haskell-cafe] Re: A question regarding cmdargs package

[Neil Mitchell]

Hi Ben,

>>> How can I disable the standard arguments 'help' and 'version'?

In general I suggest you email the author of the cmdargs package
directly, as well as cc'ing the mailing list (otherwise the author
might miss this message, as I did!)

In CmdArgs there is currently no way to suppress either --help or
--version, but I am currently reviewing a patch (from you!) and expect
that the next version will have both these features. The hard part is
making sure the defaults match what people expect and that the options
to modify the behaviour are discoverable and natural, but I'm sure
I'll find something.

Thanks, Neil


>>
>> If you're not fully committed to the cmdargs package, you might try my
>> package 'console-program' instead
>> . It does not have
>> built-in "--help" or "--version" functionality. (There is a function
>> 'showUsage' that takes the description of the command/option structure
>> of your program, and prints "--help" style usage information, but you
>> use this at your own discretion.)
>
> Thanks, looks good. I will certainly try it out.
>
> Cheers
> Ben
>
> ___
> 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: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Joachim Breitner]

Hi,

Am Montag, den 11.10.2010, 21:29 +0200 schrieb Henning Thielemann:
> Gregory Crosswhite schrieb:
> > In conclusion, while I greatly appreciate you taking the time to explain
> > your reasoning, it still looks to me like there is nothing you have
> > gained by using arrows except adding extra unnecessary complexity in
> > your library.
> 
> As a pragmatic question: Would it be possible to split hxt even further
> into hxt (core) and hxt-arrow, and resurrect hxt-filter? This way people
> could choose the way they like to process XML. Or is it too tedious to
> maintain both hxt-arrow and hxt-filter? Is it possible to implement one
> interface in terms of the other one? It seems that the filter interface
> is the more general one, such that the arrow interface may be
> implemented in terms of filters.

without having something to add about arrows to the discussion, a little
side note from your distribution package maintainer: Before you split up
stuff even more into little packages, consider keeping one package but
offering different modules If it is just about offering alternative APIs
(and not really avoiding additional dependencies), this should be
sufficient and is less work for us.

Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
  mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
  JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/
  Debian Developer: nome...@debian.org


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Henning Thielemann]

Gregory Crosswhite schrieb:

> In conclusion, while I greatly appreciate you taking the time to explain
> your reasoning, it still looks to me like there is nothing you have
> gained by using arrows except adding extra unnecessary complexity in
> your library.

As a pragmatic question: Would it be possible to split hxt even further
into hxt (core) and hxt-arrow, and resurrect hxt-filter? This way people
could choose the way they like to process XML. Or is it too tedious to
maintain both hxt-arrow and hxt-filter? Is it possible to implement one
interface in terms of the other one? It seems that the filter interface
is the more general one, such that the arrow interface may be
implemented in terms of filters.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: RealFrac methods for Double and Float

[Daniel Fischer]

On Monday 11 October 2010 04:44:24, Antoine Latter wrote:

> I have results from my Intel-based MacBook, 64-bits, GHC 7 rc.

>
> Results from ncgFloat:
>
> Relations for properFraction:
>   Prelude  1.00
>   C via Integer0.333999
>   Hs via Integer   0.499852
>   C Int4.417461
>   Hs Int   4.558648

Puzzle solved. I have run the benchmarks with the latest HEAD and got 
broadly similar results.

GHC's new code generator does some incredible stuff with the code for 
Float's RealFrac instance, properFraction has become about _seven times_ 
faster, floor and ceiling about _thirteen times_ and round about _10.5 
times_ (values for my box, the exact numbers will differ, but the tendency 
will be the same).

Just Wow!

My code for properFraction :: Float -> (Integer, Float) has become 1.7 
times slower when calling out to C, everything else has either changed 
hardly at all or become slightly faster (5-10%).

The overall result is that for Float, in the general case, the current 
implementation is faster and overall the speedups are less impressive than 
they were for 6.12.

So I'll have to re-learn what GHC does with which kind of code.

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

Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Gregory Crosswhite]

 Uwe,

Thank you for your reply.

On 10/11/10 6:20 AM, Uwe Schmidt wrote:

I thing, this is not a question of functionality, it's a question of style.
Of course everything in hxt could have been done with monads,
but does this also mean: Everything must have been done with monads?

No, but there is no point in using a formalism that adds complexity 
without adding functionality.  Arrows are more awkward to use than 
monads because they were intentionally designed to be less powerful than 
monads in order to cover situations in which one could not use a monad.  
When your problem is solved by a monad there is no point in using arrows 
since an arrow require you to jump through extra hoops to accomplish the 
same goal.

Arrows are a generalisation of functions, so if you know all about working
with functions you know (almost) all about working with arrows.
When generalizing a pure algorithm, something like "f3 . f2 . f1",
or in Unix pipe style "f1>>>  f2>>>  f3", you don't have to rewrite
the code, you just generalize function composition.


Yes, but the >=> operator lets you do the same thing with monads, and in 
fact I use it all the time to do point-free programming with monads, so 
this isn't at all an advantage that arrows have over monads.


When constructing code, it is of course sometimes simpler to start with a
point wise version and then refactor and rewrite it into a more compact point
free version. The problem with arrows seems, that the arrow style forces to
start with the point free style. And that may be the main hurdle in mind.

No, that is not at all the problem with arrows.  The problem with arrows 
is that they are more restrictive than monads in two respects.  First, 
unlike monads, in general they do not let you perform an arbitrary 
action in response to an input.  Second, they place restrictions on how 
you define the input arguments of the arrow because you can't feed the 
output of one arrow into to input of the next unless said input is 
captured in the arrows type.


To be more concrete about my second point, suppose you have some monadic 
action


f :: a -> b -> m c

How would you structure this same action as an arrow?  One thing that 
you could do is take one of the arguments and turn it into the input of 
the arrow:


 f' :: a -> Arrow b c

But now you can't feed the output of an arrow into the first argument.  
Alternatively, you could pack both arguments into the input of the arrow:


f'' :: Arrow (a,b) c

Great, but now you have made it more awkward to use f'' because you have 
to always pack the arguments into a tuple, so that for example if one of 
the arguments is a constant then you can no longer easily use currying.  
The advantage of f over both alternatives is that you don't have to 
waste any of your time fitting multiple input arguments into the input 
type of an arrow.


In fact, if the first argument to f'' is usually a constant, then f'' is 
arguably more awkward to use in a point-free setting than f, because 
instead of being able to write


a >=> f 42 >=> b

You have to write something like

a >>> (const 42 &&& id) >>> f'' >>> b

Of course, if the first argument were *always* a constant then you could 
use f', but then you lose the ability to ever feed in the output of an 
arrow into the first argument.  So in short, arrows force you to make 
choices and trade-offs that never come up when using monads.


In conclusion, while I greatly appreciate you taking the time to explain 
your reasoning, it still looks to me like there is nothing you have 
gained by using arrows except adding extra unnecessary complexity in 
your library.


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

Re: [Haskell-cafe] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings

[John Van Enk]

Hooray for collaboration! I think this emphasizes the need for some sort of
social aspect on Hackage...

On Mon, Oct 11, 2010 at 10:58 AM, Justin Bailey  wrote:

> On Mon, Oct 11, 2010 at 7:56 AM, Christopher Done
>  wrote:
> > Hey that's cool, I hadn't seen that. This'll reduce my code
> > significantly, especially mkFieldWithName. Cheers!
> >
>
> I'm not sure if it supports the "parameterization" of records that you
> detailed in your post - let me know how it works for you. Patches
> always welcome as well :)
>
> Justin
> ___
> 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] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings

[Justin Bailey]

On Mon, Oct 11, 2010 at 7:56 AM, Christopher Done
 wrote:
> Hey that's cool, I hadn't seen that. This'll reduce my code
> significantly, especially mkFieldWithName. Cheers!
>

I'm not sure if it supports the "parameterization" of records that you
detailed in your post - let me know how it works for you. Patches
always welcome as well :)

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

Re: [Haskell-cafe] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings

[Christopher Done]

On 11 October 2010 16:45, Justin Bailey  wrote:
> No immediate plans but thanks for pointing that out - I hadn't seen it
> yet. Similar functionality exists in the haskelldb-th package, without
> the special type operators.

Hey that's cool, I hadn't seen that. This'll reduce my code
significantly, especially mkFieldWithName. Cheers!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings

[Justin Bailey]

No immediate plans but thanks for pointing that out - I hadn't seen it
yet. Similar functionality exists in the haskelldb-th package, without
the special type operators.

On Fri, Oct 8, 2010 at 5:19 PM, Bas van Dijk  wrote:
> Great work!
>
> I think I'm going to use it.
>
> Any plan on packaging up Christopher Done's HaskellDB's type operators:
>
> http://chrisdone.com/posts/2010-10-07-haskelldb-and-typeoperator-madness.html
>
> Which allows you to write something like:
>
> type PersonTable = Table :$: Expr
>   :%: Id    ::: Integer
>   :+: Age   ::: Integer
>   :+: Email ::: String
>   :+: Blurb ::: Maybe String
>   :+: End
>
> Regards,
>
> Bas
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Michael Snoyman]

On Mon, Oct 11, 2010 at 2:44 PM, Magnus Therning  wrote:
> On Mon, Oct 11, 2010 at 13:14, John Lato  wrote:
>>> From: Michael Snoyman 
>>>
>>> Also, now 10 random profiles will be displayed on the homepage. Only
>>> "verified users" will be displayed here. I'm also considering adding a
>>> new status as well: real picture, so that only people with real images
>>> (not cartoons, not identicons) can show up on the homepage. I think
>>> this might give a more professional feel. Thoughts?
>>
>> I agree that it would be nice to use only real pictures, however I wouldn't
>> want to leave out those who choose not to use any image at all.
>> What about a site policy that user images must be real pictures (if they
>> exist), and violations can be flagged/blocked?  Although, I don't know how
>> this would interact with using OpenID, which appears to be most of the users
>> currently displaying an identicon.
>
> I think it would be wrong to have haskellers.com impose restrictions
> on what image I put on gravatar.  My image on gravatar pops up in
> numerous other sites (I believe stackoverflow, ohloh, flickr, etc) and
> I'm not necessarily happy with putting my photo everywhere, even
> though I'd be fine with putting it on haskellers.com.
>
> So, instead I'd like to see the use of gravatar become optional.  Then
> if haskellers.org could require a photo, and I could simply choose not
> to get my cartoon image from gravatar.
>
> An obvious extension would be to allow me to get the image from other
> sources in the future, maybe an option to grab a picture out of an
> album on Facebook, or Flickr?

So firstly, just to clarify, I was never recommending we make real
photos a requirement to have an account on Haskellers. I was simply
talking about the 10 random profiles that get shown on the homepage: I
think it gives a more professional feel to the site if we see 10 "real
people" and not Bart Simpson. That was my question.

Now, the idea of using something besides gravatar is a fair point. I
know personally I *like* it when sites use gravatar, as it's one less
site I have to upload my image to. Otherwise, I need to search around
for my preferred profile image, crop it to whatever that site wants,
hope they'll scale it nicely, etc. From the site maintainer
standpoint, gravatar also means there's less moving parts on
Haskellers, and it decreases our bandwidth significantly, which is
definitely something to consider.

I'll definitely put some thought into providing an alternative to
gravatar. In the meanwhile, an option you have is to add a second
gravatar email address. This works especially well with Gmail
accounts, where you can just use a + sign (eg,
michael+haskell...@snoyman.com). I'm not saying this is ideal, but if
you want to have your real photo up, it will work today.

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

Re: [Haskell-cafe] Static computation/inlining

[Steve Schafer]

On Sun, 10 Oct 2010 18:51:59 -0700, Alexander Solla 
wrote:

>Although the list isn't huge, I would still rather get rid of the
>O(2*n) operation of turning it into maps at run-time.

I usually handle this as follows:

1) I create my data file in some human-friendly format (such as your
list of tuples), so that I can easily edit it later, as required.

2) I write a program, a sort of preprocessor, that (a) loads the data
from the human-friendly format into a processing-friendly structure, and
then (b) serializes that structure into a file that's efficient to load
at run time. (So, for example, lookups from the name of a country to its
ISO codes can be handled via a Patricia structure; a Patricia structure
is tedious to construct, but once constructed, is easy to serialize and
de-serialize.)

3) The file containing the serialized structure is then linked into the
rest of the "real" program as a source unit, where the serialized
structure is represented as a constant (usually a string, but sometimes
an array of numbers, etc.).

If your build environment has a reasonable make-like tool, then the
whole process is pretty automatic; you just modify the human-friendly
file as often as you want, and the preprocessor is invoked
automatically, as needed.

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

Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Uwe Schmidt]

Hi Gregory,

>   Could you explain to me why HXT uses arrows?  I have never been able
> to figure out what advantage this gives your library over monads.  Since
> your arrows in practice implement ArrowApply, they are really just
> monads anyway, so it seems to me that using arrows instead of monads
> only serves to add complexity to the library without adding any
> benefit.  Furthermore, by using arrows instead of monads people cannot
> use the many standard monad libraries out there, but have to instead
> write their own generalizations of them to arrows.
>
> Is there some benefit that your library gets out of using arrows that I
> missed which makes these costs worth it?

Hi Heinrich,

> I have the same question.
>
> It looks like the arrows in HXT are typed version of  CFilter  from
>
> Malcolm Wallace, Colin Runciman.
> Haskell and XML: Generic Combinators or Type-Based Translation?
> http://www.haskell.org/HaXml/icfp99.html
>
> but it appears to me that representing them as
>
> type Filter a b = a -> [b]
>
> allows the use of the list monad, which would highlight the similarity
> between list comprehensions and working with XML trees.

I thing, this is not a question of functionality, it's a question of style.
Of course everything in hxt could have been done with monads,
but does this also mean: Everything must have been done with monads?

We all have learned the elegant style of point free programming as
described in IFPH and Richard Birds new book gives a lot
more valuable examples of this.
When these elegant algorithms have to be generalized, e.g. to do
some IO, we have to rewrite the whole algorithms in a monadic style.
I don't like this.

Arrows are a generalisation of functions, so if you know all about working 
with functions you know (almost) all about working with arrows.
When generalizing a pure algorithm, something like "f3 . f2 . f1",
or in Unix pipe style "f1 >>> f2 >>> f3", you don't have to rewrite
the code, you just generalize function composition.
 
When constructing code, it is of course sometimes simpler to start with a 
point wise version and then refactor and rewrite it into a more compact point 
free version. The problem with arrows seems, that the arrow style forces to 
start with the point free style. And that may be the main hurdle in mind.

What we should have done in hxt, is to combine the arrows with arbitrary 
monads, at the moment the monadic arrows work with a combination of a
state and IO. The list gives us the "nondeterminism" and the exception (empty 
list). You can do a lot of things with this, but it can be generalized. And 
perhaps we'll do this in the future.

I hope this shows a bit of the motivation for taking the arrow approach,

  Uwe

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

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Magnus Therning]

On Mon, Oct 11, 2010 at 13:14, John Lato  wrote:
>> From: Michael Snoyman 
>>
>> Also, now 10 random profiles will be displayed on the homepage. Only
>> "verified users" will be displayed here. I'm also considering adding a
>> new status as well: real picture, so that only people with real images
>> (not cartoons, not identicons) can show up on the homepage. I think
>> this might give a more professional feel. Thoughts?
>
> I agree that it would be nice to use only real pictures, however I wouldn't
> want to leave out those who choose not to use any image at all.
> What about a site policy that user images must be real pictures (if they
> exist), and violations can be flagged/blocked?  Although, I don't know how
> this would interact with using OpenID, which appears to be most of the users
> currently displaying an identicon.

I think it would be wrong to have haskellers.com impose restrictions
on what image I put on gravatar.  My image on gravatar pops up in
numerous other sites (I believe stackoverflow, ohloh, flickr, etc) and
I'm not necessarily happy with putting my photo everywhere, even
though I'd be fine with putting it on haskellers.com.

So, instead I'd like to see the use of gravatar become optional.  Then
if haskellers.org could require a photo, and I could simply choose not
to get my cartoon image from gravatar.

An obvious extension would be to allow me to get the image from other
sources in the future, maybe an option to grab a picture out of an
album on Facebook, or Flickr?

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org          Jabber: magnus＠therning．org
http://therning.org/magnus         identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Uwe Schmidt]

Hello Henning,

> hxt-filter does not seem to be updated to hxt-9.0. How about providing
> hxt-filter with DEPRECATED pragmas for the functions that tell me how to
> rewrite functions from hxt-filter to arrows? Or is there another guide
> about how to move from hxt-filter to arrows?

Sorry, but there is no complete guide for rewriting filter code
into code working with arrows because of lack of time. Besides
developing and documenting hxt, there are a few other things,
that have to be done.

It's rather easy to convert to the arrow style.
All the functionality of hxt-filter is available in hxt.
Most of the names and operators remain as they are.
Declare

type XmlFilter = LA XmlTree XmlTree

That's the equivalent arrow type.
When evaluating a filter expression, use

runLA filter input

When switching to the arrow style, some of the operators
had to be renamed to the standard arrow operators,
e.g. (.>) to (>>>) and (+++) ==> (<+>)

For the monadic filters, mainly used for filters with IO
use the Type "IOSArrow XmlTree XmlTree" and
start a computation with runX, as described in the
examples of the wiki page about hxt:
http://www.haskell.org/haskellwiki/HXT#copyXML

Just compile your sources with these changes, and use
the Haskell compiler for finding ALL points, where you have
to modify or rename something.
If the code compiles, it will run.

Please trust in strong typing,

  Uwe

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

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Roman Cheplyaka]

On Mon, 11 Oct 2010 13:14:21 +0100, John Lato  wrote:
>>
>> From: Michael Snoyman 
>>
>> Also, now 10 random profiles will be displayed on the homepage. Only
>> "verified users" will be displayed here. I'm also considering adding a
>> new status as well: real picture, so that only people with real images
>> (not cartoons, not identicons) can show up on the homepage. I think
>> this might give a more professional feel. Thoughts?
> 
> 
> I agree that it would be nice to use only real pictures, however I
wouldn't
> want to leave out those who choose not to use any image at all.
> 
> What about a site policy that user images must be real pictures (if they
> exist), and violations can be flagged/blocked?  Although, I don't know
how
> this would interact with using OpenID, which appears to be most of the
> users
> currently displaying an identicon.

This is Gravatar's issue, which has little to do with OpenID, as far as I
understand.

-- 
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[John Lato]

>
> From: Michael Snoyman 
>
> Also, now 10 random profiles will be displayed on the homepage. Only
> "verified users" will be displayed here. I'm also considering adding a
> new status as well: real picture, so that only people with real images
> (not cartoons, not identicons) can show up on the homepage. I think
> this might give a more professional feel. Thoughts?


I agree that it would be nice to use only real pictures, however I wouldn't
want to leave out those who choose not to use any image at all.

What about a site policy that user images must be real pictures (if they
exist), and violations can be flagged/blocked?  Although, I don't know how
this would interact with using OpenID, which appears to be most of the users
currently displaying an identicon.

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

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Roman Cheplyaka]

On Mon, 11 Oct 2010 13:09:00 +0200, Vo Minh Thu  wrote:
> 2010/10/11 Roman Cheplyaka :
>> On Mon, 11 Oct 2010 11:54:12 +0100, Magnus Therning

>> wrote:
>>> On Mon, Oct 11, 2010 at 08:37, Michael Snoyman 
>> wrote:
>>> [...]
 Also, now 10 random profiles will be displayed on the homepage. Only
 "verified users" will be displayed here. I'm also considering adding a
 new status as well: real picture, so that only people with real images
 (not cartoons, not identicons) can show up on the homepage. I think
 this might give a more professional feel. Thoughts?
>>>
>>> I'd be weary of making that a requirement, there are good reasons for
>>> not putting your picture on the web, just like there are good reasons
>>> to not use your real name :-)
>>
>> ... just like there are good reasons not to publish yourself in a public
>> catalogue (such as haskellers.com) at all.
>>
>> I have nothing against anonymity. I voted against requirement of real
>> names
>> on hackage.
>>
>> But in this particular case, the whole point to be in the listing is to
>> present yourself. So I find the above proposal very reasonable.
> 
> Hi,
> 
> In the belgian law, an employer can (of course) request a faithful
> resume, but cannot request the resume to contain a picture of you.
> This is a clear example where you wish to advertise yourself, but not
> necessarily with a picture. Anyway, I don't think it is difficult to
> imagine situations where one doesn't wish to show a picture of his/her
> face.

Agree. But then there should be no picture at all for a given person.
As Michael said -- no cartoons, no identicons.

-- 
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Vo Minh Thu]

2010/10/11 Roman Cheplyaka :
> On Mon, 11 Oct 2010 11:54:12 +0100, Magnus Therning 
> wrote:
>> On Mon, Oct 11, 2010 at 08:37, Michael Snoyman 
> wrote:
>> [...]
>>> Also, now 10 random profiles will be displayed on the homepage. Only
>>> "verified users" will be displayed here. I'm also considering adding a
>>> new status as well: real picture, so that only people with real images
>>> (not cartoons, not identicons) can show up on the homepage. I think
>>> this might give a more professional feel. Thoughts?
>>
>> I'd be weary of making that a requirement, there are good reasons for
>> not putting your picture on the web, just like there are good reasons
>> to not use your real name :-)
>
> ... just like there are good reasons not to publish yourself in a public
> catalogue (such as haskellers.com) at all.
>
> I have nothing against anonymity. I voted against requirement of real names
> on hackage.
>
> But in this particular case, the whole point to be in the listing is to
> present yourself. So I find the above proposal very reasonable.

Hi,

In the belgian law, an employer can (of course) request a faithful
resume, but cannot request the resume to contain a picture of you.
This is a clear example where you wish to advertise yourself, but not
necessarily with a picture. Anyway, I don't think it is difficult to
imagine situations where one doesn't wish to show a picture of his/her
face.

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

Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

[Magnus Therning]

On Mon, Oct 11, 2010 at 09:41, Brandon Moore  wrote:
>
> While I can see your point about potentially introducing new security holes,
> and producing much less trusted code, I feel having tidy, pure libraries
> that we can all integrate into our Haskell is a benefit that far outweighs
> this.  Especially when we have nice things like the type system, which can
> be used to alleviate many of the security worries.
>
> I agree in general, for code like servers and file formats, but I worry in
> particular about cryptographic primitives. Some side channel attacks seem to
> call for a very low-level language, to make it easier to verify that e.g.
> execution time and the memory access pattern does not depend on the key.

I personally think we have to draw the line somewhere regarding what
we care about when it comes to security.  (Provable) correctness,
maintainability through well-structured code are things we are more
likely to gain through using high-level languages like Haskell.  That
is actually a lot of security bundled up in those things.  What we
lose is low-level control, which would be required to thwart
side-channel attacks.  On the other hand, I'm not convinced openssl or
gnutls deal with side-channel attacks very effectively either.

In any case, there is nothing that says we must have only *one* SSL
library, based on this discussion there seems to be people in the
community who still would prefer a binding to openssl/gnutls.

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org          Jabber: magnus＠therning．org
http://therning.org/magnus         identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Roman Cheplyaka]

On Mon, 11 Oct 2010 11:54:12 +0100, Magnus Therning 
wrote:
> On Mon, Oct 11, 2010 at 08:37, Michael Snoyman 
wrote:
> [...]
>> Also, now 10 random profiles will be displayed on the homepage. Only
>> "verified users" will be displayed here. I'm also considering adding a
>> new status as well: real picture, so that only people with real images
>> (not cartoons, not identicons) can show up on the homepage. I think
>> this might give a more professional feel. Thoughts?
> 
> I'd be weary of making that a requirement, there are good reasons for
> not putting your picture on the web, just like there are good reasons
> to not use your real name :-)

... just like there are good reasons not to publish yourself in a public
catalogue (such as haskellers.com) at all.

I have nothing against anonymity. I voted against requirement of real names
on hackage.

But in this particular case, the whole point to be in the listing is to
present yourself. So I find the above proposal very reasonable.

-- 
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Magnus Therning]

On Mon, Oct 11, 2010 at 08:37, Michael Snoyman  wrote:
[...]
> Also, now 10 random profiles will be displayed on the homepage. Only
> "verified users" will be displayed here. I'm also considering adding a
> new status as well: real picture, so that only people with real images
> (not cartoons, not identicons) can show up on the homepage. I think
> this might give a more professional feel. Thoughts?

I'd be weary of making that a requirement, there are good reasons for
not putting your picture on the web, just like there are good reasons
to not use your real name :-)

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org          Jabber: magnus＠therning．org
http://therning.org/magnus         identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Static computation/inlining

[Felipe Lessa]

On Sun, Oct 10, 2010 at 10:51 PM, Alexander Solla  wrote:
> Is there anyway to instruct GHC (and maybe other compilers) to compute these
> maps statically? Are GHC and the other compilers smart enough to do it
> automatically? Although the list isn't huge, I would still rather get rid of
> the O(2*n) operation of turning it into maps at run-time. (Especially since
> some later list encodings like these might be enormous) What should I be
> looking into?

You may use Template Haskell and forget about the 'Data.Map's entirely =).

I've attached a proof-of-concept code that turns

  list :: [(a,b)]
  list = [(x1,y1), (x2, y2), ..., (xn, yn)]

into two functions (you can choose the names)

  fromAtoB :: a -> b
  fromAtoB x1 = y1
  fromAtoB x2 = y2
  ...
  fromAtoB xn = yn

  fromBtoA :: b -> a
  fromBtoA y1 = x1
  ...
  fromBtoA yn = xn

but with the arguments tranformed to patterns.

Compiling a test module:

$ ghc -ddump-splices -c ModuleWithFunctions.hs
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.1 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
ModuleWithFunctions.hs:1:0:
ModuleWithFunctions.hs:1:0: Splicing declarations
bimap
  "map_country_to_country_code"
  "map_country_code_to_country"
  countries_and_iso_country_codes
  ==>
ModuleWithFunctions.hs:8:2-98
map_country_to_country_code Afghanistan
  = ISOCountryCode AF AFG (NC 4)
map_country_to_country_code AlandIslands
  = ISOCountryCode AX ALA (NC 248)
map_country_to_country_code Albania = ISOCountryCode AL ALB (NC 8)
map_country_to_country_code Zimbabwe
  = ISOCountryCode ZW ZWE (NC 716)
map_country_code_to_country ISOCountryCode AF AFG NC 4
  = Afghanistan
map_country_code_to_country ISOCountryCode AX ALA NC 248
  = AlandIslands
map_country_code_to_country ISOCountryCode AL ALB NC 8 = Albania
map_country_code_to_country ISOCountryCode ZW ZWE NC 716 = Zimbabwe


So two functions were spliced into your code with explicit pattern
matches.  I don't know how efficient is the code that GHC generates
for functions with many patterns.  Now, testing them:

$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
:Prelude> :l Module
[4 of 4] Compiling Module   ( Module.hs, interpreted )
Ok, modules loaded: Module, ModuleWithData, ModuleWithFunctions, Template.
*Module> :bro Module
data Country = Afghanistan | AlandIslands | Albania | Zimbabwe
data ISOCountryCode = ISOCountryCode TwoCode ThreeCode NumCode
data NumCode = NC Int
data ThreeCode = AFG | ALA | ALB | ZWE
data TwoCode = AF | AX | AL | ZW
countries_and_iso_country_codes :: [(Country, ISOCountryCode)]
isoNumericCode :: Int -> NumCode
map_country_code_to_country :: ISOCountryCode -> Country
map_country_to_country_code :: Country -> ISOCountryCode
*Module> map_country_to_country_code Albania
Loading package array-0.3.0.1 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
ISOCountryCode AL ALB (NC 8)
*Module> map_country_code_to_country $ ISOCountryCode AL ALB (NC 8)
Albania

Cheers! =)

-- 
Felipe.
{-# LANGUAGE DeriveDataTypeable #-}

module ModuleWithData where

import Data.Data
import Data.Typeable

data Country = Afghanistan | AlandIslands | Albania | Zimbabwe
   deriving (Data, Eq, Ord, Show, Typeable)

data ISOCountryCode = ISOCountryCode TwoCode ThreeCode NumCode
  deriving (Data, Eq, Ord, Show, Typeable)

data TwoCode = AF | AX | AL | ZW
   deriving (Data, Eq, Ord, Show, Typeable)

data ThreeCode = AFG | ALA | ALB | ZWE
 deriving (Data, Eq, Ord, Show, Typeable)

data NumCode = NC Int
   deriving (Data, Eq, Ord, Show, Typeable)

isoNumericCode :: Int -> NumCode
isoNumericCode = NC

countries_and_iso_country_codes :: [ (Country, ISOCountryCode) ]
countries_and_iso_country_codes =
[ (Afghanistan,  ISOCountryCode AF AFG (isoNumericCode 004))
, (AlandIslands, ISOCountryCode AX ALA (isoNumericCode 248))
, (Albania,  ISOCountryCode AL ALB (isoNumericCode 008))
, (Zimbabwe, ISOCountryCode ZW ZWE (isoNumericCode 716))
]
{-# LANGUAGE TemplateHaskell #-}

module M

Re: [Haskell-cafe] pointers for EDSL design

[Dominique Devriese]

John, Oleg,

2010/10/9  :
>> So here's a very simple expression:
>>
>> t1 = let v = sigGen (cnst 1) in outs v v
>>
>> which is what led to my question.  I'm binding the sigGen to 'v' to
>> introduce sharing at the meta-level.  Would it be better to introduce
>> support for this in the dsl?
>
> Often this is not a question of preference but that of
> necessity. Sharing at the meta-level may help the generator, but it
> does _not_ translate into the sharing at the object level. In the
> generated code, the code for 'sigGen (cnst 1)' shall be
> duplicated. It could be that two csound blocks must share the same
> signal source, to receive samples in parallel. Meta-level sharing
> (Haskell's let) would not do. We need a construct for an object-level
> let, for example
>
>  t1 = let_ (SigGen (cnst 1)) (\v -> outs v v)

An alternative approach to model sharing at the object level is the
technique I use for modelling context-free grammars in my PADL 2011
paper "Explicitly Recursive Grammar Combinators" [1] (just got
acceptance notification this morning!). The idea is basically that you make the
sharing in the object-level expression explicit by modelling all
your terms as the results of one big recursive function and then
opening up the recursion. Using ideas from the Multirec generic
programming library and some recent Haskell type system extensions
(most importantly GADTs and type families), you can do this in a
well-typed way for sets of mutually recursive object-level
expressions.

In this case, you would get something like the following (written
without any understanding of your problem domain, so sorry if I
interpret stuff wrong here ;) ):

data I1
data T1
data CircuitNode ix where
   I1 :: CircuitNode I1
   T1 :: CircuitNode T1

myCircuit self I1 = sigGen (cnst 1)
myCircuit self T1 = outs (self I1) (self I1)

With a type class such as RecProductionRule in my paper, you can then
even get rid of the self argument and get something like this:

myCircuit I1 = sigGen (cnst 1)
myCircuit T1 = outs (ref I1) (ref I1)

The main advantage is that this approach extends to circuits with
mutually recursive nodes, but contrary to simple meta-level sharing,
allows you to observe and manipulate the recursive structure of the
circuit. Oh, and it stays properly typed. More info in the paper and
the accompanying technical report [2].

cheers
Dominique

Footnotes:
[1]  
http://people.cs.kuleuven.be/~dominique.devriese/permanent/cfgc-submitted-PADL.pdf
[2]  http://www.cs.kuleuven.be/publicaties/rapporten/cw/CW594.abs.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] How to fix "undefined reference" error with getDataDir?

[Andy Stewart]

Hi all,

I have two package A and B, and B depend A.

I use below code snippets in package A:

--> code start <--
...
import Paths_manatee_ircclient
import System.FilePath
...
  dir <- getDataDir
  let imagePath imageName = dir  "icons"  (imageName ++ ".png")
...
--> code end   <--

Anyway, package A compile fine, but when i compile package B, i got
below error:

--> error start <--
Linking dist/build/manatee/manatee ...
/home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o):
 In function `s6sP_info':
(.text+0x3bea): undefined reference to 
`manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir3_closure'
/home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o):
 In function `s6sP_info':
(.text+0x3bf0): undefined reference to 
`manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir2_closure'
/home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o):
 In function `s6Uf_info':
(.text+0x560f): undefined reference to 
`__stginit_manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_'
/home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o):
 In function `r5Mp_closure':
(.data+0x9d8): undefined reference to 
`manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir3_closure'
/home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o):
 In function `r5Mp_closure':
(.data+0x9e0): undefined reference to 
`manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir2_closure'
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
manatee-0.0.1 failed during the building phase. The exception was:
ExitFailure 1
--> error end   <--

How to fix above error? 

Thanks!

  -- Andy
  

Below is .cabal file for package A:

--> A.cabal start <--
name:   manatee-ircclient
version:0.0.1
Cabal-Version:  >= 1.6
license:GPL-3
license-file:   LICENSE
copyright:  (c) 2009 ~ 2010 Andy Stewart
synopsis:   IRC client extension for Manatee.
description:manatee-ircclient is IRC client extension for Manatee 
(Haskell/Gtk+ Integrated Live Environment)
author: Andy Stewart
maintainer: Andy Stewart 
stability:  provisional
category:   Development, Other

tested-with:GHC==6.12.3
build-type: Simple
extra-source-files: Setup.lhs

data-dir: icons
data-files: angry.png
confused.png
crying.png
embarrassed.png
inlove.png
kiss.png
sleepy.png
sad.png
laugh.png
smile.png
surprised.png
tired.png
tongue.png
whistling.png
wink.png

Library
 build-depends: base >= 4 && < 5, manatee-core >= 0.0.1, dbus-client >= 0.3 
&& < 0.4, stm >= 2.1.2.0,
containers >= 0.3.0.0, gtk-serialized-event >= 0.11.0, gtk 
>= 0.11.0, 
text >= 0.7.1.0, bytestring >= 0.9.1.5,
dbus-core, template-haskell, gtksourceview2 >= 0.11.0, unix 
>= 2.4.0.0,
network, groom, fastirc >= 0.2.0, split >= 0.1.2, nano-md5 
>= 0.1.2, filepath,
regex-posix >= 0.94.1, array >= 0.3.0.0, GoogleTranslate >= 
0.0.3, utf8-string, mtl, Cabal
 exposed-modules:
   Manatee.Extension.IrcClient
   Manatee.Extension.IrcClient.Types
   Manatee.Extension.IrcClient.DBus
   Manatee.Extension.IrcClient.Daemon
   Manatee.Extension.IrcClient.HighlightNick
   Manatee.Extension.IrcClient.IrcBuffer
   Manatee.Extension.IrcClient.IrcView
   Manatee.Extension.IrcClient.Smile
 other-modules: 
 extensions:
 ghc-options: -O -fwarn-unused-matches -fwarn-unused-binds 
-fwarn-unused-imports -fwarn-overlapping-patterns -fwarn-duplicate-exports 
-threaded -fwarn-unrecognised-pragmas -fwarn-hi-shadowing 
 
Executable manatee-irc-daemon
 main-is: Main.hs

 ghc-options: -threaded 
--> A.cabal end   <--

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

[Haskell-cafe] Re: RealFrac methods for Double and Float

[Daniel Fischer]

On Monday 11 October 2010 04:44:24, Antoine Latter wrote:
> I have results from my Intel-based MacBook, 64-bits, GHC 7 rc. The
> quickchecks failed to run:
>
> QuickChecking Double
> properFraction/Int
> qcDouble: qcDouble.hs:(10,10)-(15,5): Missing field in record
> construction Test.QuickCheck.Test.chatty
>
> QuickChecking Float
> properFraction/Int
> qcFloat: qcFloat.hs:(10,10)-(15,5): Missing field in record
> construction Test.QuickCheck.Test.chatty
>
> This is with QuickCheck 2.3.0.2.

Oops, I didn't even notice that QC-2.3.* was out, let alone that they added 
a field to Args.
Sorry again.

>
> Take care,
> Antoine

Thanks for benchmarking.

Your numbers come as an unpleasant surprise.
The factors are generally lower than anywhere else I've so far got feedback 
from, but what's really disconcerting is that the Float -> Integer 
conversions are actually slower than the current, apparently.
I have no idea yet how that can be.

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

Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

[Vincent Hanquez]

On Mon, Oct 11, 2010 at 09:06:45AM +0100, Sittampalam, Ganesh wrote:
> While I agree with the potential benefits, I also worry that you will
> end up making something that is far less well tested in practice. For
> widely used and fairly low-level libraries like gnutls, openssl and
> zlib, I'm just skeptical that the benefits outweigh the risks and costs.
 
Hi Ganesh,

You're absolutely right in the fact there's risk involved. Cryptography
related things are hard to get right, I won't be denying it. However
I'm really not a big fan of the alternative.

Having to rely forever on blessed black boxes coded in low level languages,
doesn't sound appealing to me. There's the risk that cryptography becomes
even more voodoo magic by doing that. This is certainly true for TLS/SSL.
a lots of people have no idea how it works, what it does and doesn't do.

So hopefully having a clean haskell library will make more people interested,
in changing this black-box state; an even bigger hope, is to vulgarize
cryptography, instead of making it more opaque ;)

> Anyway, it's just a feeling. Please do prove me wrong :-)

I'll certainly try ;)

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

Re: [Haskell-cafe] Re: ANNOUNCE: tls, native TLS/SSL protocol implementation

[Vincent Hanquez]

On Sat, Oct 09, 2010 at 12:53:17PM +0100, Maciej Piechotka wrote:
> I don't think I quite follow. Could you explain?

sorry for beeing confusing. I meant something like a pure iteratee interface,
so that you get the marshalled data to send in a bytestring format, and then
you can decide yourself what to do with this bytestring (send it to a handle,
discard it, process it as the other side)

> Maybe serverStartTLS? 

ok, I'll think about it; I'm not thrilled by that though ;)

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

[Haskell-cafe] Re: pointers for EDSL design

[John Lato]

On Fri, Oct 8, 2010 at 10:29 PM,  wrote:

>
> John Lato wrote:
>
> > So here's a very simple expression:
> >
> > t1 = let v = sigGen (cnst 1) in outs v v
> >
> > which is what led to my question.  I'm binding the sigGen to 'v' to
> > introduce sharing at the meta-level.  Would it be better to introduce
> > support for this in the dsl?
>
> Often this is not a question of preference but that of
> necessity. Sharing at the meta-level may help the generator, but it
> does _not_ translate into the sharing at the object level. In the
> generated code, the code for 'sigGen (cnst 1)' shall be
> duplicated. It could be that two csound blocks must share the same
> signal source, to receive samples in parallel. Meta-level sharing
> (Haskell's let) would not do. We need a construct for an object-level
> let, for example
>

This was a problem, but I did arrive at a solution.  When my interpreter
evaluates an expression, it creates a named variable to store the result and
memoizes it.  Future evaluations of the expression with the same arguments
become a reference to the named variable.

This works well for functions.  However, there may be some operations that
should not be memoized.  These can be handled by simply having the
interpreter re-evaluate the expression.  I've found that including a
user-supplied label to control memoization creates consistency within the
embedded language, and thus a more natural programming style.

When targeting csound, the generated code is nearly exactly what I would
have written directly, except for auto-generated variable names.  I don't
yet know how feasible it will be for other interpreters though.

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

[Haskell-cafe] Re: Round benchmarks

[Daniel Fischer]

On Monday 11 October 2010 07:05:20 you wrote:
> Hi,
>
> These results seem different from the samples.

Thanks. The numbers are quite impressive.
Although the quotients (hence speedups) are generally much larger, the 
ranking doesn't differ much.

For round :: x -> Int, via C is a big win.
For round :: x -> Integer and properFraction :: Double -> (Integer, 
Double), going via C doesn't seem to make much difference on 64 bits, but 
they do on 32.
That's probably because a Double mantissa is a smallInteger on 64 bits.

Overall, your timings support going via C for round and
properFraction :: Double -> (Integer, Double).
In two cases, it makes not much difference on 64 bits but is a big gain on 
32, for round :: x -> Int, it's a big win on both.

>
> I was surprised that the "via Integer" results appear faster than the
> Int results.

No, the numbers are (Prelude time / new time), so the larger the number, 
the better.
Sorry for not making that clear in the README.

>
> Vivian

Cheers,
Daniel

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

Re: [Haskell-cafe] Re: Re-order type

[Ryan Ingram]

djinn[1] can derive some glue functions for you.

you tell it something like
> glue :: (x -> y -> z -> (b,(c,a)) -> (c -> a -> d) -> x -> y -> z -> d
and it tells you something like
> glue f g x y z = let (b,(c,a)) = f x y z in g c a
I changed the type of f slightly to avoid the trivial answer
> glue _ g a _ c = g c a

[1] http://hackage.haskell.org/package/djinn



2010/10/9 André Batista Martins :
>
> Might have not been clear, but i will try illustrate .
>
>
> f:: a-> b -> c -> (b,(c,a))
>
> f1 ::  c -> a -> d
>
>
> input type:
>    A   B   C
>  --
>    |    f  |
>    | _ |
>
> output   (B,(C,A))
>
>
>  C    A
>  --
>    |    f1    |
>    | _ |
>
> output D
>
> If i want compose   f  and f1, i need to do a correct input to f1 from the
> output of f.
> So i want one function to  convert the output of "f" to input off "f!".
> In this case,  we do  f1 fst (snd (t,(t1,t2)))  snd (snd (t,(t1,t2)))
> But i want do this automaticaly, for type of any two function. I search for
> the "glue".
>
> I don't have any concern about what the function does, i only have interess
> on input and output types.
>
>
> Cheers,
>  André
>
>
>
> No dia 9 de Outubro de 2010 22:38, André Batista Martins
>  escreveu:
>>
>> Hello,
>>  exists any algorithm  to determine how terms can be changed to safisty
>> the type of one function?
>>
>>
>> example:
>>
>> f:: a-> b -> c -> (b,c,a)
>>
>> f1 ::  c -> a -> d
>>
>> In my first function "f" i want assign  the output "c" and "a" for to
>> input of function "f1".
>> I searched for any solution, but i didn't find any anything.
>>
>> One clue i have found is "minimal edit distance algorithm" for 2 strings.
>> Perhaps if i convert de output type of "f" to one string, and de input of
>> "f1" to another string and then use this algorithm , i will get one "dirty"
>> solution...
>>
>> I'm open to any sugestion.
>
>
> ___
> 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] Re: Polyvariadic functions operating with a monoid

[Kevin Jardine]

It also appears that we need type families to reconstruct the original
Haskell list system using polyToMonoid.

instance (a ~ a') => Monoidable a [a'] where
toMonoid a = [a]

testList = putStrLn $ show $ polyToMonoid (mempty :: [a]) "a" "b" "c"

Given this instance of Monoidable, you can put any number of values
after
polyToMonoid (mempty :: [a])  as long as they are exactly the same
type.

In other words, this acts exactly like the usual Haskell list, going
back to my original point that polyToMonoid is a sort of generalised
list or "a function that takes a bunch of values that can be stuck
together in some way".

I am a bit surprised that the  (a ~ a') is needed, but Haskell will
not compile this code with the more usual

instance Monoidable a [a] where
toMonoid a = [a]

Kevin

On Oct 11, 9:54 am, Kevin Jardine  wrote:
> Hi Oleg,
>
> I've found that if I also add two other slightly scary sounding
> extensions: OverlappingInstances and IncoherentInstances, then I can
> eliminate the unwrap function *and* use your type families trick to
> avoid the outer type annotation.
>
> My latest code is here:
>
> {-# LANGUAGE TypeSynonymInstances, FlexibleInstances,
> MultiParamTypeClasses, TypeFamilies #-}
> {-# LANGUAGE OverlappingInstances, IncoherentInstances #-}
> module PolyTest where
>
> import Data.Monoid
>
> class Monoid m => Monoidable a m where
>     toMonoid :: a -> m
>
> squish :: Monoidable a m => m -> a -> m
> squish m a = (m `mappend` (toMonoid a))
>
> class Monoid m => PolyVariadic m r where
>     polyToMonoid :: m -> r
>
> instance (Monoid m', m' ~ m) => PolyVariadic m m' where
>     polyToMonoid acc = acc
>
> instance (Monoidable a m, PolyVariadic m r) => PolyVariadic m (a->r)
> where
>     polyToMonoid acc = \a -> polyToMonoid (squish acc a)
>
> Here are three examples. The resulting notation is short enough now
> that I am no longer tempted to use CPP.
>
> All you need to do is to specify the type for mempty. And even this
> can be skipped if you want to put in the specific mempty value
> (although I think that the type annotation is often better if slightly
> longer as it documents clearly what monoid the result is being mapped
> into).
>
> -- [String] example
> instance Show a => Monoidable a [String] where
>     toMonoid a = [show a]
>
> testStringList = putStrLn $ show $ polyToMonoid (mempty :: [String])
> True () (Just (5::Int))
>
> -- String example
> instance Show a => Monoidable a String where
>     toMonoid a = show a
>
> testString = putStrLn $ polyToMonoid (mempty :: String) True () (Just
> (5::Int))
>
> -- product example
>
> instance Monoid Double where
>     mappend = (*)
>     mempty = (1.0) :: Double
>
> instance Monoidable Int Double where
>     toMonoid = fromIntegral
>
> instance Monoidable Double Double where
>     toMonoid = id
>
> testProduct = putStrLn $ show $ polyToMonoid (mempty :: Double) (5 ::
> Int) (2.3 :: Double) (3 :: Int) (8 :: Int)
>
> main = do
>     testStringList
>     testString
>     testProduct
>
> $ runhaskell PolyTest.hs
> ["True","()","Just 5"]
> True()Just 5
> 276.0
>
> Kevin
>
> On Oct 11, 2:39 am, o...@okmij.org wrote:
>
> > Sorry, I'm still catching up. I'm replying to first few messages.
>
> > > instance Show a => Monoidable a [String] where
> > >     toMonoid a = [show a]
>
> > > main = putStrLn $ unwrap $ polyToMonoid [] True () (Just (5::Int))
> > > fails to compile.
>
> > The error message points to the first problem:
>
> > >     No instances for (Monoidable Bool [a],
> > >                       Monoidable () [a],
> > >                       ...
>
> > The presence of the type variable 'a' means that the type checker
> > doesn't know list of what elements you want (in other words, the
> > context is not specific enough to instantiate the type variable
> > a). Thus, we need to explicitly tell that we wish a list of strings:
>
> > > test3 = putStrLn $ unwrap $polyToMonoid ([]::[String]) True () (Just 
> > > (5::Int))
>
> > Now we get a different error, which points to the real problem this
> > time: the expression `unwrap ' appears as an argument to
> > putStrLn. That means that we are required to produce a String as a
> > monoid. Yet we specified ([]::[String]) as mempty, which is unsuitable
> > as mempty for the String monoid. If we desire the [String] monoid as
> > the result, we need to change the context. For example,
>
> > > test3 = mapM_ putStrLn $ unwrap $
> > >            polyToMonoid ([]::[String]) True () (Just (5::Int))
> > > Another example that also fails to compile (but I cannot see why):
> > > main = putStrLn $ show $ unwrap $ polyToMonoid (0::Int) (1::Int)
> > >         (2::Int) (3::Int)
> > > No instance for (PolyVariadic Int (WMonoid m))
> > >       arising from a use of `polyToMonoid'
>
> > The error message is informative, mentioning the type variable,
> > m. Whenever that happens, we know that we put a bounded polymorphic
> > expression in the context that is not specific enough. We need some
> > type annotations. 

Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

[Brandon Moore]

While I can see your point about potentially introducing new security holes, 
and producing much less trusted code, I feel having tidy, pure libraries that 
we can all integrate into our Haskell is a benefit that far outweighs this.  
Especially when we have nice things like the type system, which can be used to 
alleviate many of the security worries.

I agree in general, for code like servers and file formats, but I worry in 
particular about cryptographic primitives. Some side channel attacks seem to 
call for a very low-level language, to make it easier to verify that e.g. 
execution time and the memory access pattern does not depend on the key.


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

Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

[Thomas Davie]

> 
> While I agree with the potential benefits, I also worry that you will
> end up making something that is far less well tested in practice. For
> widely used and fairly low-level libraries like gnutls, openssl and
> zlib, I'm just skeptical that the benefits outweigh the risks and costs.
> 
> Anyway, it's just a feeling. Please do prove me wrong :-)

This certainly isn't a proof by a long shot, but my feeling on at least 
low-level libraries is exactly the reverse of this.

C libraries are usually designed to be extremely stateful (this certainly 
includes openssl), and because of that any Haskell wrapper for them ends up 
being heavily IO based.  The result of this is that any code that incorporates 
it ends up being trapped in an IO mess to do essentially pure (yes, I know the 
arguments about IO being pure, you know what I mean) things.  It's precisely 
these libraries that we need not just implemented in a "native" way, but 
designed in a pure, beautiful, simple way for Haskell.

While I can see your point about potentially introducing new security holes, 
and producing much less trusted code, I feel having tidy, pure libraries that 
we can all integrate into our Haskell is a benefit that far outweighs this.  
Especially when we have nice things like the type system, which can be used to 
alleviate many of the security worries.

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

RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

[Sittampalam, Ganesh]

Vincent Hanquez wrote:
> On Fri, Oct 08, 2010 at 12:54:48PM +0100, Sittampalam, Ganesh wrote:
>> What's the motivation for this?
> 
> Well, I wanted to have a tls/ssl module that integrate nicely with
> haskell. 
> until then the 2 solutions were:
> 
> - shelling out to curl: that's not great, usually works until you
> have an error, and then you're greeted with a curl command line
> error. the control is pretty poor, what if you want a fancy
> certificate control ? Also you have absolutely no server support in
> this case, this is client only.
> 
> - using either gnutls or openssl bindings: there's multiples reasons
> this is not great. 
> depending on huge C libraries (security wise, platform wise), massive
> usage of IO even in place where it shouldn't, low hacking potential
> (adding ciphers/hash, etc).  
> 
> Apart from that, we all know here why programming in haskell is
> better than doing the same thing in says, C or python. I think it
> apply even more when the focus of this is a secure library.  

While I agree with the potential benefits, I also worry that you will
end up making something that is far less well tested in practice. For
widely used and fairly low-level libraries like gnutls, openssl and
zlib, I'm just skeptical that the benefits outweigh the risks and costs.

Anyway, it's just a feeling. Please do prove me wrong :-)

Cheers,

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

[Haskell-cafe] Re: Polyvariadic functions operating with a monoid

[Kevin Jardine]

Hi Oleg,

I've found that if I also add two other slightly scary sounding
extensions: OverlappingInstances and IncoherentInstances, then I can
eliminate the unwrap function *and* use your type families trick to
avoid the outer type annotation.

My latest code is here:

{-# LANGUAGE TypeSynonymInstances, FlexibleInstances,
MultiParamTypeClasses, TypeFamilies #-}
{-# LANGUAGE OverlappingInstances, IncoherentInstances #-}
module PolyTest where

import Data.Monoid

class Monoid m => Monoidable a m where
toMonoid :: a -> m

squish :: Monoidable a m => m -> a -> m
squish m a = (m `mappend` (toMonoid a))

class Monoid m => PolyVariadic m r where
polyToMonoid :: m -> r

instance (Monoid m', m' ~ m) => PolyVariadic m m' where
polyToMonoid acc = acc

instance (Monoidable a m, PolyVariadic m r) => PolyVariadic m (a->r)
where
polyToMonoid acc = \a -> polyToMonoid (squish acc a)

Here are three examples. The resulting notation is short enough now
that I am no longer tempted to use CPP.

All you need to do is to specify the type for mempty. And even this
can be skipped if you want to put in the specific mempty value
(although I think that the type annotation is often better if slightly
longer as it documents clearly what monoid the result is being mapped
into).

-- [String] example
instance Show a => Monoidable a [String] where
toMonoid a = [show a]

testStringList = putStrLn $ show $ polyToMonoid (mempty :: [String])
True () (Just (5::Int))

-- String example
instance Show a => Monoidable a String where
toMonoid a = show a

testString = putStrLn $ polyToMonoid (mempty :: String) True () (Just
(5::Int))

-- product example

instance Monoid Double where
mappend = (*)
mempty = (1.0) :: Double

instance Monoidable Int Double where
toMonoid = fromIntegral

instance Monoidable Double Double where
toMonoid = id

testProduct = putStrLn $ show $ polyToMonoid (mempty :: Double) (5 ::
Int) (2.3 :: Double) (3 :: Int) (8 :: Int)

main = do
testStringList
testString
testProduct

$ runhaskell PolyTest.hs
["True","()","Just 5"]
True()Just 5
276.0

Kevin

On Oct 11, 2:39 am, o...@okmij.org wrote:
> Sorry, I'm still catching up. I'm replying to first few messages.
>
> > instance Show a => Monoidable a [String] where
> >     toMonoid a = [show a]
>
> > main = putStrLn $ unwrap $ polyToMonoid [] True () (Just (5::Int))
> > fails to compile.
>
> The error message points to the first problem:
>
> >     No instances for (Monoidable Bool [a],
> >                       Monoidable () [a],
> >                       ...
>
> The presence of the type variable 'a' means that the type checker
> doesn't know list of what elements you want (in other words, the
> context is not specific enough to instantiate the type variable
> a). Thus, we need to explicitly tell that we wish a list of strings:
>
> > test3 = putStrLn $ unwrap $polyToMonoid ([]::[String]) True () (Just 
> > (5::Int))
>
> Now we get a different error, which points to the real problem this
> time: the expression `unwrap ' appears as an argument to
> putStrLn. That means that we are required to produce a String as a
> monoid. Yet we specified ([]::[String]) as mempty, which is unsuitable
> as mempty for the String monoid. If we desire the [String] monoid as
> the result, we need to change the context. For example,
>
> > test3 = mapM_ putStrLn $ unwrap $
> >            polyToMonoid ([]::[String]) True () (Just (5::Int))
> > Another example that also fails to compile (but I cannot see why):
> > main = putStrLn $ show $ unwrap $ polyToMonoid (0::Int) (1::Int)
> >         (2::Int) (3::Int)
> > No instance for (PolyVariadic Int (WMonoid m))
> >       arising from a use of `polyToMonoid'
>
> The error message is informative, mentioning the type variable,
> m. Whenever that happens, we know that we put a bounded polymorphic
> expression in the context that is not specific enough. We need some
> type annotations. In our case, the function 'show' can show values of
> many types. The type checker does not know that we wish an Int monoid
> specifically. So, we have to specialize the show function:
>
> > test4 = putStrLn $ (show :: Int -> String) $
> >     unwrap $ polyToMonoid (0::Int) (1::Int) (2::Int) (3::Int)
>
> At this point one may wonder if this is all worth it. There are too
> many annotations. Fortunately, if you are not afraid of one more
> extension, the annotations can be avoided. Your example would be
> accepted as it was written, see test3 and test4 below.
>
>
>
> > {-# LANGUAGE TypeSynonymInstances #-}
> > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, TypeFamilies #-}
>
> > module M where
>
> > import Data.Monoid
>
> > newtype WMonoid m = WMonoid{unwrap :: m}
>
> > class Monoid m => Monoidable a m where
> >     toMonoid :: a -> m
>
> > class Monoid m => PolyVariadic m p where
> >     polyToMonoid :: m -> p
>
> > instance (Monoid m', m' ~ m) => PolyVariadic m (WMonoid m') where
> >     polyToMonoid acc = WMonoid acc
>
> > 

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Michael Snoyman]

On Mon, Oct 11, 2010 at 9:06 AM, Nicolas Pouillard
 wrote:
> On Mon, 11 Oct 2010 05:50:32 +0200, Michael Snoyman  
> wrote:
>> Sorry to everyone for not getting back so quickly, I kept getting
>> errors from postfix when I tried sending mail to the cafe. Hopefully
>> this one will go through. As I see it, two open issues are "flagging"
>> and "real Haskellers".
>>
>> Flagging: this was simply a mistake in terminology on my part. I've
>> replaced it with "Report this user." It should be used for either
>> inappropriate content, spam, or someone who's just clearly not part of
>> the community (eg, "Lol, I don't know Haskell, I had Cocoa Puffs for
>> breakfast"). I'm purposely being vague about this; if a user *thinks*
>> there's a problem, it shouldn't take an admin more than a few seconds
>> to investigate it.
>>
>> Now the more important question about real Haskellers: I think I
>> mentioned before implementing the feature that I was a little bit
>> nervous about doing so. The main reason I went ahead and did it anyway
>> was we were getting some... strange gravatars showing up on the
>> homepage. This problem was solved automatically when I added sorting
>> by years of experience (no one can object to Simon PJ and Lennart
>> being on the homepage of course), but the problem with that system is
>> *anyone* can just set their start year to 1990 and get homepage status
>> until an admin blocks him/her.
>>
>> So for the moment, real Haskeller is a minimal whitelisting system,
>> simply intended to prevent people from gaming the system. I've
>> probably chosen bad terminology, and by not explaining this upset a
>> lot of people, my apologies. The point here is not to make the real
>> Haskeller status exclusive, but just to give an extra level of
>> protection. If people really think this is a bad idea, we can take it
>> out. However, keep in mind that the community already seems to favor
>> whitelists (the wiki requires admin intervention for an account, same
>> on HackageDB).
>
> I think that "Verified accounts" sounds more appropriate than "Real
> Haskellers", then.

Cool, consider it done ;). Actually, it really is done, I just have to
push the code to the server.

Also, now 10 random profiles will be displayed on the homepage. Only
"verified users" will be displayed here. I'm also considering adding a
new status as well: real picture, so that only people with real images
(not cartoons, not identicons) can show up on the homepage. I think
this might give a more professional feel. Thoughts?

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

Re: [Haskell-cafe] Re: Re-order type (flip map)

[Stephen Tetley]

On 11 October 2010 00:00, Johannes Waldmann
 wrote:
>
>> My point was: you need to find/define two operators, not just one.
>
> Sure, I need  flip ($)  and  flip (.)
>
> Since the Prelude forgot to define these (and  flip map),
> the question was: are there established names for these two operators?
>

(#) was quite "established" for flip ($) around 2000 - its in a couple
of papers that appeared at the PADL conferences - one written by Erik
Meijer, Daan Leijen and (I think) James Hook on scripting Microsoft
Agents with COM. The authors noted reverse application with (#) gave
code a nice OO-like reading.

The other was Peter Thiemann's Wash - (#) is again flip ($) and (##)
is flipped compose.

Typographically I think these are a good fit, unfortunately they now
might play badly with GHC's magic hash operator.


Best wishes

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

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Nicolas Pouillard]

On Mon, 11 Oct 2010 05:50:32 +0200, Michael Snoyman  wrote:
> Sorry to everyone for not getting back so quickly, I kept getting
> errors from postfix when I tried sending mail to the cafe. Hopefully
> this one will go through. As I see it, two open issues are "flagging"
> and "real Haskellers".
> 
> Flagging: this was simply a mistake in terminology on my part. I've
> replaced it with "Report this user." It should be used for either
> inappropriate content, spam, or someone who's just clearly not part of
> the community (eg, "Lol, I don't know Haskell, I had Cocoa Puffs for
> breakfast"). I'm purposely being vague about this; if a user *thinks*
> there's a problem, it shouldn't take an admin more than a few seconds
> to investigate it.
> 
> Now the more important question about real Haskellers: I think I
> mentioned before implementing the feature that I was a little bit
> nervous about doing so. The main reason I went ahead and did it anyway
> was we were getting some... strange gravatars showing up on the
> homepage. This problem was solved automatically when I added sorting
> by years of experience (no one can object to Simon PJ and Lennart
> being on the homepage of course), but the problem with that system is
> *anyone* can just set their start year to 1990 and get homepage status
> until an admin blocks him/her.
> 
> So for the moment, real Haskeller is a minimal whitelisting system,
> simply intended to prevent people from gaming the system. I've
> probably chosen bad terminology, and by not explaining this upset a
> lot of people, my apologies. The point here is not to make the real
> Haskeller status exclusive, but just to give an extra level of
> protection. If people really think this is a bad idea, we can take it
> out. However, keep in mind that the community already seems to favor
> whitelists (the wiki requires admin intervention for an account, same
> on HackageDB).

I think that "Verified accounts" sounds more appropriate than "Real
Haskellers", then.

Regards,

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