Re: [Haskell-cafe] The Haskell theme

[Christopher Done]

On 13 October 2010 05:49, Mark Lentczner  wrote:
>  I spent some time beforehand looking at what other successful language 
> communities do w.r.t. visual design. I found that none of the communities had 
> a single theme; most had two or three. but these themes were visually 
> harmonious. Furthermore, I found that they were used consistently, and that 
> the various themes were generally at the same level of "polish".

Just out of interest, can you show some examples? A cursory glance at
Ruby, and I see that the home page[1] and their package site[2] are
completely different!

[1]: http://www.ruby-lang.org/en/
[2]: http://rubyforge.org/

> This means leaning toward consistent colors, and logo form, rather than exact 
> layout. Further, it seems more important that our projects get designers who 
> will do a thorough job, and less important that it be a single "central 
> design group".

Indeed.

> It is no accident that the new Haddock backend looks like the new wiki 
> design: Thomas Schilling (nominolo) supplied the initial style sheet that the 
> Haddock team used to build the "Ocean" theme. I think this exemplifies what 
> we should strive for: The two projects look well together, look like they 
> have a relationship, and both are full treatments of their subjects. It isn't 
> so important that they have identical layouts or details.

Ah, I didn't notice! I see that there is a navy blue bar at the top, a
grey footer and the links are orange. This is generally good enough, I
suppose. Nice.

> Since parts of the Hackage site integrate so closely with the Haddock output, 
> I've been asked if I would take a stab at styling the new Hackage (or at 
> least the package pages). I'll be aiming to make that fit, but without being 
> 100% rigid about conformance to the Ocean output.

Wwe could provide a base stylesheet which provides fonts, colours,
spacing, the heading and footer and logo. That way when you or anyone
starts on a new site you already have the base style upon which to
built, it will look like Haskell whatever layout or content you use.

>> http://img840.imageshack.us/img840/3577/ideasv.png
>
> Lovely ideas there and I think a Haskell project built on those lines would 
> continue to look well with the wiki and Haddock.

Can we use this logo? Or can we pick one? Every site I see has a
different incarnation of it. The favicon of the new-www site is even
different to the logo that's on the left. In fact on the new-www site
the logo colour changes from the home page to sub pages!

This reminds me, do we have a good syntax highlighting theme?
HsColour's has always been pretty bad (no offence intended -- but
there is a reason people always redefine it).

> I'd lean toward us putting these thoughts down in the wiki, and developing a 
> set of "guide posts" for styling Haskell, rather than a strict set of 
> policies.

This sounds like a good idea. The Python site has a page like this[3],
ours could be a little more comprehensive regarding the "polish", as
you say.

[3]: http://python.org/community/logos/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Neil Mitchell]

> The point here was not so much removing --help, but rather that I want to
> have control over the 'standard' options (help,version,verbosity) in the
> same way as for the rest. My program might not have a version, so why
> offer --version? Or maybe I want a different name for it because the -V is
> already used for something else, which I cannot change for backwards
> compatibility. I might want another name for --help, for instance -h. The
> standard -? does not work in all shells/configurations and --help might
> look strange if all other options are of the one-dash-one-character sort. I
> would also like to configure the help text for the standard options, for
> instance for i18n or because I like starting with a lower case letter or...

That i18n is a fantastic argument - and one that really means cmdargs
has no choice but to support all the attributes on help/version.

> BTW another cool feature of an auto-magic option parsing lib is the GNU
> standard "--" (arguments after this are not to be treated as options).

cmdargs also supports this by default.

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

Re: [Haskell-cafe] a couple of cabal related questions

[Antoine Latter]

On Tue, Oct 12, 2010 at 10:41 PM, Ivan Lazar Miljenovic
 wrote:
> On 13 October 2010 02:00, Magnus Therning  wrote:
>> On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal  wrote:
>>> By the way, the 'version' variable doesn't mentioned in Cabal user guide, or
>>> at least I missed it. Is it documented somewhere?
>>
>> I don't know, I think I found it in the source more or less by mistake :-)
>
> Yeah, I think that's the common consensus; there is _some_
> documentation of the Paths_foo module in the Cabal user guide, but it
> doesn't cover much.
>
> One thing I do wish was possible: the ability to use a "stub"
> Paths_foo module for testing purposes (as currently you have to have
> done a "cabal configure && cabal build" to get it), but I couldn't
> find a way to do so without Cabal packaging the stub version when
> creating the distribution tarball :s
>

I've used CPP, something like:

module MyPaths
 ( export contents of Paths_magic ) where

#ifdef SOME_DEF_SET_BY_CABAL
import Paths_magic
#else

mock implementation of paths magic here

#endif

Then in your .cabal file declare the define which causes it to use the
real magic paths module. When not compiling via cabal, you'll at least
have something sensible (like the current directory or something).

I'm pretty sure I didn't make this up, but I have used it. It's a bit
of a pain to set up, though.

Antoine
___
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]

I have turned the code into a library and put it up on github here:

http://github.com/kevinjardine/polyToMonoid

The library includes two versions of the function: ptm does not
require a termination function but does not allow partial evaluation
either. ctm is more composable (returning a function that consumes the
next parameter) and requires a termination function trm to return the
result.

The source includes thorough Haddock friendly comments with examples.

My plan is to upload it to Hackage later this week but I wondered if
anyone had any comments before I do.

Kevin

On Oct 11, 11:08 am, Kevin Jardine  wrote:
> 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
> > > 

Re: [Haskell-cafe] Yi on Windows

[Jeff Wheeler]

That bug is probably no longer correct. We now use the dyre package
for loading the config. Does anybody know if dyre works on Windows in
general?

On Tue, Oct 12, 2010 at 5:39 PM, Peter Marks  wrote:
> Does anyone use Yi on Windows? I've managed to get it to build and run, but
> it doesn't seem to pick up a config file. This seems to be an issue
> identified over a year
> ago: http://code.google.com/p/yi-editor/issues/detail?id=269. This would
> seem to render the editor almost completely useless on Windows. The whole
> point is to have an editor you can customize in Haskell.
> Any suggestions appreciated.
> Thanks
>
> Peter
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>



-- 
Jeff Wheeler

Undergraduate, Electrical Engineering
University of Illinois at Urbana-Champaign
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The Haskell theme

[Mark Lentczner]

On Oct 6, 2010, at 12:10 PM, Don Stewart wrote:
> * haskell visual design group?
>+ consistent color themes across haskell.org sites.
>+ consistent haskell branding.

On Oct 12, 2010, at 2:17 PM, Christopher Done wrote:

> To kick off discussion about Haskell's general theme, as discussed
> recently, here's some random ideas.

I was there for the BoF discussion, and this was one of the topics I was there 
to discuss. I spent some time beforehand looking at what other successful 
language communities do w.r.t. visual design. I found that none of the 
communities had a single theme; most had two or three. but these themes were 
visually harmonious. Furthermore, I found that they were used consistently, and 
that the various themes were generally at the same level of "polish".

For Haskell I think this means that while it isn't essential that we have a 
single common theme on all properties, it is important that various site 
designers think of the "whole look" of Haskell when designing their projects. 
This means leaning toward consistent colors, and logo form, rather than exact 
layout. Further, it seems more important that our projects get designers who 
will do a thorough job, and less important that it be a single "central design 
group".

It is no accident that the new Haddock backend looks like the new wiki design: 
Thomas Schilling (nominolo) supplied the initial style sheet that the Haddock 
team used to build the "Ocean" theme. I think this exemplifies what we should 
strive for: The two projects look well together, look like they have a 
relationship, and both are full treatments of their subjects. It isn't so 
important that they have identical layouts or details.

Since parts of the Hackage site integrate so closely with the Haddock output, 
I've been asked if I would take a stab at styling the new Hackage (or at least 
the package pages). I'll be aiming to make that fit, but without being 100% 
rigid about conformance to the Ocean output.

> http://img840.imageshack.us/img840/3577/ideasv.png

Lovely ideas there and I think a Haskell project built on those lines would 
continue to look well with the wiki and Haddock.

> I don't know what I was thinking here but it seemed like fun:
> http://img412.imageshack.us/img412/1827/rect5935.png

For some projects, I could imagine this feel would be more appropriate - yet 
still, there is enough tie-in to make it part of the family.

> Maybe we should do a theme poll like the logo poll. I don't know.
> Regardless, I think we do need to decide on something and stick with
> it. Should this discussion be taken to the web devel mailing list? Is
> that appropriate?

I'd lean toward us putting these thoughts down in the wiki, and developing a 
set of "guide posts" for styling Haskell, rather than a strict set of policies.

- Mark


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

Re: [Haskell-cafe] a couple of cabal related questions

[Ivan Lazar Miljenovic]

On 13 October 2010 02:00, Magnus Therning  wrote:
> On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal  wrote:
>> By the way, the 'version' variable doesn't mentioned in Cabal user guide, or
>> at least I missed it. Is it documented somewhere?
>
> I don't know, I think I found it in the source more or less by mistake :-)

Yeah, I think that's the common consensus; there is _some_
documentation of the Paths_foo module in the Cabal user guide, but it
doesn't cover much.

One thing I do wish was possible: the ability to use a "stub"
Paths_foo module for testing purposes (as currently you have to have
done a "cabal configure && cabal build" to get it), but I couldn't
find a way to do so without Cabal packaging the stub version when
creating the distribution tarball :s

-- 
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

[Haskell-cafe] Re: Re: Make your Darcs repositories hashed?

[Ben Franksen]

Jason Dagit wrote:
> On Tue, Oct 12, 2010 at 2:02 PM, Ben Franksen
> wrote:
> 
>> One minor but important note: the hashed format is *not* readable with a
>> darcs-1 program:
> 
> Sorry about that.  The support for hashed repos existed long before 2.0
> was released and so I misremembered the hashed support as appearing in a
> 1.x release.
> 
> It looks like you need at least 2.0 to read darcs 1 hashed repos.
> 
> Upgrading to a modern darcs client is advised and is only a 'cabal install
> darcs' away.  I was under the impression that even debian stable has moved
> on to 2.x releases.  How is it that you have a 1.0.9 release candidate
> client still?

Have you ever worked at a public institution? I recommend the
experience... ;-)

Seriously, the server is a debian etch (!) system. Also called "debian
old-stable". Of course I have long since installed newer version of darcs,
but since I am not root there I cannot put it into /usr/local, so I cannot
completely rule out the possibility that other users still use the
ancient /usr/bin/darcs and will now have problems when they darcs get.

I do _not_ expect that this will lead to any serious trouble, as the latest
stable darcs is just a small addition to the PATH away. Still, users should
be warned that darcs-2.x is required.

Cheers
Ben

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

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

[Ben Franksen]

Roman Cheplyaka wrote:
> 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.

Why not? They can say more about a person than a picture (not some generic,
auto-chosen one, of course).

Cheers
Ben

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

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

[Ben Franksen]

Joachim Breitner wrote:
> Am Dienstag, den 12.10.2010, 16:42 +1100 schrieb 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
> 
> note that people expect "cmd --help" to at least do nothing. So if your
> program is called "launchMissiles", please make it at least spit out a
> message like "your evil dictator was too lazy to write a help message"
> when it is called with --help.
> 
> (That is if you are sharing your program. Not sure if you should share
> "launchMissiles" at all.)

launchMissiles = putStrLn "Boom! (just kidding :)"

BTW another cool feature of an auto-magic option parsing lib is the GNU
standard "--" (arguments after this are not to be treated as options).

Cheers
Ben

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

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

[Ben Franksen]

Neil Mitchell 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?

I wanted to create a clone of an existing program that had no help option
and instead gave the help output if it saw an invalid option.

>> 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)
> 
> You can already do this with CmdArgs. If you use cmdArgsMode/process
> it returns a structure populated to say what to do next (i.e. display
> a help message), but you are welcome to do something different, or do
> what it says in a different way. However, I can see some people might
> want to remove help entirely, so I'll try and find a balance.

The point here was not so much removing --help, but rather that I want to
have control over the 'standard' options (help,version,verbosity) in the
same way as for the rest. My program might not have a version, so why
offer --version? Or maybe I want a different name for it because the -V is
already used for something else, which I cannot change for backwards
compatibility. I might want another name for --help, for instance -h. The
standard -? does not work in all shells/configurations and --help might
look strange if all other options are of the one-dash-one-character sort. I
would also like to configure the help text for the standard options, for
instance for i18n or because I like starting with a lower case letter or...

Cheers
Ben

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

[Haskell-cafe] Yi on Windows

[Peter Marks]

Does anyone use Yi on Windows? I've managed to get it to build and run, but
it doesn't seem to pick up a config file. This seems to be an issue
identified over a year ago:
http://code.google.com/p/yi-editor/issues/detail?id=269. This would seem to
render the editor almost completely useless on Windows. The whole point is
to have an editor you can customize in Haskell.

Any suggestions appreciated.

Thanks


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

Re: [Haskell-cafe] Re: Make your Darcs repositories hashed?

[Jason Dagit]

On Tue, Oct 12, 2010 at 2:02 PM, Ben Franksen wrote:

> One minor but important note: the hashed format is *not* readable with a
> darcs-1 program:
>

Sorry about that.  The support for hashed repos existed long before 2.0 was
released and so I misremembered the hashed support as appearing in a 1.x
release.

It looks like you need at least 2.0 to read darcs 1 hashed repos.

Upgrading to a modern darcs client is advised and is only a 'cabal install
darcs' away.  I was under the impression that even debian stable has moved
on to 2.x releases.  How is it that you have a 1.0.9 release candidate
client still?

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

Re: [Haskell-cafe] Client-extensible heterogeneous types

[Alexander Solla]

On Oct 12, 2010, at 4:24 AM, Jacek Generowicz wrote:


I can't see a Haskell solution which combines both of these orthogonal
features without losing the benefits of the type system. (For example,
I could create my own, weak, type system with tags to identify the
type and maps to do the dispatch.)


Is there any particular reason why you want to actually to mirror  
Python code?  I think that letting the programmer design domain  
specific control structures is rather the point of Haskell.  Instead  
of relying on a one-sized fits all solution (which only really fits  
one kind of problem), you write your own.  And it is typically easier  
to write the control structure than it is to implement it using the OO  
patterns, because of the notion of irreducible complexity.  For  
example, the Factory pattern constructs a functor.  You can write the  
essential semantics of doing this with a single Functor instance,  
instead of writing multiple classes which implement the semantics,  
while relying on implicit, and possibly ill-fitting semantics of  
method dispatch.  The other OO patterns make this objection stronger.   
If you can write a UML diagram, you can turn it into a commutative  
diagram, and write less code by implementing its arrows.


An OO class hierarchy is a very specific functor over objects (which  
attaches methods to objects).  Haskell provides the Functor type  
class.  Write your generic functions for specific functors:



-- The varying "input" types.  Will be attached to arbitrary values by  
the Functor instance.


data A = A  -- Variant 1
data B = B  -- Variant 2

-- Some normalized Output type.
data Output = Output

-- The new control structure.  
data Attaches a = AttachesA A a

| AttachesB B a

-- Stick your conditional (varying) semantics in here.  Corresponds to  
heterogeneousProcessor.  
-- The output presumably depends on whether A or B is attached, so  
this function is not equivalent 
-- to something of the form fmap (f :: a -> Output) (attaches ::  
Attaches a) 


runAttaches :: Attaches a -> Attaches Output
runAttaches = undefined

-- This corresponds roughly to  
heterogeneousProcessor(heterogeneousContainer):

processedOutputs :: [Attaches a] -> [(Attaches Output)]
processedOutputs as = fmap runAttaches as


-- Functor instance.  Now you have a way to treat an (Attaches a)  
value just like you would an a. (modulo calling fmap)

instance Functor Attaches where
 fmap f (AttachesA A a) = (AttachesA A (f a))
 fmap f (AttachesB B a) = (AttachesB B (f a))



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

[Haskell-cafe] The Haskell theme

[Christopher Done]

To kick off discussion about Haskell's general theme, as discussed
recently, here's some random ideas.

Going with the original colours of the nominated Haskell logo, and
kinda what's been done here:
http://new-www.haskell.org/haskellwiki/Haskell

http://img840.imageshack.us/img840/3577/ideasv.png

To download the Inkscape SVG grab it here:
http://chrisdone.com/designs/haskell-theme-1.svg

I don't know what I was thinking here but it seemed like fun:
http://img412.imageshack.us/img412/1827/rect5935.png

I get bored really quickly, I was alright for 15 minutes and then I
lost the will to point and click. Anyway, I was thinking rather than
trying to come up with a brilliant all-encompassing design, we could
agree on conventions:

* colours
* headings
* spacing
* links
* the particular incarnation of the logo

etc.

I'm pretty happy to go with the colour theme of
http://new-www.haskell.org/haskellwiki/Haskell

Haskellers.com also makes me think we need an umbrella theme that
encompasses all Haskell sites.

Maybe we should do a theme poll like the logo poll. I don't know.
Regardless, I think we do need to decide on something and stick with
it. Should this discussion be taken to the web devel mailing list? Is
that appropriate?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Make your Darcs repositories hashed?

[Ben Franksen]

One minor but important note: the hashed format is *not* readable with a
darcs-1 program:

(after a darcs optimize --upgrade
in /opt/repositories/controls/darcs/apps/HoBiCaT)

frank...@aragon:~/tmp > /usr/bin/darcs --version
1.0.9rc1 (release candidate 1)
frank...@aragon:~/tmp > /usr/bin/darcs
get /opt/repositories/controls/darcs/apps/HoBiCaT
Invalid repository:  /srv/csr/repositories/controls/darcs/apps/HoBiCaT
darcs: /srv/csr/repositories/controls/darcs/apps/HoBiCaT/_darcs/inventory:
openBinaryFile: does not exist (No such file or directory)
frank...@aragon:~/tmp > /opt/darcs/bin/darcs --version
2.0.2 (release)
frank...@aragon:~/tmp > /opt/darcs/bin/darcs
get /opt/repositories/controls/darcs/apps/HoBiCaT
Copying patches, to get lazy repository hit ctrl-C...
Finished getting.

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

 On 10/12/10 1:22 PM, Dan Doel wrote:

On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote:


Hughes himself said that when your arrow is an instance of ArrowApply,
you are better off just sticking with monads.

Well, this is not necessarily good advice. It is true that ArrowApply will
preclude some sort of static analysis. But, this does not mean that you cannot
do the static analysis on the pieces of code that *can* be written using less
powerful arrow combinators.



Okay, you make a good point here;  it might be the case that it is worth 
implementing an Arrow interface in order to provide a set of combinators 
that can do static analysis and hence confer some sort of benefit such 
as improved performance.



The same can be said about Applicative, Monad, etc. The combinators in the
former could be implemented in ways that allow some extra analysis to be done,
while those in the latter are still available when absolutely necessary. I
believe the Utrecht parsing library does this, and encourages parsers to be
written in applicative style as much as possible for this reason.



Darnit, you are using my own arguments against me here.  ;-)  I say this 
because earlier in this forum I personally argued that it there are 
times when it is beneficial to have the Applicative instance not 
directly follow the Monad instance so that you do interesting things 
that you can't do with the Monad instance, such as running computations 
in parallel.  Thus, likewise I am forced to see your point and conclude 
that it might be useful sometimes to define an Arrow instance in 
addition to a Monad instance so that the Arrow instance can take 
advantage of the Arrow structure to do interesting things.


This has definitely given me food for thought;  thank you.


If you have nothing like that to gain, though, it may make sense to jettison
arrows due merely to syntactic considerations and the like, though.



Yes, I agree, and in fact this the point that I have been trying to make 
all along.


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

RE: [Haskell-cafe] Windows binary for latest darcs head

[Phyx]

If oktober 7th would do you can get it at
http://www.haskell.org/ghc/dist/current/dist/ 

http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101007-i386-windows.e
xe

 

maybe a newer build would show up soon.

 

From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Aaron Gray
Sent: Tuesday, October 12, 2010 16:43
To: Haskell-Cafe
Subject: [Haskell-cafe] Windows binary for latest darcs head

 

Does anyone have a Windows binary for the latest GHC darcs head or at least
October 8th they could send me.

 

Many thanks in advance,

 

Aaron

 

___
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

[C. McCann]

On Tue, Oct 12, 2010 at 3:00 PM, Paolo G. Giarrusso
 wrote:
> Were you writing a paper, your comment would be fully valid. Here
> we're talking about a library for people to use in practice. In the
> middle, somebody should make sure that people without a PhD can learn
> arrows, by providing documentation. The problem might be just
> educational, and it's not restricted to arrows, but it is still a
> valid problem.

Oh, for crying out loud, no it isn't. I don't have a PhD. I don't have
any graduate degree at all. I didn't learn anything about functional
programming back when I was an undergraduate at a
not-exactly-prestigious school, never mind category theory or abstract
algebra or any of that stuff, and I only started even learning Haskell
barely a year ago.

Arrows are easy to understand. Yes, really.

I'll agree that a lot of libraries on hackage could stand to have
better documentation and examples of usage--and I've not actually used
HXT itself so I can't speak to how well it does--but I honestly cannot
begin to imagine how using a fairly straightforward type class that's
part of the core libraries included with the most popular compiler is
a problem.

> When you write a library for general consumption (like here), you
> should strive to have a simple and effective interface for people.

Arrows *are* a simple and effective interface. Whether they're the
best interface to choose for any specific library is a trickier
question, of course, but that's because choosing how to structure a
library interface is always difficult.

> Try to think of what's happening. Even the existence of this thread is
> surprising. Haskell programmers, and experienced ones, are discussing
> about how to express a two arguments function with arrows.
> Can you imagine a C programmer asking that? The answer would be "RTFM"
> or "STFW", or less polite than that. And that's GOOD. You can use
> arrows because you got an useful intuition of them. Good for you.

There's only one way to express a general arrow with two inputs: Use a
tuple, because general arrows can't be curried. The discussion is
about converting a two-argument function to an arrow directly vs.
using one argument as a parameter to a function that constructs a
single-input arrow, and the only reason it's an issue is because the
syntax for supplying a constant argument to an arrow is a bit clunkier
than doing so for a function.

A better analogy might be programmers using some OO language
discussing whether some piece of usually-static data that an object
needs should be a method parameter (likely creating a bunch of
redundant code) or set just once by a constructor parameter (awkward
in those cases where it does need to change).

It is, as Sebastiaan Visser said, an engineering problem, not a
conceptual problem. Avoiding arrows would simply produce a different
set of engineering problems to consider.

> Some people argue for 2), but the "research bias" of the community is
> still quite strong. And you can't achieve 2) well working with a
> research methodology. For instance, somebody needs to write _complete_
> documentation (I see there is some, but it doesn't cover the basic
> questions you are discussing), intended for users, rather than papers.
> Like it happens for any other language.

I do get a little tired of finding libraries whose only documentation
consists of a couple papers, found in PDF form on the author's
university homepage (or worse, no documentation at all). But expecting
a library like HXT to walk someone through how to use libraries that
are included with GHC seems a bit unreasonable.

> Of course, nobody _has to do_ anything. I'm a PhD student, I couldn't
> work on any of this because it wouldn't count for my career. But at
> least I'm aware my work won't be usable for purpose 2). (Intermediate
> situations, like writing a paper _and_ a dumbed-down version for
> general consumption, are also possible of course).

I don't like the idea that things need to be "dumbed-down" for general
use. Programmers aren't stupid and they can learn new ideas. Talking
about stuff like it's some crazy incomprehensible deep magic that only
super-geniuses can understand is silly and not helpful.

...Well, that all probably came out sounding harsher than I intended,
my apologies if so. I'm just a little weary of seeing ideas like
arrows made out to be more complicated than they really are; I
honestly think at least 90% of what makes them seem difficult is
people telling each other how difficult they are!

- C.
___
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]

 On 10/12/10 6:29 AM, Sebastiaan Visser wrote:

Gregory,

I use arrows (especially list arrows) in a lot of my projects and find them 
(after some training) easier to work with than monands. Code that I write 
point-free using arrows generally contains fewer bugs than code I write in 
monadic style.


So what it is that you like is the point-free style rather than the use 
of arrows.  There is nothing stopping you from using point-free style 
with monads, and I personally prefer to do so when I can.  So to repeat 
this again, I am not arguing against point-free style, I am arguing 
against basing libraries on arrows instead of monads unless one 
specifically needs the more general structure of the arrows because 
otherwise it makes life less convenient for the user as (among other 
reasons) it introduces extra syntax and prevents use of standard monad 
combinators and libraries.



I think it is unfair to say that arrows add complexity over monads. This 
statement can only be true to people who actually know monads and do not know 
arrows. This has more to do with the direction of one's knowledge than the 
'complexity' (whatever this means) of a programming abstraction.



I can assure you that I have spent a lot of time looking at arrows and 
even once wrote and used instance of Arrow myself in a situation where a 
monad would not have been appropriate.  To be specific:  the additional 
complexity comes from the fact that additional notation is needed to 
accomplish the same goal, and from the fact that standard monad 
combinators and libraries cannot be used.  This isn't simply a matter of 
being unfamiliar with arrows.



Don't see arrows a less restricted monads, see them as a generalization of 
functions, than it will all make sense. Use them in situations that need 
generalization of functions, not in cases that require the power of monads.



I am not sure what you are getting at with this, because your 
description contradicts my usual notion of when one uses monads and 
arrows --- namely, when one is working with a structure that fits one or 
the other of the two patterns and one wants to leverage special 
libraries and/or syntax.



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.

I'd rather use (.) for composition of expressions than (<=<) and I'd rather use 
the 'id' for identity than return. Writing my arrow computations point-free as if 
they were functions feels far less clumsy and a far more readable than monadic style.



Fair enough, but again, in exchange for these two operators you lose 
monadic combinators and libraries and introduce additional syntax.



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.

This restriction, though not always, can be very useful. This restriction 
allows you to do full inspection of the arrow expression. This inspection can 
in some cases be used to serialize an arrow computation of statically optimize 
it to a more efficient form.



I agree completely!  This is *exactly* the kind of time when it is 
appropriate to use an arrow.  The choice of whether to use an arrow or a 
monad should be based on the structure of the underlying system, with 
the latter to be preferred unless there is a good reason to choose the 
former.



When you don't need the power of Monads (or ArrowApply) why use a formalism 
that does provide this power? That will only make it harder to reason about 
your program, which isn't quite the Haskell way.



Because, again, it makes the life of the user of your library easier --- 
for example, when they decide to use it in a way that is perfectly 
legitimate but is not something you had thought of in advance.


Put another way, why should one place an arbitrary restriction on the 
user when there is nothing gained by it?



I've worked with HXT quite a lot and

[Haskell-cafe] Protocol buffer network examples

[Mads Lindstrøm]

Hi

I am trying to read and write delimited messages[3] using
protocol-buffers [1,2] over a socket. I have managed to write delimited
messages and I was looking for examples of reading delimited messages.
Maybe somebody has an example of reading delimited messages from a
socket?

The Haskell protocol-buffer[1] package mostly uses bytestrings, but I
need to read from a socket. Of cause, I can use the bytestring package
to read X number of bytes from a socket-handle. But it is impossible to
know what X is, before you start parsing the message, as even integers
are variable length in protocol buffers.


Hope somebody can help,

Mads Lindstrøm

[1] http://hackage.haskell.org/package/protocol-buffers

[2] http://code.google.com/p/protobuf/

[3] Delimited messages is a protocol buffers technique, where one writes
the size of the message before the actual message:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming

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

 On 10/12/10 12:39 PM, Gene A wrote:


splitMiddle :: forall a. [a] -> ([a], [a])
splitMiddle  =
   (id &&& (length >>> flip div 2)) >>>
   (\(xs,a) -> splitAt a xs)



But is that really easier to understand at a glance then

splitMiddle xs = splitAt (length xs `div` 2) xs

?  It seems to me that while point-free style is nice and I personally 
us it extensively, sticking to it religiously can sometimes lead to code 
that is *less* clear.


Also, I don't see why one would prefer >>> over the standard function 
composition operator, ".".  Using this and uncurry you could actually 
make your point-free style definition much more succinct and arguably 
easier to read:


splitMiddle = uncurry splitAt . ((`div` 2) . length &&& id)



OKAY here is where the thoughts can come in to play and are a direct
result of the pointfree style that is adopted as a direct result of 
using arrow

notation.   [...]


I completely agree with you that point-free style is nice;  I am 
certainly not arguing against it.  However, it can be over-kill, and 
there is no reason that I can see why using the arrow notation ">>>" in 
place of the standard function notation "." helps one write function in 
a point-free style.



The other nice use of arrow is INSIDE of a monadic structure:


 "Now is the time to come to the aid of our country" >>= (return >>> 
words >>> concat)

"Nowisthetimetocometotheaidofourcountry" [...]



Your use of a monad here both redundant and obfuscatory;  a much simpler 
version of this code is


(concat . words) "Now is the time to come to the aid of our country"



squeezeSentenceF
  :: forall (f :: * -> *). (Functor f) => f [Char] -> f [Char]
squeezeSentenceF css = (squeeze <$>) css
squeezeSentenceF ["This is how to do a list of sentences",
  "It makes use of applicatives too"]
["Thisishowtodoalistofsentences","Itmakesuseofapplicativestoo"]
[...]


You aren't really using applicative style here, you are just defining a 
shorthand for calling "fmap squeeze".  Also, your function could be 
expressed in point-free style as follows:


squeezeSentenceF = fmap squeeze


 I think that the more you mix and match ALL of the tools and
do a little experimentation with them, that it then begins to be a 
situation where
your thoughts of how to compose things are not locked down to one way 
and it
opens up your mind to many possibilities.  I am a proponent of having 
and using

ALL the available tools in a mix and match way if need be.


I agree, but what I oppose is the choice of fancy tools because they are 
fancy rather than because they get the job done better than simple 
tools, because the fancy tools often carry a price with them over the 
simpler tools.


Cheers,
Greg
___
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

[Dan Doel]

On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote:

> Hughes himself said that when your arrow is an instance of ArrowApply,
> you are better off just sticking with monads.

Well, this is not necessarily good advice. It is true that ArrowApply will 
preclude some sort of static analysis. But, this does not mean that you cannot 
do the static analysis on the pieces of code that *can* be written using less 
powerful arrow combinators.

The same can be said about Applicative, Monad, etc. The combinators in the 
former could be implemented in ways that allow some extra analysis to be done, 
while those in the latter are still available when absolutely necessary. I 
believe the Utrecht parsing library does this, and encourages parsers to be 
written in applicative style as much as possible for this reason.

If you have nothing like that to gain, though, it may make sense to jettison 
arrows due merely to syntactic considerations and the like, though.

-- Dan
___
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]

 On 10/12/10 5:56 AM, Uwe Schmidt wrote:

Hi Gregory,

As I understood, John Hughes invented the arrows as a generalisation
of monads, you say it's a less powerful concept. I'm a bit puzzled with
that. Could you explain these different views.



Consider the following example:

f :: Int -> m a
f i = monads !! (i *5 `mod` length monads)
where
monads = [...] :: [m a]

In this case, we see that the action chosen by f is a non-trivial 
function of the input argument.  In general, there is no way that we can 
represent this equivalently as an arrow.  The reason why is because, 
unlike monads, in general arrows do not give you arbitrary freedom to 
choose the action performed by the arrow.  It is true that one can get 
this freedom back for arrows which are instances of ArrowApply, but that 
that point what you really have is a monad with different notation.  
Hughes himself said that when your arrow is an instance of ArrowApply, 
you are better off just sticking with monads.


The reason for the existence of arrows is because allowing the user to 
arbitrarily choose actions restricts the power that the creator of a 
library has to do stuff behind the scenes with these actions.  To see 
why, suppose we are chaining together two arrows like so:


f :: Arrow a b
g :: Arrow b c
h :: Arrow a c
h = f >>> g

When defining the composition operator >>>, the library author has the 
power to "open up" both of the actions f and g, which gives him lots of 
power in defining what h should be.  By contrast, suppose we are 
chaining together two monads like this:


f :: Monad b
g :: b -> Monad c
h :: Monad c
h = f >>= g

When defining the composition operator >>=, the library author can look 
inside f, but he has no way of knowing which action will be chosen by g, 
so he cannot use this information to decide what h should be.


The motivation Hughes gave for arrows was parsers that have a "static" 
part in them;  he pointed out that using monads we have no way to access 
and combine these static parts, so we needed to come up with a formalism 
that let us have a nice combinator framework like monads but which 
allows us to "break open" components so that we can combine them in 
interesting ways.


So in short, arrows (relative to monads) take away some of the power of 
the user to choose actions as a function of the input in order to give 
library authors more power to define how actions are combined.  In this 
sense arrows are "less powerful" from a user perspective than monads, 
except in the case where an arrow is an instance of ArrowApply in which 
case they are



...
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.

yes, I agree. What about the other combinators (&&&, ***,...)?



A couple of points in response.  First, though it is less convenient, 
you can use those combinators if you wrap your arrow inside the Kleisli 
newtype wrapper, which is something I have occasionally done.  Second, 
while I see your point that there are some combinators that arrows have 
that are not defined for monads, there are not that many of them, and it 
would be trivial to write special instances of them for monads;  it 
seems to me that the price of making versions of these operators for 
monads is less than the price of having to re-implement all of the 
existing monad combinators and libraries using arrow notation just to 
not have to redefined monad versions of &&&, etc.



...
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. ...

It's rather easy to define some choice combinators. Or am I
missing the point?



No, in general arrows do not allow you to define choice combinators.  
Having said that, you *can* give the user some power to choose between 
fixed choices action in exchange for possibly losing power from your 
perspective a library author.  If your arrow is an instance of 
ArrowChoice, then you give your user the ability to choose between a 
fixed set of predefined actions.  However, the user is not able to 
compute an arbitrary action in response to an input.  To get this power, 
you need to make your arrow an instance of ArrowApply, in which case you 
really aren't getting any benefit from the perspective of either a user 
*or* a library author over using a monad.



yes, this a common pattern, a function f' with an extra argument of type a,
and sometimes you want to call f' with some value, e.g. f' 42,
sometimes the extra argument must be computed from the arrow input, let's say
with an arrow g.

For this case in hxt there is a combinator ($<) with signature

($<) :: (c ->  a b d) ->  a b c ->  a b d

With that combi

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

[Gene A]

>
> On Tue, Oct 12, 2010 at 8:56 AM, Uwe Schmidt  wrote:
> >> 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.
>

On Tue, Oct 12, 2010 at 9:49 AM, C. McCann  wrote

> Essentially, arrows lend themselves best to composing first-order
> computations to create larger computations with a fixed structure. If
> you find yourself forced to frequently use ArrowApply or other means
> of eliminating higher-order structure--e.g., anything that results in
> an arrow with an output type that contains fewer instances of the
> arrow's own type constructor than does the input type--it may be worth
> considering if arrows are really what you want to use.
>
> Personally, though, I think monads are really overkill in many cases
> and strongly prefer, where possible, to use Applicative or Arrow.
>
>
Well I am compelled to add my two cents worth to this conversation.  I like
to use examples, so that is what I will do.  I am going to use a simple one,
and you may wonder why I used an arrow to represent this little computation,
but the main reason is that it fits the way I think better then if's ,
guards, cases, in or where clauses.  The entirety of a computation is right
there in my face.  The other thing that I will explain after showing this
little example function {arrow under the hood} is that it leads to more
thinking of composing into even more higher orderness, until you have a
single function definition that can be the entire program.

Function splitMiddle:
 Takes a list and returns a pair consisting of the
 list split into two equal parts.

splitMiddle :: forall a. [a] -> ([a], [a])
splitMiddle  =
   (id  &&& (length >>> flip div 2)) >>>
   (\(xs,a) -> splitAt a xs)

usage:
 splitMiddle [1..10]
([1,2,3,4,5],[6,7,8,9,10])

OKAY here is where the thoughts can come in to play and are a direct
result of the pointfree style that is adopted as a direct result of using
arrow
notation.  To split the list of words of a line of text you may do this
initially:

splitMiddle $ words "Now is the time to come to the aid of our country"
(["Now","is","the","time","to","come"],["to","the","aid","of","our","country"])

Then it occurs that well hell, why not move the "words" function into the
arrow:

(words >>> splitMiddle) "Now is the time to come to the aid of our country"
(["Now","is","the","time","to","come"],["to","the","aid","of","our","country"])

That can be turned into a new function with great ease and clarity:

splitSentence :: String -> ([String], [String])
splitSentence = words >>> splitMiddle

Then maybe I decide, hey, I only want the second half of the sentence:

sndHalfSentence :: String -> [String]
sndHalfSentence = words >>> splitMiddle >>> snd

or if I have defined splitSentence as above:

sndHalfSentence :: String -> [String]
sndHalfSentence = splitSentence >>> snd

doing the function fstHalfSentence is obvious in that the mechanics
are right there to see and no variables to muck it up, just change the
snd to fst :

fstHalfSentence :: String -> [String]
fstHalfSentence = splitSentence >>> fst

The other nice use of arrow is INSIDE of a monadic structure:


 "Now is the time to come to the aid of our country" >>= (return >>> words
>>> concat)
"Nowisthetimetocometotheaidofourcountry"

which can become the definition of squeeze:

squeeze :: [Char] -> [Char]
*Big3> let squeeze cs = cs >>= (return >>> words >>> concat)

squeeze "Now is the time to come to the aid of our country"
"Nowisthetimetocometotheaidofourcountry"

and then of course you can do a few sentences instead of only
one,if you change the definition with the simple addition of an

applicative operator to the mix.

squeezeSentenceF
  :: forall (f :: * -> *). (Functor f) => f [Char] -> f [Char]
squeezeSentenceF css = (squeeze <$>) css
squeezeSentenceF ["This is how to do a list of sentences",
  "It makes use of applicatives too"]
["Thisishowtodoalistofsentences","Itmakesuseofapplicativestoo"]

notice that this is more general then just mapping as it applies to any
functor, of which the Maybe monad has an instance..
so:
 squeezeSentenceL  (Just "This is how to do a Maybe sentence")
Just "ThisishowtodoaMaybesentence"

works just nicely.  I think that the more you mix and match ALL of the tools
and
do a little experimentation with them, that it then begins to be a situation
where
your thoughts of how to compose things are not locked down to one way and it
opens up your mind to many possibilities.  I am a proponent of having and
using
ALL the available tools in a mix and match way if need be. About the only
thing
you have to do to use any of the various tools in the same line of code is
to remember
to use a parenthetic bit of separation between one and the next.
metacode"
xss >>= ( ((g >>>

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

[Paolo G. Giarrusso]

Dear Sebastiaan,
I would first refer to the description of the "Change function" in a
paper by Erik Meijer (an Haskeller among the designers of F#):
http://portal.acm.org/citation.cfm?id=1297027.1297078
In short, programmers will learn something new only if the improvement
is worth the effort of the paradigm shift.

Below I add my opinions on the specific problem. A disclaimer: I am
unfamiliar with monads myself, I claim awareness of a meta-problem,
which is IMHO more important.
On Oct 12, 3:29 pm, Sebastiaan Visser  wrote:
> Gregory,

> I use arrows (especially list arrows) in a lot of my projects and find them 
> (after some training) easier to work with than monands. Code that I write 
> point-free using arrows generally contains fewer bugs than code I write in 
> monadic style.

> I think it is unfair to say that arrows add complexity over monads. This 
> statement can only be true to people who actually know monads and do not know 
> arrows. This has more to do with the direction of one's knowledge than the 
> 'complexity' (whatever this means) of a programming abstraction.

Were you writing a paper, your comment would be fully valid. Here
we're talking about a library for people to use in practice. In the
middle, somebody should make sure that people without a PhD can learn
arrows, by providing documentation. The problem might be just
educational, and it's not restricted to arrows, but it is still a
valid problem.
When you write a library for general consumption (like here), you
should strive to have a simple and effective interface for people.

Try to think of what's happening. Even the existence of this thread is
surprising. Haskell programmers, and experienced ones, are discussing
about how to express a two arguments function with arrows.
Can you imagine a C programmer asking that? The answer would be "RTFM"
or "STFW", or less polite than that. And that's GOOD. You can use
arrows because you got an useful intuition of them. Good for you.

The problem is partially the same as with monads, only to a greater
extent: monads can be easy if you don't try to relate them to category
theory, and they are indeed considered easy in F# (see the same
paper). Again, the problem is maybe mostly educational, but it is
entirely valid.

Of course, the root question is: what is the purpose of Haskell?
1) Is it to produce pure research, which might then be reused in
production to actually affect software engineering, and used directly
by blessed PhD students?
2) Or should Haskell be used as such?
Some people argue for 2), but the "research bias" of the community is
still quite strong. And you can't achieve 2) well working with a
research methodology. For instance, somebody needs to write _complete_
documentation (I see there is some, but it doesn't cover the basic
questions you are discussing), intended for users, rather than papers.
Like it happens for any other language.

Of course, nobody _has to do_ anything. I'm a PhD student, I couldn't
work on any of this because it wouldn't count for my career. But at
least I'm aware my work won't be usable for purpose 2). (Intermediate
situations, like writing a paper _and_ a dumbed-down version for
general consumption, are also possible of course).

Best regards
___
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

[C. McCann]

On Tue, Oct 12, 2010 at 8:56 AM, Uwe Schmidt  wrote:
>> 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.
>
> As I understood, John Hughes invented the arrows as a generalisation
> of monads, you say it's a less powerful concept. I'm a bit puzzled with
> that. Could you explain these different views.

These are the same thing, the difference is whether you're talking
about how many different concepts are compatible with an abstract
structure as opposed to what can be done universally with such a
structure. Adding the ability to do more things with a structure
necessarily reduces the number of concepts that structure applies to.

Perhaps a more familiar example is the relationship Functor >
Applicative > Monad. Going left to right adds power, making generic
code more expressive but reducing the number of concepts that can be
represented as instances; going right to left adds generality,
limiting what generic code can do but enabling more instances.

That said, I dislike calling arrows a generalization of monads--it's
not incorrect as such, but I don't think it aids understanding. It
really is much better to think of them as generalized functions, which
they explicitly are if you look at the borrowed category theory
terminology being used. They're generalized monads only in the sense
that functions (a -> m b) form arrows in a category, as far as I can
tell.

>> 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. ...
>
> It's rather easy to define some choice combinators. Or am I
> missing the point?

The key point is that arrows in full generality--meaning instances of
Arrow only, not other type classes--are not higher-order because no
internal application operator is provided. The ArrowApply class gives
you full higher-order generalized functions, at the cost of giving up
some useful limitations (read: static guarantees about code behavior)
that make reasoning about arrow-based structures potentially easier.

So, a general arrow can perform different actions and produce
different output based on input it receives, but it can't take *other
arrows* and pick different ones to use depending on its input.

> The combinator does the following: The input of the whole arrow
> is fed into g, g computes some result and this result together with the
> input is used for evaluating f'.  The ($<) is something similar to ($).

There's no shortage of ways to deal with the issue, but they all rely
on using combinator *functions*, not arrows. The result is that
arrow-based expressions tend to be internally less flexible, following
pre-defined paths, similar to how expressions using Applicative can't
embed control flow the way ones using Monad can. Which is fine for
many purposes, of course.

Essentially, arrows lend themselves best to composing first-order
computations to create larger computations with a fixed structure. If
you find yourself forced to frequently use ArrowApply or other means
of eliminating higher-order structure--e.g., anything that results in
an arrow with an output type that contains fewer instances of the
arrow's own type constructor than does the input type--it may be worth
considering if arrows are really what you want to use.

Personally, though, I think monads are really overkill in many cases
and strongly prefer, where possible, to use Applicative or Arrow.

- C.
___
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 Tuesday 12 October 2010 17:15:14, Antoine Latter wrote:
> On Tue, Oct 12, 2010 at 10:02 AM, Tyson Whitehead  
wrote:
> > On October 11, 2010 15:12:12 Daniel Fischer wrote:
> >> 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).
> >
> > Out of curiosity, by new code generator, are you meaning just the
> > stock GHC 7 code path or are you meaning the new now available but
> > disabled by default unless you use some flag (which I forget right
> > now) code generation path.
> >
> > Cheers!  -Tyson
>
> When I did the GHC 7 timings I simply ran the shell script provided in
> the linked tarball - no funny business.
>
> Antoine

Yep, just a vanilla perf build of HEAD.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.Judy

[Don Stewart]

tomdoris:
> Hi,
> Are there any plans to extent the current Data.Judy package to include 
> bindings
> to JudySL and JudyHS? There's a standalone binding to JudySL by Andrew Choi
> that is usable but it would of course be better to have the functionality in
> the Data.Judy package proper.
> Thanks
> Tom

Patches will be accepted! I'm not currently working on this though.
___
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

[Antoine Latter]

On Tue, Oct 12, 2010 at 10:02 AM, Tyson Whitehead  wrote:
> On October 11, 2010 15:12:12 Daniel Fischer wrote:
>> 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).
>
> Out of curiosity, by new code generator, are you meaning just the stock GHC 7
> code path or are you meaning the new now available but disabled by default
> unless you use some flag (which I forget right now) code generation path.
>
> Cheers!  -Tyson
>

When I did the GHC 7 timings I simply ran the shell script provided in
the linked tarball - no funny business.

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

Re: [Haskell-cafe] a couple of cabal related questions

[Magnus Therning]

On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal  wrote:
> On 12.10.2010 13:45, Magnus Therning wrote:
>>
>> On Tue, Oct 12, 2010 at 10:20, Dmitry V'yal  wrote:
>>>
>>> Hello,
>>>
>>> recently I've cabalized my program and it brought some problems.
>>>
>>> First of all, I made use of 'import Paths_' functionality
>>> to
>>> get the path of installed data files. It works great, but now I can no
>>> longer run my program in ghci because this module is auto-generated by
>>> cabal. I tried to supply my own. This way ghci works, but my stub module
>>> gets compiled into the binary in place of auto-generated. And things
>>> break
>>> again. What's the best way to overcome it?
>>
>> Create a file called .ghci in the directory where you run ghci and
>> make it contains something like this:
>>
>> :set -idist/build/autogen
>>
>>> And another question. I'd like to make my program output it's version
>>> string. Of course, I can hardcode it into sources, but I've already
>>> specified one in the cabal file. Is there any way to get it back in the
>>> run
>>> time?
>>
>> It's in Paths_  as the variable 'version'.
>>
>> /M
>>
>
> That's perfectly what I was looking for, thanks a lot!
>
> By the way, the 'version' variable doesn't mentioned in Cabal user guide, or
> at least I missed it. Is it documented somewhere?

I don't know, I think I found it in the source more or less by mistake :-)

/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

[Haskell-cafe] Haskellers.com survey

[Michael Snoyman]

Hey all,

Guessing popular consensus based on what people write on the mailing
list is not exactly statistically sound. So instead, I've put up some
of our open questions- along with some other questions I've wanted to
ask- in a survey. If you are interested in the future of Haskellers, I
encourage you to fill it out.

https://spreadsheets.google.com/viewform?formkey=dG8tcVhBdzRSS1lkdVV6U281emtRMWc6MQ

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

[Haskell-cafe] Windows binary for latest darcs head

[Aaron Gray]

Does anyone have a Windows binary for the latest GHC darcs head or at least
October 8th they could send me.

Many thanks in advance,

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

Re: [Haskell-cafe] a couple of cabal related questions

[Dmitry V'yal]

On 12.10.2010 13:45, Magnus Therning wrote:

On Tue, Oct 12, 2010 at 10:20, Dmitry V'yal  wrote:

Hello,

recently I've cabalized my program and it brought some problems.

First of all, I made use of 'import Paths_' functionality to
get the path of installed data files. It works great, but now I can no
longer run my program in ghci because this module is auto-generated by
cabal. I tried to supply my own. This way ghci works, but my stub module
gets compiled into the binary in place of auto-generated. And things break
again. What's the best way to overcome it?


Create a file called .ghci in the directory where you run ghci and
make it contains something like this:

:set -idist/build/autogen


And another question. I'd like to make my program output it's version
string. Of course, I can hardcode it into sources, but I've already
specified one in the cabal file. Is there any way to get it back in the run
time?


It's in Paths_  as the variable 'version'.

/M



That's perfectly what I was looking for, thanks a lot!

By the way, the 'version' variable doesn't mentioned in Cabal user 
guide, or at least I missed it. Is it documented somewhere?

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

Re: [Haskell-cafe] Desired behaviour of rounding etc.

[Daniel Fischer]

On Tuesday 12 October 2010 11:18:39, Simon Marlow wrote:
> On 09/10/2010 10:07, Daniel Fischer wrote:
> > On Saturday 09 October 2010 06:34:32, Lennart Augustsson wrote:
> >> That code is incorrect.  You can't assume that the base for floating
> >> point numbers is 2, that's something you have to check.
> >> (POWER6 and z9 has hardware support for base 10 floating point.)

> > -- We assume that FLT_RADIX is 2 so that we can use more efficient
> > code #if FLT_RADIX != 2
> > #error FLT_RADIX must be 2
> > #endif

>
> Making the assumption is fine (as we do in the code above), but the
> important thing is to make the build fail in a very noisy way if the
> assumption turns out to be wrong (as above).
>
> Cheers,
> Simon

Are there any other places where FLT_RADIX == 2 is assumed?
(grepping the .hs, .lhs and .h files in the source tree for FLT_RADIX 
revealed nothing else.)
If that's the only place where e.g. base 10 floating point would fail, we 
should make it work for that too.
If on the other hand base 2 is assumed in other places, for primops, 
whatever, and that assumption is not going to be changed, I'd prefer not to 
litter the source with dead code.

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

Re: [Haskell-cafe] Client-extensible heterogeneous types

[Stephen Tetley]

On 12 October 2010 14:08, Jacek Generowicz  wrote:

> Reading the GHC docs on Data.Dynamic, I infer that Data.Dynamic is
> non-standard, but, in principle, portable to other implementations.
>
> Is that understanding correct?

Yes - Data.Dynamic uses some GHC specifics but there are other
"lightweight" encodings of dynamic types that I think just use
existential types (which John Lato mentioned).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Make your Darcs repositories hashed?

[Eric Kow]

Hey Haskellers (and darcs-users CC'ed)

On Sat, Oct 09, 2010 at 23:08:12 +, Jason Dagit wrote:
> I answered you immediate question in a different email.  Now I'll do a bit
> of explanation on why people want hashed.

Thanks to Jason for the explanation.

I've linked to it from http://wiki.darcs.net/RepositoryFormats so that
we'll have an easier time in the future encouraging people to move to
the hashed format.

Also: If you don't have darcs 2.4.4, you can upgrade to the hashed
format by doing:

  cd /srv/code/myrepo 
  darcs get . ~/myrepo-hashed 

  rm -rf ~/myrepo-hashed/_darcs/prefs 
  cp -R _darcs/prefs ~/myrepo-hashed/_darcs/prefs 

  mv ~/myrepo-hashed/_darcs _darcs.new 
  mv _darcs _darcs.old
  mv _darcs.new _darcs 

  rm -rf ~/myrepo-hashed 
  rm -rf _darcs.old

I may put this on the wiki. We had pruned this sort of thing away in
favour of the optimize --upgrade command, in the interest of tidiness,
but getting recent Darcs into people's hands takes a while.

Also, the maintainers behind code.haskell.org are aware about the need
for a Darcs 2.4.4 upgrade (I filed a request on 15 Sep).  We're looking
into an easy way to do this on Debian Etch.

See also

* http://wiki.darcs.net/RepositoryFormats
  The three formats in a nutshell

* http://wiki.darcs.net/DarcsTwo#hashed-repository-format
  More about hashed repositories (covers a lot of the same stuff Jason did)

* http://lists.osuosl.org/pipermail/darcs-users/2010-August/024941.html
  Discussion on eventually retiring support for old-fashioned repositories

  I can guarantee that at least Darcs 2.5 (the upcoming release) will
  continue to provide full support for old-fashioned repositories. But
  they are going away eventually so that we can focus on making Darcs
  better.

Thanks!

-- 
Eric Kow 
For a faster response, try +44 (0)1273 64 2905 or
xmpp:ko...@jabber.fr (Jabber or Google Talk only)


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

Re: [Haskell-cafe] Client-extensible heterogeneous types

[John Lato]

>
> From: Jacek Generowicz 
>
> So my question is, what would be the Haskell approach to combining
> heterogeneity (as provided by variant (algebraic) types) with
> type-extensibility (as provided by type classes), without losing the
> benefits of Haskell's type system?
>
> I haven't looked into Template Haskell, but i guess that it is likely
> to provide a solution.
> But is there a solution in plain Haskell?
>

It's not plain Haskell, but I'm surprised nobody mentioned the
ExistentialQuantification extension, which unless I'm missing something
provides exactly what you want.

John
___
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

[Sebastiaan Visser]

Gregory,

I use arrows (especially list arrows) in a lot of my projects and find them 
(after some training) easier to work with than monands. Code that I write 
point-free using arrows generally contains fewer bugs than code I write in 
monadic style.

On Oct 11, 2010, at 8:48 PM, Gregory Crosswhite wrote:
> 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.

I think it is unfair to say that arrows add complexity over monads. This 
statement can only be true to people who actually know monads and do not know 
arrows. This has more to do with the direction of one's knowledge than the 
'complexity' (whatever this means) of a programming abstraction.

Don't see arrows a less restricted monads, see them as a generalization of 
functions, than it will all make sense. Use them in situations that need 
generalization of functions, not in cases that require the power of monads.

>> 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.

I'd rather use (.) for composition of expressions than (<=<) and I'd rather use 
the 'id' for identity than return. Writing my arrow computations point-free as 
if they were functions feels far less clumsy and a far more readable than 
monadic style.

>> 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.

This restriction, though not always, can be very useful. This restriction 
allows you to do full inspection of the arrow expression. This inspection can 
in some cases be used to serialize an arrow computation of statically optimize 
it to a more efficient form.

When you don't need the power of Monads (or ArrowApply) why use a formalism 
that does provide this power? That will only make it harder to reason about 
your program, which isn't quite the Haskell way.

> 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 fi

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

[John Lato]

On Mon, Oct 11, 2010 at 3:24 PM, Michael Snoyman wrote:

> 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.
>

I generally agree on this point, however having a profile on the homepage
(even if it is randomly selected) provides a great deal of publicity and
legitimacy to that profile (as much as haskellers.com can provide!).  I
think this should be equally available to users who for whatever reason do
not wish to share a photo image.


>
> 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.


That seems to be reasonable.  Although this is only an issue if there's some
sort of real-image restriction to the functionality of haskellers.com.  I
don't think the implementation should be difficult once the policy is
decided.

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

Re: [Haskell-cafe] pointers for EDSL design

[Dominique Devriese]

2010/10/12  :
>> 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"...  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.
>
> I guess you are using what I call `the initial embedding' of an object
> language. Somehow I prefer the final embedding.

No. In the library, I use both embedding styles for different
purposes, but what I was referring to here (the construction of
production rules) is actually implemented using what you call a typed
tagless-final embedding. I see the technique as an encoding of
*recursion* in a typed tagless final object language in such a way
that the recursion is observable in the host language.

Suppose you have the following (logically inconsistent ;)) code (in
Haskell notation):
  term1 :: Int
  term1 = if term2 then 1 else 2
  term2 :: Bool
  term2 = term1 == 2

and you want to model it in the typed tagless final encoding of simply
typed lambda calculus from the examples in your online typed tagless
final lecture notes [1] extended with implicit arbitrary recursion.
Then you could do

  data Term1
  data Term2

  data TermDomain ix where
   Term1 :: TermDomain Term1
   Term2 :: TermDomain Term2

  data family TermVal ix
  newtype instance TermVal Term1 = TV1 {unTV1 :: Int}
  newtype instance TermVal Term2 = TV2 {unTV2 :: Bool}

  class ExtraSymantics repr where
if_ :: repr h Bool -> repr h a -> repr h a -> repr h a
eq_int :: repr h Int -> repr h Int -> repr h Bool

  class RecSymantics repr phi | repr -> phi where
ref :: phi ix -> repr h (TermVal ix)

  terms :: (Functor (repr h), Symantics repr, ExtraSymantics repr,
RecSymantics repr TermDomain) => TermDomain ix -> repr h
(TermVal ix)
  terms Term1 = fmap TV1 $ if_ (fmap unTV2 (ref Term2)) (int 1) (int 2)
  terms Term2 = fmap TV2 $ eq_int (fmap unTV1 (ref Term1)) (int 2)

In this way, the embedding models the object language recursion in
such a way that the recursion remains observable in the host language
because you can implement it the way you want in your RecSymantics
instance. Possible needs for this observable recursion could be that
you want to do some form of recursion depth-bounded evaluation or some
form of static analysis or whatever... Such modifications are
fundamentally impossible if you model object language recursion
naively using direct host language recursion.

For my parsing library, I need these techniques to get a good view on
the recursion in the grammar. This allows me perform grammar
transformations and analysis.

Dominique

Footnotes:
[1]  http://okmij.org/ftp/tagless-final/course/#infin1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Client-extensible heterogeneous types

[Jacek Generowicz]

[Sorry Stephen, didn't mean to take this off-list, hence the resend.]

On 2010 Oct 12, at 14:31, Stephen Tetley wrote:


To do this I would use dynamic types (via Data.Dynamic).


Ah, yes, I've just stumbled upon these while trying to figure out what  
APPLY or FUNCALL would mean in Haskell.



There are more typeful ways to deal with heterogeneous structures[*],
but if "clients can easily extend it with their own new types" you've
pretty much defined what dynamic types solve.


Cool.

I've just started experimenting with implementing the dynamism by  
holding functions (methods) alongside data in a variant type. I think  
I'll see what I learn by taking this a bit further, before digging  
into Data.Dynamic, but it's good to know there is some prior art to  
turn to in the long run.


Many thanks.

Reading the GHC docs on Data.Dynamic, I infer that Data.Dynamic is non- 
standard, but, in principle, portable to other implementations.


Is that understanding correct?


[*] See the HList papers and library and various solutions to the
"expression problem".


This seems to be extremely relevant too, though I think that I'll  
stick to my own experiment and Data.Dynamic to start with.


Thanks very much.

___
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)

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/10 03:37 , Michael Snoyman wrote:
> "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 think you need to decide which community you intend to support, actually.

On the one hand, a professional organization will prefer to have real names,
real pictures, etc.  On the other, if you want to be a central coordinating
spot for the existing Haskell community, many of us are far better known by
nicknames and identicons.

If you want to support both, then perhaps you need multiple "portals", with
people wanting to be identified professionally registering appropriately in
order to show up in the professional portal.  But then you have the
difficulty of how to show content in each portal (for example, a forum
discussion might be cited in the professional forum, but what if some or all
of the contributors were on the community side?  You might show names and
pictures from the professional side and some kind of placeholder for those
not registered professionally, but then you need to worry about the folks
who want to keep their professional and "online" identities separate.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky0XIoACgkQIn7hlCsL25VCsQCfVPHZFM3ZY0syuCQ55P78R5a9
hnkAnimXEzujTNifh5jgwnQyMsrZmwo0
=Fppp
-END PGP SIGNATURE-
___
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

[Uwe Schmidt]

Hi Gregory,

> ...
> 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.

As I understood, John Hughes invented the arrows as a generalisation
of monads, you say it's a less powerful concept. I'm a bit puzzled with
that. Could you explain these different views.

> ...
> 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.

yes, I agree. What about the other combinators (&&&, ***,...)?

> ...
> 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. ...

It's rather easy to define some choice combinators. Or am I
missing the point?

> ...  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.

yes, this a common pattern, a function f' with an extra argument of type a,
and sometimes you want to call f' with some value, e.g. f' 42,
sometimes the extra argument must be computed from the arrow input, let's say 
with an arrow g.

For this case in hxt there is a combinator ($<) with signature

($<) :: (c -> a b d) -> a b c -> a b d

With that combinator you can write

f' $< g

The combinator does the following: The input of the whole arrow
is fed into g, g computes some result and this result together with the
input is used for evaluating f'.  The ($<) is something similar to ($).

> 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
>...

yes, that become rather clumsy.

> ...
> 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.

So, your advice is to throw away the whole arrow stuff in hxt-10 and
redefined (or rename) the combinators on the basis of monads?

Cheers,

  Uwe

___
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

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/10 04:41 , Brandon Moore wrote:
> 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.

It's hard enough to predict execution times for Haskell code at the best of
times :)

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky0V4cACgkQIn7hlCsL25V0VwCg1GrZkqrGU0CswG/KSQvHO+hJ
B2QAn269l6o58G0AeRlyWV9lRTaFF6K6
=6RTp
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Data.Judy

[Tom Doris]

Hi,
Are there any plans to extent the current Data.Judy package to include
bindings to JudySL and JudyHS? There's a standalone binding to JudySL by
Andrew Choi that is usable but it would of course be better to have the
functionality in the Data.Judy package proper.
Thanks
Tom
___
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

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/10 04:06 , 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.

I see your point, but I would be prepared to trust a clean, typesafe (and
especially if it's pure) Haskell implementation over the Cthulhu's-tentacles
that is openssl.  :)

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky0VikACgkQIn7hlCsL25Wt/QCgneAyuCttwnyrHG4vuC22sNBp
Y7gAnAtKUoNekXUb61ISYwnmSkZWJejM
=3+oI
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Client-extensible heterogeneous types

[Stephen Tetley]

To do this I would use dynamic types (via Data.Dynamic).

There are more typeful ways to deal with heterogeneous structures[*],
but if "clients can easily extend it with their own new types" you've
pretty much defined what dynamic types solve.


[*] See the HList papers and library and various solutions to the
"expression problem".
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Client-extensible heterogeneous types

[Jacek Generowicz]

Greetings,

I'm looking for dynamic dispatch on extensible sets of types.

Here is a more detailed explanation of what I mean:



# Consider the following Python code as representative of something
# you might see in Object-Orineted programs in all sorts of languages.

# Create an abstract type

from abc import ABCMeta, abstractmethod

class Abstract:

__metaclass__ = ABCMeta

@abstractmethod
def method(self):
pass

# Provide some reifications of the abstract type

class Variant1(Abstract):
def method(self):
return "Variant 1 stuff"

class Variant2(Abstract):
def method(self):
return "Variant 2 stuff"

# Provide some utilities to process these data

def heterogeneousProcessor(data):
return [datum.method() for datum in data]

# If you wrap all the above up in a library, clients can easily extend
# it with their own new types which will still work within the
# framework

class ClientDefined(Abstract):
def method(self):
return "Client-defined stuff"


heterogeneousContainer = [Variant1(), Variant2(), ClientDefined()]

result = heterogeneousProcessor(heterogeneousContainer)





-- In Haskell, on the one hand, the heterogeneity is easily provided
-- by algebraic data types

data AbstractHeterogeneous = VariantHeterogeneous1 |  
VariantHeterogeneous2


methodHeterogeneous VariantHeterogeneous1 = "Variant 1 stuff"
methodHeterogeneous VariantHeterogeneous2 = "Variant 2 stuff"

heterogeneousProcessor dataa = [methodHeterogeneous datum | datum <-  
dataa]


heterogeneousContainer = [VariantHeterogeneous1, VariantHeterogeneous2]

resultHeterogeneous = heterogeneousProcessor heterogeneousContainer

-- But in order to extend the set of variants, the client would have
-- to modify the source code, changing the definiton of
-- AbstractHeterogeneous and methodHeterogeneous, both of which belong
-- to the library.


-- On the other hand, the extensibility is easily provided by type
-- classes

-- Library code:

class AbstractExtensible a where
methodExtensible :: a -> String

instance AbstractExtensible () where
methodExtensible _ = "Variant 1 stuff"

instance AbstractExtensible Char where
methodExtensible _ = "Variant 2 stuff"

-- Client extension:

instance AbstractExtensible Int where
methodExtensible _ = "Client-defined stuff"

-- but in this case, there is no heterogeneity: you cannot create the
-- equivalent of heterogeneousContainer above

-- heterogeneousExtensibleContainer = 

resultExtensible :: [String]
resultExtensible = [methodExtensible (), methodExtensible 'a',  
methodExtensible (1::Int)]



I can't see a Haskell solution which combines both of these orthogonal
features without losing the benefits of the type system. (For example,
I could create my own, weak, type system with tags to identify the
type and maps to do the dispatch.)

So my question is, what would be the Haskell approach to combining
heterogeneity (as provided by variant (algebraic) types) with
type-extensibility (as provided by type classes), without losing the
benefits of Haskell's type system?

I haven't looked into Template Haskell, but i guess that it is likely  
to provide a solution.

But is there a solution in plain Haskell?

Thanks.

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

Re: [Haskell-cafe] Re: Eta-expansion destroys memoization?

[Derek Elkins]

On Tue, Oct 12, 2010 at 4:34 AM, Bertram Felgenhauer
 wrote:
> Simon Marlow wrote:
>> Interesting.  You're absolutely right, GHC doesn't respect the
>> report, on something as basic as sections!  The translation we use
>> is
>>
>>   (e op)  ==>  (op) e
>>
>> once upon a time, when the translation in the report was originally
>> written (before seq was added) this would have been exactly
>> identical to \x -> e op x, so the definition in the report was
>> probably used for consistency with left sections.
>>
>> We could make GHC respect the report, but we'd have to use
>>
>>   (e op)  ==>  let z = e in \x -> z op x
>>
>> to retain sharing without relying on full laziness.
>
> We should keep in mind that this was changed deliberately in ghc 6.6,
> in order to support "postfix" operators.
>
>    http://www.haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html
>
> The motivating example was the factorial operator which can currently
> be written as  (n !)  in ghc-Haskell.

>From 
>http://www.haskell.org/ghc/docs/6.6/html/users_guide/syntax-extns.html#postfix-operators
"Since this extension goes beyond Haskell 98, it should really be
enabled by a flag; but in fact it is enabled all the time. (No Haskell
98 programs change their behaviour, of course.) "

Which is not true, but is probably true enough.

Of course, there is now a flag
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#postfix-operators
but it seems that the non-standard interpretation of (e !) is still
kept even without it.  Without the flag, it type checks as if you had
written \x -> e ! x but it still behaves as if you had written (!) e.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] a couple of cabal related questions

[Magnus Therning]

On Tue, Oct 12, 2010 at 10:20, Dmitry V'yal  wrote:
> Hello,
>
> recently I've cabalized my program and it brought some problems.
>
> First of all, I made use of 'import Paths_' functionality to
> get the path of installed data files. It works great, but now I can no
> longer run my program in ghci because this module is auto-generated by
> cabal. I tried to supply my own. This way ghci works, but my stub module
> gets compiled into the binary in place of auto-generated. And things break
> again. What's the best way to overcome it?

Create a file called .ghci in the directory where you run ghci and
make it contains something like this:

:set -idist/build/autogen

> And another question. I'd like to make my program output it's version
> string. Of course, I can hardcode it into sources, but I've already
> specified one in the cabal file. Is there any way to get it back in the run
> time?

It's in Paths_ as the variable 'version'.

/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

[Haskell-cafe] a couple of cabal related questions

[Dmitry V'yal]

Hello,

recently I've cabalized my program and it brought some problems.

First of all, I made use of 'import Paths_' functionality 
to get the path of installed data files. It works great, but now I can 
no longer run my program in ghci because this module is auto-generated 
by cabal. I tried to supply my own. This way ghci works, but my stub 
module gets compiled into the binary in place of auto-generated. And 
things break again. What's the best way to overcome it?


And another question. I'd like to make my program output it's version 
string. Of course, I can hardcode it into sources, but I've already 
specified one in the cabal file. Is there any way to get it back in the 
run time?


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

Re: [Haskell-cafe] Desired behaviour of rounding etc.

[Simon Marlow]

On 09/10/2010 10:07, Daniel Fischer wrote:

On Saturday 09 October 2010 06:34:32, Lennart Augustsson wrote:

That code is incorrect.  You can't assume that the base for floating
point numbers is 2, that's something you have to check.
(POWER6 and z9 has hardware support for base 10 floating point.)

   -- Lennart


Well, in light of

-- We assume that FLT_RADIX is 2 so that we can use more efficient code
#if FLT_RADIX != 2
#error FLT_RADIX must be 2
#endif
 properFraction (F# x#)
   = case decodeFloat_Int# x# of
 (# m#, n# #) ->
 let m = I# m#
 n = I# n#
 in
 if n>= 0
 then (fromIntegral m * (2 ^ n), 0.0)

appearing in the RealFrac instance for Float, I thought it would be a safe
optimisation to use for Float and Double in GHC.Float (oddly, FLT_RADIX ==
2 is only used for Float, not for Double).

I can of course wrap the base 2 code in an "#if FLT_RADIX == 2" and have
general code for other bases, but as long as the #error stays, that seems
superfluous.


Making the assumption is fine (as we do in the code above), but the 
important thing is to make the build fail in a very noisy way if the 
assumption turns out to be wrong (as above).


Cheers,
Simon





On Fri, Oct 8, 2010 at 2:08 PM, Daniel Fischer

wrote:

The methods of the RealFrac class produce garbage when the value lies
outside the range of the target type, e.g.

Prelude GHC.Float>  truncate 1.234e11 :: Int  -- 32-bits
-1154051584

and, in the case of truncate, different garbage when the rewrite rule
fires:

Prelude GHC.Float>  double2Int 1.234e11
-2147483648

I'm currently working on faster implementations of properFraction,
truncate, round, ceiling and floor for Float and Double, so I'd like
to know

- does it matter at all what garbage is returned in the above case?
- if it does, what is the desired behaviour (at least for Int, I can't
cater for all possibilities)?


On a related note, in my benchmarks,

truncFloatGen :: Integral a =>  Float ->  a
truncFloatGen = fromInteger . truncFloatInteger

truncFloatInteger :: Float ->  Integer
truncFloatInteger x =
  case decodeFloat x of
(m,e) | e == 0  ->  m
  | e<  0   ->
let s = -e
in if m<  0
  then - ((-m) `shiftR` s)
  else m `shiftR` s
  | otherwise ->  m `shiftL` e

is more than twice as fast as GHC.Float.float2Int, the corresponding
for Double almost twice as fast as double2Int.

Can anybody confirm that the above is faster than float2Int on other
machines/architectures?

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


___
Libraries mailing list
librar...@haskell.org
http://www.haskell.org/mailman/listinfo/libraries


___
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

[Joachim Breitner]

Hi,

Am Dienstag, den 12.10.2010, 16:42 +1100 schrieb 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

note that people expect "cmd --help" to at least do nothing. So if your
program is called "launchMissiles", please make it at least spit out a
message like "your evil dictator was too lazy to write a help message"
when it is called with --help.

(That is if you are sharing your program. Not sure if you should share
"launchMissiles" at all.)

Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: m...@joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
  Jabber-ID: nome...@joachim-breitner.de


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: [Haskell-cafe] Re: Eta-expansion destroys memoization?

[Bertram Felgenhauer]

Simon Marlow wrote:
> Interesting.  You're absolutely right, GHC doesn't respect the
> report, on something as basic as sections!  The translation we use
> is
> 
>   (e op)  ==>  (op) e
> 
> once upon a time, when the translation in the report was originally
> written (before seq was added) this would have been exactly
> identical to \x -> e op x, so the definition in the report was
> probably used for consistency with left sections.
> 
> We could make GHC respect the report, but we'd have to use
> 
>   (e op)  ==>  let z = e in \x -> z op x
> 
> to retain sharing without relying on full laziness.

We should keep in mind that this was changed deliberately in ghc 6.6,
in order to support "postfix" operators.

http://www.haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html

The motivating example was the factorial operator which can currently
be written as  (n !)  in ghc-Haskell.

Cheers,

Bertram
___
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]

>> 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)

You can already do this with CmdArgs. If you use cmdArgsMode/process
it returns a structure populated to say what to do next (i.e. display
a help message), but you are welcome to do something different, or do
what it says in a different way. However, I can see some people might
want to remove help entirely, so I'll try and find a balance.

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