Re: [Haskell-cafe] [Off-topic] How unimportant it is whether submarines can swim (EWD1056)

[Kim-Ee Yeoh]

On Sun, Oct 28, 2012 at 11:29 AM, Rustom Mody  wrote:

> In particular, there is one small notational point that he insisted on
> towards the end of his career (and life) viz. where traditional
> mathematicians write *f(x)  *and functional programmers write *f x*, he
> would write *f.x* , ie he showed apply with a '.'
>
> In trying to understand his intentions, I wrote the following
> 'thought-dialogue' [as in thought-experiment :-) ]
> http://www.the-magus.in/Publications/ewd.pdf
>

I didn't read all of it, but near the end when "EWD" made the point about
how function application should be a first-class operator and not mere
whitespace, "Haskeller" missed a golden opportunity to segue into
applicative functors.

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

Re: [Haskell-cafe] Optimal line length for haskell

[Alexander Solla]

On Mon, Oct 29, 2012 at 4:09 PM, Richard O'Keefe  wrote:

>
> On 30/10/2012, at 3:28 AM, Alexander Solla wrote:
> > On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky 
> wrote:
> > In any language, a line longer than 80 characters usually (but not
> > always) suggests that you might want to stop and rethink your design. In
> > many cases a refactoring or two will greatly simplify the code and
> > reduce your line length as a result.
> >
> > I disagree.  That might be true for imperative languages, where width is
> indicative of deep nesting and its associated problems.  But it is not true
> for a functional language, where it is merely indicative of a wide "normal
> form".  Yes, the normal form can sometimes be refactored, but to what end?
>
> Better code?  I have no idea of what "a wide normal form" might be, and
> less
> idea of why that would imply that a narrower and better form does not also
> exist.


I made no implication that narrower forms are not useful, or even better,
given that the structure is not incompatible with the syntax used to
implement it.  (For example, I would much rather [1,2,3,4,5] over

> [1
> ,2
> ,3
> ,4
> ,5
> ]

but would likely prefer

> [ "alpha"
> , "beta"
..
> , "omega"
> ]

over the alternative.

For example, I generally prefer using the combinators directly when dealing
with functors, applicatives, and monads.  This can be written "wide", but
it can also be written in the style of:

> f' = f <$> (a >>= g)
><*> (b >>= h)
><*> (c >>= i >>= k)

That is perfectly sensible.  But if I had to repeat this syntactic
construct, I would probably do it wide:

> f' = f <$> (a >>= g) <*> (b >>= h) <*> (c >>= i >>= k)
> g' = g <$> (d >>= g) <*> (e >>= h) <*> (f >>= i >>= k)

The new row exposes a sort of "tabular" structure.

This code is easy to edit, all at once, highlights differences, and exposes
similarities that might be hidden if written in stanza format and have
enough "rows" in that format.

Of course, a "normal form" merely a combinator, or rather, its definiens.

So one might ask, why not factor this out into a combinator?  That might
well be appropriate, or it might not.  Either way, your program end up with
a table for values which may vary (since, presumably, the definitions of f'
and g' witness that you want to define f' and g'.), as in:

> f' = comb f a b c
> g' = comb g d e f

This cannot be made any narrower (up to naming). We  can call a normal form
n-wide if its combinator requires n arguments.

How many combinators do we really want?  A combinator is what it will take
to factor the "wideness" out of a tabular form, and all you get is a maybe
narrower tabular form.

My own perspective is that if I can't fit it onto one slide in large
> type for my students to see it is too big.
>

This is fair enough, but there are some types of extremely uninteresting
code that don't go on slides and are naturally expressed as extremely wide
tables.  Typically, it is data for use by the program -- the stuff the
program traverses to output its answer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Teaching Haskell @ MOOCs like Coursera or Udacity

[niket]

Hi Kris,

You have highlighted a very important point by talking about real life
projects and the way they differ from "core" haskell.

When I got inspired by Martin Odersky's Coursera Scala course and wished
the same for Haskell, I meant the following:

1. Great and in depth set of exercises and feedback/evaluation platform.
2. Real life haskell extensions and relevant exercises.
3. Structured and organized course. The current list of things on wiki is
wonderful but are they helping newcomers? Frankly speaking, it didn't help
me. How can we stop putting newcomers like me on crossroads of haskell
learning?

Thanks,
Niket


On Fri, Oct 26, 2012 at 2:46 AM, Kristopher Micinski  wrote:

> On Thu, Oct 25, 2012 at 4:57 PM, Gregg Lebovitz 
> wrote:
> > I am trying to get a learning center started in the Haskell community. As
> > pointed out below, MOOCs are hard to put together, however training and
> > videos straight forward. There is a lot of teaching material available in
> > the community. It is a matter of finding, organizing and curating it.
> >
>
> At the same time the Haskell wiki and Oleg's site taken together
> constitute a good amount of learning material in a semi organized
> fashion.  These aren't replacements or implementations of your idea
> but they come pretty close (to the point that I could spend quite a
> while on the combinations of those and still feel unfinished..).  I
> think the Haskell wikibook also does a good amount to address further
> concepts in Haskell.  There have been tons of great FP books written
> over the years, many of which aren't even frequently mentioned by
> people, but at the same time nothing helps like actually using it in
> your own personal projects, I haven't seen so much elaboration on
> *this* point.  (For example, doing this would probably mean talking
> about a set of parser combinators, some script-y haskell libraries, a
> web framework, etc...)
>
> Interesting quote:
> After all, if we didn’t need teachers, then we could earn our
> undergraduate degrees by spending four years in the library.
>
> Is this not what most people do?  I know that was certainly my experience
> :-).
>
> One problem with Haskell: the language moves fast.  "Core Haskell"
> isn't all that hard, but if you open any real Haskell project, it's
> going to use advanced (sometimes unstable) extensions that aren't
> going to be in your book or web guide, making some people feel stuck.
> These concepts aren't necessarily difficult, but if you actually want
> to use Haskell you need to face the more popular language extensions.
> Off the top of my head, existential types, arrows, higher kinds, all
> stick out to me as being things you see in most code, along with (of
> course) monad transformer stacks that will scare off newcomers and
> aren't explained in any cohesive context other than the Haskell
> wiki...
>
> kris
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Safe lens?

[Greg Fitzgerald]

Works great.  Thanks for the quick work!

-Greg


On Mon, Oct 29, 2012 at 2:46 PM, Edward Kmett  wrote:
> I fixed it. Version 3.0.6 was just uploaded to hackage and is appropriately
> Trustworthy where needed.
>
> Please let me know if I missed flagged anything you need flagged, or
> mis-flagged anything you think shouldn't be. ;)
>
>
> On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan  wrote:
>>
>> It happened somewhere between 2.6 and 2.7:
>>
>>
>> http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
>>
>> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
>>
>> The strange thing is that the only internal dependency of 2.7.0.1,
>> Control.Lens.Isomorphic, is still "Safe-Infered" (this spelling error
>> should probably be fixed)
>>
>>
>> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
>>
>> It'd be pretty fancy if Safe Haskell could give reasons for "None" /
>> tell what would have made it unsafe in the event of "Trustworthy".
>> Particularly fancy if integrated into the haddocks.
>>
>> -mgsloan
>>
>> On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett  wrote:
>> > Actually Control.Lens.Getter doesn't use TH. The issue is more that it
>> > depends on some modules I didn't flag as Trustworthy and which require
>> > some
>> > more high-falutin type system extensions that GHC isn't happy about
>> > treating
>> > as Safe. I'll try adding a few Trustworthy flags.
>> >
>> > It previously was treated as Trustworthy or SafeInfered throughout.
>> >
>> > Somewhere along the way I must have toggled on an extension and broken
>> > that
>> > property.
>> >
>> > -Edward
>> >
>> >
>> > On Mon, Oct 29, 2012 at 1:14 PM, Petr P  wrote:
>> >>
>> >>   Hi
>> >>
>> >> I believe the reason is that it uses TemplateHaskell for automatic
>> >> derivation of labels. And TemplateHaskell is of course unsafe, since
>> >> it could convert your code into something entirely different.
>> >>
>> >>   Best regards,
>> >>   Petr Pudlak
>> >>
>> >> 2012/10/29 Greg Fitzgerald :
>> >> > Why are getters from the 'lens' package unsafe?  Is there a subset
>> >> > like Data.Label.Pure from 'fclabels' that can be imported safely?
>> >> >
>> >> >
>> >> > $ cat a.hs
>> >> > {-# LANGUAGE Safe #-}
>> >> >
>> >> > import Control.Lens.Getter
>> >> >
>> >> > main = print 123
>> >> >
>> >> > $ runghc a.hs
>> >> >
>> >> > a.hs:3:1:
>> >> > Control.Lens.Getter: Can't be safely imported!
>> >> > The module itself isn't safe.
>> >> >
>> >> >
>> >> > Thanks,
>> >> > Greg
>> >> >
>> >> > ___
>> >> > Haskell-Cafe mailing list
>> >> > Haskell-Cafe@haskell.org
>> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >>
>> >> ___
>> >> Haskell-Cafe mailing list
>> >> Haskell-Cafe@haskell.org
>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

Re: [Haskell-cafe] Segment Tree based Set

[Tony Morris]

Yeah that looks useful indeed. I am surprised there isn't a DIET on hackage.

On Tue, Oct 30, 2012 at 3:55 AM, Stephen Tetley wrote:

> Are Martin Erwig's "diets" anything close?
>
> http://web.engr.oregonstate.edu/~erwig/diet/
>
> On 29 October 2012 04:48, Tony Morris  wrote:
> > Hi,
> > I was wondering if anyone knows of a package implementing a fast lookup
> > for an element in ranges.
> >
> > For example, this operation:
> > Ord a => a -> [(a, a)] -> Bool
> >
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC maintenance on Arch

[Fabio Riga]

2012/10/29  :
> To be clear, the project ArchHaskell has little or no relation to my
> original post.  If I understand correctly, ArchHaskell is a set of Arch uses
> who attempted to repackage the packages in hackage in the AUR.
Not exactly. ArchHaskell try to keep an ArchLinux repository of
Haskell package without the dependency mess that pop out from using
cabal install.

> addresses issues of package management that are unrelated to my complaint.
> My complaint is that Arch currently does not support having two versions of
> GHC installed and GHC does not support backwards compatibility.  The current
> method of always updating GHC to the latest version, discarding the old
> version is useful to the most hard core bleeding edge types.  An alternative
> model for those of us that need a consistently usable system is not well
> supported.  Currently updating ghc the "normal way" always breaks your build
> system.  Arch has addressed this issue with a number of other packages.
> Perhaps the best comparison would be
> ghc verse
> linux.  With linux, we
> have a "linux" package and a
> "linux-lts"
> package.  These are the same, but linux-lts gets updated slightly less often
> and with less expedition.  This problem has been had in Arch, it's been
> solved, and we should take the example of these other cases I have provided
> and make two ghc packages, so that there is a standard supported sane way to
> use ghc on arch linux.  This isn't a problem that affects me personally
> these days. As an advanced user I don't really have any trouble working
> around the issue.  But I'd like Arch to be inviting to newbies and to have
> what most of us more experienced users implement manually by default.

I think ArchLinux is about bleeding edge types. It is normal for Arch
to have the latest stable version available in repository. And ghc is
not the kernel. For example Arch has ruby-1.9, while many other
distros still use 1.8. But if you do need ghc-7.4 and you don't want
to deal with upgrades of every Haskell library you use, you can always
install haskell-platform and use cabal for the needed libraries. But
when you'll want to update to the next haskell-platform version (or
whatever you define as "stable"), you'll have to remove and reinstall
everything. Having Arch packages makes this process smoother.

Fabio

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

Re: [Haskell-cafe] Optimal line length for haskell

[Richard O'Keefe]

On 30/10/2012, at 3:28 AM, Alexander Solla wrote:
> On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky  
> wrote:
> In any language, a line longer than 80 characters usually (but not
> always) suggests that you might want to stop and rethink your design. In
> many cases a refactoring or two will greatly simplify the code and
> reduce your line length as a result.
> 
> I disagree.  That might be true for imperative languages, where width is 
> indicative of deep nesting and its associated problems.  But it is not true 
> for a functional language, where it is merely indicative of a wide "normal 
> form".  Yes, the normal form can sometimes be refactored, but to what end?

Better code?  I have no idea of what "a wide normal form" might be, and less
idea of why that would imply that a narrower and better form does not also
exist.

We can argue till everyone is sick and tired and still not reach any
kind of consensus.  Let's have some *examples*.

(For the record, the longest line lengths I've ever seen have been in
C++ and Java.  I know someone who, and I am not kidding, thinks a 390-
column line in code intended to be read by other people is OK.)

My own perspective is that if I can't fit it onto one slide in large
type for my students to see it is too big.


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

[Haskell-cafe] Empirically comparing strict vs. lazy evaluation

[Kristopher Micinski]

Hello Haskellers!

I wonder if you know of benchmarks that attempt to compare,
empirically, lazy vs. eager evaluation.  Pointers to papers and/or
code would be most appreciated.

Our group (at UMD) is working on a paper that develops some technology
for lazy programs, and we would like to choose benchmarks for
evaluating it that span the gamut of computations that perform well
when done lazily, vs. those that do not perform as well when evaluated
lazily. Then we want to look at the best case and worst case for our
technology WRT laziness, and see how it stacks up.

Thanks in advance for any ideas you have!

Kris Micinski

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

[Haskell-cafe] ICFP 2013: Call for workshops and co-located events

[David Van Horn]

 CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS
ICFP 2013
 18th ACM SIGPLAN International Conference on Functional Programming
 September 22 - 28, 2013
   Boston, Massachusetts, USA
   http://icfpconference.org/icfp2013/

The 18th ACM SIGPLAN International Conference on Functional
Programming will be held in Boston, Massachusetts on September 22-28,
2013.  ICFP provides a forum for researchers and developers to hear
about the latest work on the design, implementations, principles, and
uses of functional programming.

Proposals are invited for workshops (and other co-located events, such
as tutorials) to be affiliated with ICFP 2013 and sponsored by
SIGPLAN.  These events should be more informal and focused than ICFP
itself, include sessions that enable interaction among the attendees,
and foster the exchange of new ideas.  The preference is for one-day
events, but other schedules can also be considered.

The workshops are scheduled to occur on September 22-24 (the three
days before ICFP) and September 28 (the day after ICFP).

--

Submission details
 Deadline for submission: December  7, 2012
 Notification of acceptance:  January   7, 2013

Prospective organizers of workshops or other co-located events are
invited to submit a completed workshop proposal form in plain text
format to the ICFP 2013 workshop co-chairs (Patrik Jansson and
Sam Tobin-Hochstadt), via email to icfp13-worksh...@ccs.neu.edu
by December 7, 2012.  (For proposals of co-located events other
than workshops, please fill in the workshop proposal form and just
leave blank any sections that do not apply.)  Please note that this
is a firm deadline.

Organizers will be notified if their event proposal is accepted by
January 7, 2013, and if successful, depending on the event, they
will be asked to produce a final report after the event has taken
place that is suitable for publication in SIGPLAN Notices.

The proposal form is available at:

http://www.icfpconference.org/icfp2013/icfp13-workshops-form.txt

Further information about SIGPLAN sponsorship is available at:

http://acm.org/sigplan/sigplan_workshop_proposal.htm

--

Selection committee

The proposals will be evaluated by a committee comprising the
following members of the ICFP 2013 organizing committee, together with
the members of the SIGPLAN executive committee.

 Workshop Co-Chair: Patrik Jansson  (Chalmers University of Technology)
 Workshop Co-Chair: Sam Tobin-Hochstadt   (Northeastern University)
 General Chair :Greg Morrisset (Harvard University)
 Program Chair: Tarmo Uustalu(Tallinn University of Technology)


--

Further information

Any queries should be addressed to the workshop co-chairs (Patrik Jansson and
Sam Tobin-Hochstadt), via email to icfp13-worksh...@ccs.neu.edu

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

Re: [Haskell-cafe] Safe lens?

[Edward Kmett]

We picked up some extensions along the way in the dependency, so that went
to None, then the things that depended on it devolved from SafeInferred to
None as well.

-Edward

On Mon, Oct 29, 2012 at 5:54 PM, Michael Sloan  wrote:

> I guess that's a good way to safeguard against future accidental
> toggleage.  Still, it's puzzling that the status of "Safe-Infered" was
> lost.
>
> On Mon, Oct 29, 2012 at 2:46 PM, Edward Kmett  wrote:
> > I fixed it. Version 3.0.6 was just uploaded to hackage and is
> appropriately
> > Trustworthy where needed.
> >
> > Please let me know if I missed flagged anything you need flagged, or
> > mis-flagged anything you think shouldn't be. ;)
> >
> >
> > On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan 
> wrote:
> >>
> >> It happened somewhere between 2.6 and 2.7:
> >>
> >>
> >>
> http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
> >>
> >>
> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
> >>
> >> The strange thing is that the only internal dependency of 2.7.0.1,
> >> Control.Lens.Isomorphic, is still "Safe-Infered" (this spelling error
> >> should probably be fixed)
> >>
> >>
> >>
> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
> >>
> >> It'd be pretty fancy if Safe Haskell could give reasons for "None" /
> >> tell what would have made it unsafe in the event of "Trustworthy".
> >> Particularly fancy if integrated into the haddocks.
> >>
> >> -mgsloan
> >>
> >> On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett  wrote:
> >> > Actually Control.Lens.Getter doesn't use TH. The issue is more that it
> >> > depends on some modules I didn't flag as Trustworthy and which require
> >> > some
> >> > more high-falutin type system extensions that GHC isn't happy about
> >> > treating
> >> > as Safe. I'll try adding a few Trustworthy flags.
> >> >
> >> > It previously was treated as Trustworthy or SafeInfered throughout.
> >> >
> >> > Somewhere along the way I must have toggled on an extension and broken
> >> > that
> >> > property.
> >> >
> >> > -Edward
> >> >
> >> >
> >> > On Mon, Oct 29, 2012 at 1:14 PM, Petr P  wrote:
> >> >>
> >> >>   Hi
> >> >>
> >> >> I believe the reason is that it uses TemplateHaskell for automatic
> >> >> derivation of labels. And TemplateHaskell is of course unsafe, since
> >> >> it could convert your code into something entirely different.
> >> >>
> >> >>   Best regards,
> >> >>   Petr Pudlak
> >> >>
> >> >> 2012/10/29 Greg Fitzgerald :
> >> >> > Why are getters from the 'lens' package unsafe?  Is there a subset
> >> >> > like Data.Label.Pure from 'fclabels' that can be imported safely?
> >> >> >
> >> >> >
> >> >> > $ cat a.hs
> >> >> > {-# LANGUAGE Safe #-}
> >> >> >
> >> >> > import Control.Lens.Getter
> >> >> >
> >> >> > main = print 123
> >> >> >
> >> >> > $ runghc a.hs
> >> >> >
> >> >> > a.hs:3:1:
> >> >> > Control.Lens.Getter: Can't be safely imported!
> >> >> > The module itself isn't safe.
> >> >> >
> >> >> >
> >> >> > Thanks,
> >> >> > Greg
> >> >> >
> >> >> > ___
> >> >> > Haskell-Cafe mailing list
> >> >> > Haskell-Cafe@haskell.org
> >> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >>
> >> >> ___
> >> >> Haskell-Cafe mailing list
> >> >> Haskell-Cafe@haskell.org
> >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >> >
> >> >
> >> > ___
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe@haskell.org
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >
> >
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Safe lens?

[Michael Sloan]

I guess that's a good way to safeguard against future accidental
toggleage.  Still, it's puzzling that the status of "Safe-Infered" was
lost.

On Mon, Oct 29, 2012 at 2:46 PM, Edward Kmett  wrote:
> I fixed it. Version 3.0.6 was just uploaded to hackage and is appropriately
> Trustworthy where needed.
>
> Please let me know if I missed flagged anything you need flagged, or
> mis-flagged anything you think shouldn't be. ;)
>
>
> On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan  wrote:
>>
>> It happened somewhere between 2.6 and 2.7:
>>
>>
>> http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
>>
>> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
>>
>> The strange thing is that the only internal dependency of 2.7.0.1,
>> Control.Lens.Isomorphic, is still "Safe-Infered" (this spelling error
>> should probably be fixed)
>>
>>
>> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
>>
>> It'd be pretty fancy if Safe Haskell could give reasons for "None" /
>> tell what would have made it unsafe in the event of "Trustworthy".
>> Particularly fancy if integrated into the haddocks.
>>
>> -mgsloan
>>
>> On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett  wrote:
>> > Actually Control.Lens.Getter doesn't use TH. The issue is more that it
>> > depends on some modules I didn't flag as Trustworthy and which require
>> > some
>> > more high-falutin type system extensions that GHC isn't happy about
>> > treating
>> > as Safe. I'll try adding a few Trustworthy flags.
>> >
>> > It previously was treated as Trustworthy or SafeInfered throughout.
>> >
>> > Somewhere along the way I must have toggled on an extension and broken
>> > that
>> > property.
>> >
>> > -Edward
>> >
>> >
>> > On Mon, Oct 29, 2012 at 1:14 PM, Petr P  wrote:
>> >>
>> >>   Hi
>> >>
>> >> I believe the reason is that it uses TemplateHaskell for automatic
>> >> derivation of labels. And TemplateHaskell is of course unsafe, since
>> >> it could convert your code into something entirely different.
>> >>
>> >>   Best regards,
>> >>   Petr Pudlak
>> >>
>> >> 2012/10/29 Greg Fitzgerald :
>> >> > Why are getters from the 'lens' package unsafe?  Is there a subset
>> >> > like Data.Label.Pure from 'fclabels' that can be imported safely?
>> >> >
>> >> >
>> >> > $ cat a.hs
>> >> > {-# LANGUAGE Safe #-}
>> >> >
>> >> > import Control.Lens.Getter
>> >> >
>> >> > main = print 123
>> >> >
>> >> > $ runghc a.hs
>> >> >
>> >> > a.hs:3:1:
>> >> > Control.Lens.Getter: Can't be safely imported!
>> >> > The module itself isn't safe.
>> >> >
>> >> >
>> >> > Thanks,
>> >> > Greg
>> >> >
>> >> > ___
>> >> > Haskell-Cafe mailing list
>> >> > Haskell-Cafe@haskell.org
>> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >>
>> >> ___
>> >> Haskell-Cafe mailing list
>> >> Haskell-Cafe@haskell.org
>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>
>

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

Re: [Haskell-cafe] Safe lens?

[Edward Kmett]

I fixed it. Version 3.0.6 was just uploaded to hackage and is appropriately
Trustworthy where needed.

Please let me know if I missed flagged anything you need flagged, or
mis-flagged anything you think shouldn't be. ;)

On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan  wrote:

> It happened somewhere between 2.6 and 2.7:
>
>
> http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
>
> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
>
> The strange thing is that the only internal dependency of 2.7.0.1,
> Control.Lens.Isomorphic, is still "Safe-Infered" (this spelling error
> should probably be fixed)
>
>
> http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
>
> It'd be pretty fancy if Safe Haskell could give reasons for "None" /
> tell what would have made it unsafe in the event of "Trustworthy".
> Particularly fancy if integrated into the haddocks.
>
> -mgsloan
>
> On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett  wrote:
> > Actually Control.Lens.Getter doesn't use TH. The issue is more that it
> > depends on some modules I didn't flag as Trustworthy and which require
> some
> > more high-falutin type system extensions that GHC isn't happy about
> treating
> > as Safe. I'll try adding a few Trustworthy flags.
> >
> > It previously was treated as Trustworthy or SafeInfered throughout.
> >
> > Somewhere along the way I must have toggled on an extension and broken
> that
> > property.
> >
> > -Edward
> >
> >
> > On Mon, Oct 29, 2012 at 1:14 PM, Petr P  wrote:
> >>
> >>   Hi
> >>
> >> I believe the reason is that it uses TemplateHaskell for automatic
> >> derivation of labels. And TemplateHaskell is of course unsafe, since
> >> it could convert your code into something entirely different.
> >>
> >>   Best regards,
> >>   Petr Pudlak
> >>
> >> 2012/10/29 Greg Fitzgerald :
> >> > Why are getters from the 'lens' package unsafe?  Is there a subset
> >> > like Data.Label.Pure from 'fclabels' that can be imported safely?
> >> >
> >> >
> >> > $ cat a.hs
> >> > {-# LANGUAGE Safe #-}
> >> >
> >> > import Control.Lens.Getter
> >> >
> >> > main = print 123
> >> >
> >> > $ runghc a.hs
> >> >
> >> > a.hs:3:1:
> >> > Control.Lens.Getter: Can't be safely imported!
> >> > The module itself isn't safe.
> >> >
> >> >
> >> > Thanks,
> >> > Greg
> >> >
> >> > ___
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe@haskell.org
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Safe lens?

[Michael Sloan]

It happened somewhere between 2.6 and 2.7:

http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html

The strange thing is that the only internal dependency of 2.7.0.1,
Control.Lens.Isomorphic, is still "Safe-Infered" (this spelling error
should probably be fixed)

http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html

It'd be pretty fancy if Safe Haskell could give reasons for "None" /
tell what would have made it unsafe in the event of "Trustworthy".
Particularly fancy if integrated into the haddocks.

-mgsloan

On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett  wrote:
> Actually Control.Lens.Getter doesn't use TH. The issue is more that it
> depends on some modules I didn't flag as Trustworthy and which require some
> more high-falutin type system extensions that GHC isn't happy about treating
> as Safe. I'll try adding a few Trustworthy flags.
>
> It previously was treated as Trustworthy or SafeInfered throughout.
>
> Somewhere along the way I must have toggled on an extension and broken that
> property.
>
> -Edward
>
>
> On Mon, Oct 29, 2012 at 1:14 PM, Petr P  wrote:
>>
>>   Hi
>>
>> I believe the reason is that it uses TemplateHaskell for automatic
>> derivation of labels. And TemplateHaskell is of course unsafe, since
>> it could convert your code into something entirely different.
>>
>>   Best regards,
>>   Petr Pudlak
>>
>> 2012/10/29 Greg Fitzgerald :
>> > Why are getters from the 'lens' package unsafe?  Is there a subset
>> > like Data.Label.Pure from 'fclabels' that can be imported safely?
>> >
>> >
>> > $ cat a.hs
>> > {-# LANGUAGE Safe #-}
>> >
>> > import Control.Lens.Getter
>> >
>> > main = print 123
>> >
>> > $ runghc a.hs
>> >
>> > a.hs:3:1:
>> > Control.Lens.Getter: Can't be safely imported!
>> > The module itself isn't safe.
>> >
>> >
>> > Thanks,
>> > Greg
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

Re: [Haskell-cafe] Safe lens?

[Edward Kmett]

Actually Control.Lens.Getter doesn't use TH. The issue is more that it
depends on some modules I didn't flag as Trustworthy and which require some
more high-falutin type system extensions that GHC isn't happy about
treating as Safe. I'll try adding a few Trustworthy flags.

It previously was treated as Trustworthy or SafeInfered throughout.

Somewhere along the way I must have toggled on an extension and broken that
property.

-Edward

On Mon, Oct 29, 2012 at 1:14 PM, Petr P  wrote:

>   Hi
>
> I believe the reason is that it uses TemplateHaskell for automatic
> derivation of labels. And TemplateHaskell is of course unsafe, since
> it could convert your code into something entirely different.
>
>   Best regards,
>   Petr Pudlak
>
> 2012/10/29 Greg Fitzgerald :
> > Why are getters from the 'lens' package unsafe?  Is there a subset
> > like Data.Label.Pure from 'fclabels' that can be imported safely?
> >
> >
> > $ cat a.hs
> > {-# LANGUAGE Safe #-}
> >
> > import Control.Lens.Getter
> >
> > main = print 123
> >
> > $ runghc a.hs
> >
> > a.hs:3:1:
> > Control.Lens.Getter: Can't be safely imported!
> > The module itself isn't safe.
> >
> >
> > Thanks,
> > Greg
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimal line length for haskell

[MightyByte]

I frequently find myself wanting to look at one file while coding in
another file so I can see type signatures, data type definitions, etc.
 If I only have one file fullscreen, then I would have to switch back
and forth to refresh my mind with API information.  If your max lines
are sometimes 200 chars, then you're going to have tons of wasted
screen space from all the other lines that aren't 200 characters wide.

On Mon, Oct 29, 2012 at 4:44 PM, Marc Ziegert  wrote:
> O_o
> Those are damn strange reasons to restrict oneself to 80 chars, iMho.
>
> I tend to look at ONE file at a time, on one fullscreen widescreen.
> 100 chars per line is more or less normal; I have my vertical line limit 
> marker set to 100, but only for layout-zen. My lines have sometimes 200 chars 
> length, which causes the less important (long) code not to clutter my 
> overview on the >50 neighbouring lines (~10 functions overview on the left 
> half of the screen). Otherwise, I'd use a browser/Haddock on one part of the 
> screen just to see an overview of the code I'm writing.
>
> I'm now wondering, whether this could have sth to do with my ADD, which I had 
> the first 3 decades of my life (and without whiteboard). I think, I should 
> try to code in a small narrow window of 1/4 of my screen, just to test 
> whether that would (still) be a handicap.
>
> Roman: "academic background"... Funny; my impression about this matter was 
> from the other point of view: Short lines are good for diff/patch files.
>
>
> Are there more people here with ADD (or ADD-history) and long-lines-disorder? 
> Or is that just me?
>
>
> - marc
>
>
>
>
>
>  Original-Nachricht 
>> Datum: Mon, 29 Oct 2012 11:32:29 -0400
>> Von: MightyByte 
>> An: Jake McArthur 
>> CC: Haskell Cafe 
>> Betreff: Re: [Haskell-cafe] Optimal line length for haskell
>
>> I also stick to a pretty rigid 78 characters.  Doing so actually helps
>> me fit more code onto my screen at a time because I usually have two
>> or three columns of open files side by side.  I find that I need this
>> more often than I need to see a single function on a page (thanks to
>> Haskell's traditionally small functions).  But this works for single
>> functions as well because I can open the same file in multiple columns
>> at different locations in the file.
>>
>> "The ideal line length for text layout is based on the physiology of
>> the human eye… At normal reading distance the arc of the visual field
>> is only a few inches – about the width of a well-designed column of
>> text, or about 12 words per line. Research shows that reading slows
>> and retention rates fall as line length begins to exceed the ideal
>> width, because the reader then needs to use the muscles of the eye and
>> neck to track from the end of one line to the beginning of the next
>> line. If the eye must traverse great distances on the page, the reader
>> is easily lost and must hunt for the beginning of the next line.
>> Quantitative studies show that moderate line lengths significantly
>> increase the legibility of text."
>> Web Style Guide – Basic Design Principles for Creating Website
>> Patrick J. Lynch and Sarah Horton
>> 2nd edition, page 97.
>>
>> On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur 
>> wrote:
>> > I stick to 80 columns fairly rigidly. This is not only so that it fits
>> > into narrow windows, but also so that any two subexpressions in the
>> > same expression tend to be close together on my screen, which makes it
>> > easier for me to reason about it. If only it was easy for me to read
>> > and write code on a Hilbert curve... :)
>> >
>> > I don't think long lines indicate a design problem; it's solely a
>> > formatting thing.
>> >
>> > On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody 
>> wrote:
>> >> There was a recent discussion on the python list regarding maximum line
>> >> length.
>> >> It occured to me that beautiful haskell programs tend to be plump (ie
>> have
>> >> long lines) compared to other languages whose programs are 'skinnier'.
>> >> My thoughts on this are at
>> >> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
>> >>
>> >> Are there more striking examples than the lexer from the standard
>> prelude?
>> >> [Or any other thoughts/opinions :-) ]
>> >>
>> >> Thanks,
>> >> Rusi
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> Haskell-Cafe mailing list
>> >> Haskell-Cafe@haskell.org
>> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >>
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
> (in deutsch: http://www.ge

Re: [Haskell-cafe] hsql-mysql encoding issues

[Alexander Bau]

Hi,

> what DB binding should I rather be using?

mongoDB [1] works well (also for data with umlauts) for my feed
aggregator [2].

Best regards,

Alex


[1] http://hackage.haskell.org/package/mongoDB
[2] http://hackage.haskell.org/package/lucienne



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

Re: [Haskell-cafe] Optimal line length for haskell

[Marc Ziegert]

O_o
Those are damn strange reasons to restrict oneself to 80 chars, iMho.

I tend to look at ONE file at a time, on one fullscreen widescreen.
100 chars per line is more or less normal; I have my vertical line limit marker 
set to 100, but only for layout-zen. My lines have sometimes 200 chars length, 
which causes the less important (long) code not to clutter my overview on the 
>50 neighbouring lines (~10 functions overview on the left half of the screen). 
Otherwise, I'd use a browser/Haddock on one part of the screen just to see an 
overview of the code I'm writing.

I'm now wondering, whether this could have sth to do with my ADD, which I had 
the first 3 decades of my life (and without whiteboard). I think, I should try 
to code in a small narrow window of 1/4 of my screen, just to test whether that 
would (still) be a handicap.

Roman: "academic background"... Funny; my impression about this matter was from 
the other point of view: Short lines are good for diff/patch files.


Are there more people here with ADD (or ADD-history) and long-lines-disorder? 
Or is that just me?


- marc





 Original-Nachricht 
> Datum: Mon, 29 Oct 2012 11:32:29 -0400
> Von: MightyByte 
> An: Jake McArthur 
> CC: Haskell Cafe 
> Betreff: Re: [Haskell-cafe] Optimal line length for haskell

> I also stick to a pretty rigid 78 characters.  Doing so actually helps
> me fit more code onto my screen at a time because I usually have two
> or three columns of open files side by side.  I find that I need this
> more often than I need to see a single function on a page (thanks to
> Haskell's traditionally small functions).  But this works for single
> functions as well because I can open the same file in multiple columns
> at different locations in the file.
> 
> "The ideal line length for text layout is based on the physiology of
> the human eye… At normal reading distance the arc of the visual field
> is only a few inches – about the width of a well-designed column of
> text, or about 12 words per line. Research shows that reading slows
> and retention rates fall as line length begins to exceed the ideal
> width, because the reader then needs to use the muscles of the eye and
> neck to track from the end of one line to the beginning of the next
> line. If the eye must traverse great distances on the page, the reader
> is easily lost and must hunt for the beginning of the next line.
> Quantitative studies show that moderate line lengths significantly
> increase the legibility of text."
> Web Style Guide – Basic Design Principles for Creating Website
> Patrick J. Lynch and Sarah Horton
> 2nd edition, page 97.
> 
> On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur 
> wrote:
> > I stick to 80 columns fairly rigidly. This is not only so that it fits
> > into narrow windows, but also so that any two subexpressions in the
> > same expression tend to be close together on my screen, which makes it
> > easier for me to reason about it. If only it was easy for me to read
> > and write code on a Hilbert curve... :)
> >
> > I don't think long lines indicate a design problem; it's solely a
> > formatting thing.
> >
> > On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody 
> wrote:
> >> There was a recent discussion on the python list regarding maximum line
> >> length.
> >> It occured to me that beautiful haskell programs tend to be plump (ie
> have
> >> long lines) compared to other languages whose programs are 'skinnier'.
> >> My thoughts on this are at
> >> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
> >>
> >> Are there more striking examples than the lexer from the standard
> prelude?
> >> [Or any other thoughts/opinions :-) ]
> >>
> >> Thanks,
> >> Rusi
> >>
> >>
> >>
> >>
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
(in deutsch: http://www.gerstbach.at/2004/ascii/)


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

Re: [Haskell-cafe] foldr (.) id

[David Thomas]

"sum" can be a verb, but yeah, "product" can't really, so it probably
makes sense to follow the noun pattern if we're wanting to be
consistent more than brief.

"and" as a noun is unusual, but fwiw dictionary.com says that there's
a noun sense that means "conjunction" in the logical sense, which is
exactly what we're doing here.

On Mon, Oct 29, 2012 at 1:12 PM, Sebastian Fischer  wrote:
>> "(.)/compose" is consistent with "(+)/sum", "(*)/product", "(&&)/and", etc.
>
> "(to) compose" is a verb. "composition" would be consistent with "sum"
> and "product". "and" doesn't fit, though.
>
> Sebastian
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] Safe lens?

[Greg Fitzgerald]

There's no dependency on TH here.  I'm hoping to do the same thing as
I have done with fclabels, which is to have a Trustworthy module that
imports Control.Lens.TH, derive lenses, and then allow all users of
that data type to Safely import only the Getter/Setter modules.  So,
I'm curious:

* Could Control.Lens.Getter have a LANGUAGE dependency it doesn't need?
* Is there something fundamental in the design of lens (compared to
fclabels), that its getters require unsafe language features?
* Maybe the Internal module should be marked Trustworthy?

Thanks,
Greg


On Mon, Oct 29, 2012 at 10:14 AM, Petr P  wrote:
>   Hi
>
> I believe the reason is that it uses TemplateHaskell for automatic
> derivation of labels. And TemplateHaskell is of course unsafe, since
> it could convert your code into something entirely different.
>
>   Best regards,
>   Petr Pudlak
>
> 2012/10/29 Greg Fitzgerald :
>> Why are getters from the 'lens' package unsafe?  Is there a subset
>> like Data.Label.Pure from 'fclabels' that can be imported safely?
>>
>>
>> $ cat a.hs
>> {-# LANGUAGE Safe #-}
>>
>> import Control.Lens.Getter
>>
>> main = print 123
>>
>> $ runghc a.hs
>>
>> a.hs:3:1:
>> Control.Lens.Getter: Can't be safely imported!
>> The module itself isn't safe.
>>
>>
>> Thanks,
>> Greg
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] foldr (.) id

[Sebastian Fischer]

> "(.)/compose" is consistent with "(+)/sum", "(*)/product", "(&&)/and", etc.

"(to) compose" is a verb. "composition" would be consistent with "sum"
and "product". "and" doesn't fit, though.

Sebastian

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

Re: [Haskell-cafe] Safe lens?

[Michael Sloan]

I've never understood this restriction.  Template Haskell cannot
convert your code to something entirely different, only generate code
at splice points.  It seems to me like Safe Haskell should already
have the necessary mechanisms for Safe Template Haskell to be
implemented.

The Safe Haskell docs say "TemplateHaskell — Is particularly
dangerous, as it can cause side effects even at compilation time and
can be used to access constructors of abstract data types."

Also:
"Module boundary control — Haskell code compiled using the safe
language is guaranteed to only access symbols that are publicly
available to it through other modules export lists. An important part
of this is that safe compiled code is not able to examine or create
data values using data constructors that it cannot import. If a module
M establishes some invariants through careful use of its export list
then code compiled using the safe language that imports M is
guaranteed to respect those invariants. Because of this, Template
Haskell and GeneralizedNewtypeDeriving are disabled in the safe
language as they can be used to violate this property. "

This seems like something that could be readily fixed - just make
"reify" throw an error when attempting to inspect non-exported things
when compiling with "-XSafe".  We'd also need to check that the
generated code does not reference things from unsafe modules (as it
can reference things that aren't imported).

I'm not sure why "it can cause side effects even at compile time".  If
the module with the Template Haskell code is -XSafe or -XTrustworthy,
then presumably it does not cause side effects.  One side effect that
could be troublesome is divergence / bottom.  This seems OK to me, as
the user already has to deal with this in runtime code and the errors
aren't very cryptic.

-Michael

On Mon, Oct 29, 2012 at 10:14 AM, Petr P  wrote:
>   Hi
>
> I believe the reason is that it uses TemplateHaskell for automatic
> derivation of labels. And TemplateHaskell is of course unsafe, since
> it could convert your code into something entirely different.
>
>   Best regards,
>   Petr Pudlak
>
> 2012/10/29 Greg Fitzgerald :
>> Why are getters from the 'lens' package unsafe?  Is there a subset
>> like Data.Label.Pure from 'fclabels' that can be imported safely?
>>
>>
>> $ cat a.hs
>> {-# LANGUAGE Safe #-}
>>
>> import Control.Lens.Getter
>>
>> main = print 123
>>
>> $ runghc a.hs
>>
>> a.hs:3:1:
>> Control.Lens.Getter: Can't be safely imported!
>> The module itself isn't safe.
>>
>>
>> Thanks,
>> Greg
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] Segment Tree based Set

[Stephen Tetley]

Are Martin Erwig's "diets" anything close?

http://web.engr.oregonstate.edu/~erwig/diet/

On 29 October 2012 04:48, Tony Morris  wrote:
> Hi,
> I was wondering if anyone knows of a package implementing a fast lookup
> for an element in ranges.
>
> For example, this operation:
> Ord a => a -> [(a, a)] -> Bool
>

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Vagif Verdi]

I fail to see how a fringe bleeding edge linux distro undermines a haskell 
platform.

Arch is bleeding edge. Haskell Platform is not. It is logical for a 
bleeding edge distro to include latest packages.

If you want a good support, use distros that provide such support and 
stability. Last i checked Ubuntu ships haskell platform and not the latest 
ghc.

Having said that, Arch DOES provide easy solution to this problem. Just put 
IgnorePkg in your pacman.conf.

You are complaining on the wrong forum, to the wrong people about the 
behavior natural for a bleeding edge distro.

On Monday, October 29, 2012 6:54:59 AM UTC-7, Brandon Allbery wrote:
>
> On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning 
> 
> > wrote:
>
>> Now I'm going to run the risk of upsetting you quite a bit by being
>> completely blunt.
>>
>
> Indeed.
>  
>
>> You come across in your mail like someone who has thought through your
>> own situation, but fail to see the larger picture.  You do know *your*
>>
>
> May I ask you a question, then?
>
> Does the Haskell Platform have any reason to exist?
>
> Supposedly, the Haskell community backs the Haskell Platform as the way 
> that most users should be using the Platform.  Yet we have here a vendor 
> platform which does not support it, and newcomers who notice this and 
> question it are chastised for not thinking about the needs of other people. 
>  This suggests that the Haskell Platform is unimportant and perhaps 
> disruptive to some significant group of people... is this so?
>
> And then, looking at your own message, I must ask:  have you considered 
> that the Platform is aimed at the great many people who do not have large 
> amounts of expertise maintaining their own personal Haskell ecosystem.  Or 
> are your needs so important that these people must in fact be told to deal?
>
> Or, to phrase in your own words:
>
> You come across in your mail like someone who has thought through your
>> own situation, but fail to see the larger picture.
>
>
> -- 
> brandon s allbery kf8nh   sine nomine 
> associates
> allb...@gmail.com   
> ball...@sinenomine.net 
> unix/linux, openafs, kerberos, infrastructure  
> http://sinenomine.net
>
>  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Safe lens?

[Petr P]

  Hi

I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.

  Best regards,
  Petr Pudlak

2012/10/29 Greg Fitzgerald :
> Why are getters from the 'lens' package unsafe?  Is there a subset
> like Data.Label.Pure from 'fclabels' that can be imported safely?
>
>
> $ cat a.hs
> {-# LANGUAGE Safe #-}
>
> import Control.Lens.Getter
>
> main = print 123
>
> $ runghc a.hs
>
> a.hs:3:1:
> Control.Lens.Getter: Can't be safely imported!
> The module itself isn't safe.
>
>
> Thanks,
> Greg
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Haskell-cafe] Safe lens?

[Greg Fitzgerald]

Why are getters from the 'lens' package unsafe?  Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?


$ cat a.hs
{-# LANGUAGE Safe #-}

import Control.Lens.Getter

main = print 123

$ runghc a.hs

a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.


Thanks,
Greg

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

Re: [Haskell-cafe] Optimal line length for haskell

[Rustom Mody]

On Mon, Oct 29, 2012 at 7:58 PM, Alexander Solla wrote:

>
>
> On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky wrote:
>
>> On 10/29/2012 07:50 AM, Rustom Mody wrote:
>> > There was a recent discussion on the python list regarding maximum line
>> > length.
>> > It occured to me that beautiful haskell programs tend to be plump (ie
>> > have long lines) compared to other languages whose programs are
>> 'skinnier'.
>> > My thoughts on this are at
>> > http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
>> >
>> > Are there more striking examples than the lexer from the standard
>> prelude?
>> > [Or any other thoughts/opinions :-) ]
>>
>> In any language, a line longer than 80 characters usually (but not
>> always) suggests that you might want to stop and rethink your design. In
>> many cases a refactoring or two will greatly simplify the code and
>> reduce your line length as a result.
>
>
> I disagree.  That might be true for imperative languages, where width is
> indicative of deep nesting and its associated problems.  But it is not true
> for a functional language, where it is merely indicative of a wide "normal
> form".  Yes, the normal form can sometimes be refactored, but to what end?
>  You might easily end up refactoring out of the level of abstraction you
> actually want.  Or the wide form might have useful properties, like the
> ability to sort the lines of source code alphanumerically (which would be
> lost if you switched to a stanza-based format)
>
>
>

Interesting points.  In fact my wish for using (when appropriate) a wide
form is related to some hunch about this 'wide normal form'
Can you throw some light on how one may understand that phraset?

Also BTW Ive cleaned up the post again. Since my ineptitude with blogger
was looking like an ineptitude with haskell (which may well be there and
more :-) ) Ive moved the wide code to gist.
I believe the code examples speak differently in this new format


Rusi
-- 

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Peter Simons]

Hi Timothy,

the Haskell community is not the right audience to be addressing these
complaints to. Instead, you should be talking to the ArchLinux developers,
who are responsible for packaging Haskell-related software in the [core]
and [extra] repositories. I am no expert in these matters, but my guess is
that the mailing list

  https://mailman.archlinux.org/mailman/listinfo/arch-dev-public

is more appropriate than haskell-cafe for this thread.

Take care,
Peter


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

Re: [Haskell-cafe] Optimal line length for haskell

[Iustin Pop]

On Mon, Oct 29, 2012 at 03:50:57PM +, Niklas Hambüchen wrote:
> I would prefer to completely ignore line lengths when writing Haskell.
> 
> In general, giving good names to things in where-clauses automatically
> keeps my code "short enough".
> 
> My opinion is that different people like different code layouts, and
> when formatting code in certain ways, we will always have to make
> compromises.
> 
> I would like if there was a layout normal form for storing Haskell code
> - all code presented to humans should be shown just as that human likes
> it best.
> 
> In the future, I would like to work on a personalizable real-time
> formatter that editors can hook into, using haskell-src-exts.

+1 to that; I know that it would indeed increase my productivity…

iustin

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

Re: [Haskell-cafe] Optimal line length for haskell

[Niklas Hambüchen]

I would prefer to completely ignore line lengths when writing Haskell.

In general, giving good names to things in where-clauses automatically
keeps my code "short enough".

My opinion is that different people like different code layouts, and
when formatting code in certain ways, we will always have to make
compromises.

I would like if there was a layout normal form for storing Haskell code
- all code presented to humans should be shown just as that human likes
it best.

In the future, I would like to work on a personalizable real-time
formatter that editors can hook into, using haskell-src-exts.

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

Re: [Haskell-cafe] Optimal line length for haskell

[MightyByte]

I also stick to a pretty rigid 78 characters.  Doing so actually helps
me fit more code onto my screen at a time because I usually have two
or three columns of open files side by side.  I find that I need this
more often than I need to see a single function on a page (thanks to
Haskell's traditionally small functions).  But this works for single
functions as well because I can open the same file in multiple columns
at different locations in the file.

"The ideal line length for text layout is based on the physiology of
the human eye… At normal reading distance the arc of the visual field
is only a few inches – about the width of a well-designed column of
text, or about 12 words per line. Research shows that reading slows
and retention rates fall as line length begins to exceed the ideal
width, because the reader then needs to use the muscles of the eye and
neck to track from the end of one line to the beginning of the next
line. If the eye must traverse great distances on the page, the reader
is easily lost and must hunt for the beginning of the next line.
Quantitative studies show that moderate line lengths significantly
increase the legibility of text."
Web Style Guide – Basic Design Principles for Creating Website
Patrick J. Lynch and Sarah Horton
2nd edition, page 97.

On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur  wrote:
> I stick to 80 columns fairly rigidly. This is not only so that it fits
> into narrow windows, but also so that any two subexpressions in the
> same expression tend to be close together on my screen, which makes it
> easier for me to reason about it. If only it was easy for me to read
> and write code on a Hilbert curve... :)
>
> I don't think long lines indicate a design problem; it's solely a
> formatting thing.
>
> On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody  wrote:
>> There was a recent discussion on the python list regarding maximum line
>> length.
>> It occured to me that beautiful haskell programs tend to be plump (ie have
>> long lines) compared to other languages whose programs are 'skinnier'.
>> My thoughts on this are at
>> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
>>
>> Are there more striking examples than the lexer from the standard prelude?
>> [Or any other thoughts/opinions :-) ]
>>
>> Thanks,
>> Rusi
>>
>>
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] GHC maintenance on Arch

[timothyhobbs]

To be clear, the project ArchHaskell has little or no relation to my 
original post.  If I understand correctly, ArchHaskell is a set of Arch uses
who attempted to repackage the packages in hackage in the AUR.  This 
addresses issues of package management that are unrelated to my complaint.  
My complaint is that Arch currently does not support having two versions of 
GHC installed and GHC does not support backwards compatibility.  The current
method of always updating GHC to the latest version, discarding the old 
version is useful to the most hard core bleeding edge types. An alternative 
model for those of us that need a consistently usable system is not well 
supported.  Currently updating ghc the "normal way" always breaks your build
system.  Arch has addressed this issue with a number of other packages.  
Perhaps the best comparison would be ghc verse linux.  With linux, we have a "linux" package and a "linux-lts" package.  These are the 
same, but linux-lts gets updated slightly less often and with less 
expedition.  This problem has been had in Arch, it's been solved, and we 
should take the example of these other cases I have provided and make two 
ghc packages, so that there is a standard supported sane way to use ghc on 
arch linux.  This isn't a problem that affects me personally these days. As 
an advanced user I don't really have any trouble working around the issue.  
But I'd like Arch to be inviting to newbies and to have what most of us more
experienced users implement manually by default.

Timothy


-- Původní zpráva --
Od: Malcolm Wallace 
Datum: 29. 10. 2012
Předmět: Re: [Haskell-cafe] GHC maintenance on Arch
"I think you will find that the Original Poster did not ask about 
ArchHaskell, but rather about Haskell on the Arch platform. He was 
completely unaware of ArchHaskell as a project. This might be a source of 
some confusion, and help to explain divergent attitudes.

Regards,
Malcolm

On 29 Oct 2012, at 14:41, Magnus Therning wrote:

> Please stay on topic, this is *not* a discussion about Haskell
> Platform[1], it's a discussion on ArchHaskell[2]. Please read up on
> the mailing list archives first, and then, if you still feel there's a
> need to discuss HP in ArchHaskell (which isn't the same thing as Arch
> itself) then please start a new thread.
> 
> /M
> 
> [1]: http://www.haskell.org/platform/(http://www.haskell.org/platform/)
> [2]: https://wiki.archlinux.org/index.php/ArchHaskell
(https://wiki.archlinux.org/index.php/ArchHaskell)
> 
> On Mon, Oct 29, 2012 at 2:53 PM, Brandon Allbery  
wrote:
>> On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning 
>> wrote:
>>> 
>>> Now I'm going to run the risk of upsetting you quite a bit by being
>>> completely blunt.
>> 
>> 
>> Indeed.
>> 
>>> 
>>> You come across in your mail like someone who has thought through your
>>> own situation, but fail to see the larger picture. You do know *your*
>> 
>> 
>> May I ask you a question, then?
>> 
>> Does the Haskell Platform have any reason to exist?
>> 
>> Supposedly, the Haskell community backs the Haskell Platform as the way 
that
>> most users should be using the Platform. Yet we have here a vendor 
platform
>> which does not support it, and newcomers who notice this and question it 
are
>> chastised for not thinking about the needs of other people. This suggests
>> that the Haskell Platform is unimportant and perhaps disruptive to some
>> significant group of people... is this so?
>> 
>> And then, looking at your own message, I must ask: have you considered 
that
>> the Platform is aimed at the great many people who do not have large 
amounts
>> of expertise maintaining their own personal Haskell ecosystem. Or are 
your
>> needs so important that these people must in fact be told to deal?
>> 
>> Or, to phrase in your own words:
>> 
>>> You come across in your mail like someone who has thought through your
>>> own situation, but fail to see the larger picture.
>> 
>> 
>> --
>> brandon s allbery kf8nh sine nomine associates
>> allber...@gmail.com ballb...@sinenomine.net
>> unix/linux, openafs, kerberos, infrastructure http://sinenomine.net
(http://sinenomine.net)
>> 
> 
> 
> 
> -- 
> Magnus Therning OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org jabber: mag...@therning.org
> twitter: magthe http://therning.org/magnus(http://therning.org/magnus)
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
(http://www.haskell.org/mailman/listinfo/haskell-cafe)


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

Re: [Haskell-cafe] Optimal line length for haskell

[Michael Orlitzky]

On 10/29/2012 10:28 AM, Alexander Solla wrote:
> 
> In any language, a line longer than 80 characters usually (but not
> always) suggests that you might want to stop and rethink your design. In
> many cases a refactoring or two will greatly simplify the code and
> reduce your line length as a result.
> 
> 
> I disagree.  That might be true for imperative languages, where width is
> indicative of deep nesting and its associated problems.  But it is not
> true for a functional language, where it is merely indicative of a wide
> "normal form".  Yes, the normal form can sometimes be refactored, but to
> what end?  You might easily end up refactoring out of the level of
> abstraction you actually want.  Or the wide form might have useful
> properties, like the ability to sort the lines of source code
> alphanumerically (which would be lost if you switched to a stanza-based
> format)

Well, I did leave the door open for special cases with "usually (but not
always)." I know I've had to go over 80 chars before with huge constants
or long test names.

If you're willing to sacrifice maintain/readability for some other
property (e.g. source code sortability), then I don't think my point
applies.

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Malcolm Wallace]

I think you will find that the Original Poster did not ask about ArchHaskell, 
but rather about Haskell on the Arch platform.  He was completely unaware of 
ArchHaskell as a project.  This might be a source of some confusion, and help 
to explain divergent attitudes.

Regards,
Malcolm

On 29 Oct 2012, at 14:41, Magnus Therning wrote:

> Please stay on topic, this is *not* a discussion about Haskell
> Platform[1], it's a discussion on ArchHaskell[2].  Please read up on
> the mailing list archives first, and then, if you still feel there's a
> need to discuss HP in ArchHaskell (which isn't the same thing as Arch
> itself) then please start a new thread.
> 
> /M
> 
> [1]: http://www.haskell.org/platform/
> [2]: https://wiki.archlinux.org/index.php/ArchHaskell
> 
> On Mon, Oct 29, 2012 at 2:53 PM, Brandon Allbery  wrote:
>> On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning 
>> wrote:
>>> 
>>> Now I'm going to run the risk of upsetting you quite a bit by being
>>> completely blunt.
>> 
>> 
>> Indeed.
>> 
>>> 
>>> You come across in your mail like someone who has thought through your
>>> own situation, but fail to see the larger picture.  You do know *your*
>> 
>> 
>> May I ask you a question, then?
>> 
>> Does the Haskell Platform have any reason to exist?
>> 
>> Supposedly, the Haskell community backs the Haskell Platform as the way that
>> most users should be using the Platform.  Yet we have here a vendor platform
>> which does not support it, and newcomers who notice this and question it are
>> chastised for not thinking about the needs of other people.  This suggests
>> that the Haskell Platform is unimportant and perhaps disruptive to some
>> significant group of people... is this so?
>> 
>> And then, looking at your own message, I must ask:  have you considered that
>> the Platform is aimed at the great many people who do not have large amounts
>> of expertise maintaining their own personal Haskell ecosystem.  Or are your
>> needs so important that these people must in fact be told to deal?
>> 
>> Or, to phrase in your own words:
>> 
>>> You come across in your mail like someone who has thought through your
>>> own situation, but fail to see the larger picture.
>> 
>> 
>> --
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com  ballb...@sinenomine.net
>> unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
>> 
> 
> 
> 
> -- 
> Magnus Therning  OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe   http://therning.org/magnus
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: [Haskell-cafe] GHC maintenance on Arch

[Magnus Therning]

Please stay on topic, this is *not* a discussion about Haskell
Platform[1], it's a discussion on ArchHaskell[2].  Please read up on
the mailing list archives first, and then, if you still feel there's a
need to discuss HP in ArchHaskell (which isn't the same thing as Arch
itself) then please start a new thread.

/M

[1]: http://www.haskell.org/platform/
[2]: https://wiki.archlinux.org/index.php/ArchHaskell

On Mon, Oct 29, 2012 at 2:53 PM, Brandon Allbery  wrote:
> On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning 
> wrote:
>>
>> Now I'm going to run the risk of upsetting you quite a bit by being
>> completely blunt.
>
>
> Indeed.
>
>>
>> You come across in your mail like someone who has thought through your
>> own situation, but fail to see the larger picture.  You do know *your*
>
>
> May I ask you a question, then?
>
> Does the Haskell Platform have any reason to exist?
>
> Supposedly, the Haskell community backs the Haskell Platform as the way that
> most users should be using the Platform.  Yet we have here a vendor platform
> which does not support it, and newcomers who notice this and question it are
> chastised for not thinking about the needs of other people.  This suggests
> that the Haskell Platform is unimportant and perhaps disruptive to some
> significant group of people... is this so?
>
> And then, looking at your own message, I must ask:  have you considered that
> the Platform is aimed at the great many people who do not have large amounts
> of expertise maintaining their own personal Haskell ecosystem.  Or are your
> needs so important that these people must in fact be told to deal?
>
> Or, to phrase in your own words:
>
>> You come across in your mail like someone who has thought through your
>> own situation, but fail to see the larger picture.
>
>
> --
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
>



-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Ramana Kumar]

If all you want is the Haskell Platform, I believe the Arch policy is to
provide all those packages in the official [extra] repository.
(If those are broken because of the new ghc, just use IgnorePkg to avoid
the ghc update.)
The [haskell] and other ArchHaskell repos are for the rest of Hackage
that's not in the Platform.

On Mon, Oct 29, 2012 at 1:53 PM, Brandon Allbery wrote:

> On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning wrote:
>
>> Now I'm going to run the risk of upsetting you quite a bit by being
>> completely blunt.
>>
>
> Indeed.
>
>
>> You come across in your mail like someone who has thought through your
>> own situation, but fail to see the larger picture.  You do know *your*
>>
>
> May I ask you a question, then?
>
> Does the Haskell Platform have any reason to exist?
>
> Supposedly, the Haskell community backs the Haskell Platform as the way
> that most users should be using the Platform.  Yet we have here a vendor
> platform which does not support it, and newcomers who notice this and
> question it are chastised for not thinking about the needs of other people.
>  This suggests that the Haskell Platform is unimportant and perhaps
> disruptive to some significant group of people... is this so?
>
> And then, looking at your own message, I must ask:  have you considered
> that the Platform is aimed at the great many people who do not have large
> amounts of expertise maintaining their own personal Haskell ecosystem.  Or
> are your needs so important that these people must in fact be told to deal?
>
> Or, to phrase in your own words:
>
> You come across in your mail like someone who has thought through your
>> own situation, but fail to see the larger picture.
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix/linux, openafs, kerberos, infrastructure
> http://sinenomine.net
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimal line length for haskell

[Jake McArthur]

I stick to 80 columns fairly rigidly. This is not only so that it fits
into narrow windows, but also so that any two subexpressions in the
same expression tend to be close together on my screen, which makes it
easier for me to reason about it. If only it was easy for me to read
and write code on a Hilbert curve... :)

I don't think long lines indicate a design problem; it's solely a
formatting thing.

On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody  wrote:
> There was a recent discussion on the python list regarding maximum line
> length.
> It occured to me that beautiful haskell programs tend to be plump (ie have
> long lines) compared to other languages whose programs are 'skinnier'.
> My thoughts on this are at
> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
>
> Are there more striking examples than the lexer from the standard prelude?
> [Or any other thoughts/opinions :-) ]
>
> Thanks,
> Rusi
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

Re: [Haskell-cafe] Optimal line length for haskell

[Alexander Solla]

On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky wrote:

> On 10/29/2012 07:50 AM, Rustom Mody wrote:
> > There was a recent discussion on the python list regarding maximum line
> > length.
> > It occured to me that beautiful haskell programs tend to be plump (ie
> > have long lines) compared to other languages whose programs are
> 'skinnier'.
> > My thoughts on this are at
> > http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
> >
> > Are there more striking examples than the lexer from the standard
> prelude?
> > [Or any other thoughts/opinions :-) ]
>
> In any language, a line longer than 80 characters usually (but not
> always) suggests that you might want to stop and rethink your design. In
> many cases a refactoring or two will greatly simplify the code and
> reduce your line length as a result.


I disagree.  That might be true for imperative languages, where width is
indicative of deep nesting and its associated problems.  But it is not true
for a functional language, where it is merely indicative of a wide "normal
form".  Yes, the normal form can sometimes be refactored, but to what end?
 You might easily end up refactoring out of the level of abstraction you
actually want.  Or the wide form might have useful properties, like the
ability to sort the lines of source code alphanumerically (which would be
lost if you switched to a stanza-based format)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimal line length for haskell

[Lyndon Maydwell]

If I find my line is longer than 80 characters, I just shorten my
function and variable names!

It's perfectly idio(ma)tic!

On Mon, Oct 29, 2012 at 9:52 PM, Michael Orlitzky  wrote:
> On 10/29/2012 07:50 AM, Rustom Mody wrote:
>> There was a recent discussion on the python list regarding maximum line
>> length.
>> It occured to me that beautiful haskell programs tend to be plump (ie
>> have long lines) compared to other languages whose programs are 'skinnier'.
>> My thoughts on this are at
>> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
>>
>> Are there more striking examples than the lexer from the standard prelude?
>> [Or any other thoughts/opinions :-) ]
>
> In any language, a line longer than 80 characters usually (but not
> always) suggests that you might want to stop and rethink your design. In
> many cases a refactoring or two will greatly simplify the code and
> reduce your line length as a result.
>
> I think the lexer is an example of refactoring-needed rather than
> long-lines-needed.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Brandon Allbery]

On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning wrote:

> Now I'm going to run the risk of upsetting you quite a bit by being
> completely blunt.
>

Indeed.


> You come across in your mail like someone who has thought through your
> own situation, but fail to see the larger picture.  You do know *your*
>

May I ask you a question, then?

Does the Haskell Platform have any reason to exist?

Supposedly, the Haskell community backs the Haskell Platform as the way
that most users should be using the Platform.  Yet we have here a vendor
platform which does not support it, and newcomers who notice this and
question it are chastised for not thinking about the needs of other people.
 This suggests that the Haskell Platform is unimportant and perhaps
disruptive to some significant group of people... is this so?

And then, looking at your own message, I must ask:  have you considered
that the Platform is aimed at the great many people who do not have large
amounts of expertise maintaining their own personal Haskell ecosystem.  Or
are your needs so important that these people must in fact be told to deal?

Or, to phrase in your own words:

You come across in your mail like someone who has thought through your
> own situation, but fail to see the larger picture.


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimal line length for haskell

[Michael Orlitzky]

On 10/29/2012 07:50 AM, Rustom Mody wrote:
> There was a recent discussion on the python list regarding maximum line
> length.
> It occured to me that beautiful haskell programs tend to be plump (ie
> have long lines) compared to other languages whose programs are 'skinnier'.
> My thoughts on this are at
> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
> 
> Are there more striking examples than the lexer from the standard prelude?
> [Or any other thoughts/opinions :-) ]

In any language, a line longer than 80 characters usually (but not
always) suggests that you might want to stop and rethink your design. In
many cases a refactoring or two will greatly simplify the code and
reduce your line length as a result.

I think the lexer is an example of refactoring-needed rather than
long-lines-needed.

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

Re: [Haskell-cafe] Optimal line length for haskell

[Rustom Mody]

On Mon, Oct 29, 2012 at 5:55 PM, Colin Adams wrote:

> I'm not viewing on a narrow device, and I see the wrapped (and the whole
> post confined to the centre of the screen).
>
> I certainly don't use an 80-column limit any more. I use the rule:
>
> A function must be completely visible in my editor on my screen. (but this
> is only a good rule if most people who will be reading the code will also
> have a similar sized viewport. After all, code is far more often read than
> written.)
>
> And I balance line length with function length.
>

Very good point: getting the line to fit in one screen-line is of
comparable importance to getting a function into one screen.

And especially when one is teaching, (as Roman easily figured out!) having
to scroll up and down in the midst of explanations is a certain
show-spoiler.


On Mon, Oct 29, 2012 at 6:40 PM, Mike Meyer  wrote:

> On the other hand, readable cross-platform text formatting always seems to
> be a lost cause, as this mail and the referenced blog posting demonstrate.
> --
> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
>

As for the wraparound problems, hopefully they are now solved (for normal
computers!)
I'd appreciate hearing if they are not.
And Thanks Colin for the debugging support!

Clearly prettifying code and prettifying a blog are different issues and
putting them together makes a harder constraint-solving problem (especially
for a blogger noob!)

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

Re: [Haskell-cafe] Optimal line length for haskell

[Mike Meyer]

Colin Adams  wrote:

>I'm not viewing on a narrow device, and I see the wrapped (and the
>whole
>post confined to the centre of the screen).
>
>I certainly don't use an 80-column limit any more. I use the rule:
>
>A function must be completely visible in my editor on my screen. (but
>this
>is only a good rule if most people who will be reading the code will
>also
>have a similar sized viewport. After all, code is far more often read
>than
>written.)

I don't think "similar sized viewport" begins to cover it.  If the editor wraps 
long lines, then the lines will always be visible, no matter how long they are. 
Of course, lines wrapped around to the beginning of the next line in indented 
code are really, really ugly, so I'd prefer to avoid that. 

This is one of the cases where it's more important that there be a standard 
than what the actual value is. Personally, I like  roughly 80 columns, but I've 
been dong this long enough to have used the things that the 80-column console 
format was copied from. That screens are now bigger isn't really relevant. They 
are also windowed - no matter how hard Windows, Linux and Mac apps try and 
pretend they own the entire screen - and multitasking, so it's unreasonable to 
format code as if the editor were going to be the only visible window.

On the other hand, readable cross-platform text formatting always seems to be a 
lost cause, as this mail and the referenced blog posting demonstrate.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

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

Re: [Haskell-cafe] Optimal line length for haskell

[Colin Adams]

I'm not viewing on a narrow device, and I see the wrapped (and the whole
post confined to the centre of the screen).

I certainly don't use an 80-column limit any more. I use the rule:

A function must be completely visible in my editor on my screen. (but this
is only a good rule if most people who will be reading the code will also
have a similar sized viewport. After all, code is far more often read than
written.)

And I balance line length with function length.

On 29 October 2012 12:18, Rustom Mody  wrote:

> On Mon, Oct 29, 2012 at 5:40 PM, Malcolm Wallace 
> wrote:
>
>> It is kind of ironic that the wide code examples in the blog post are
>> wrapped at 65 chars by the blog formatting.
>>
>> Regards,
>> Malcolm
>
>
>
> Well that goes to underscore a couple of points:
> 1. The fixed 80 char width that was inviolable decades ago breaks today on
> both sides: it may be too low or too high!
> 2. I guess I dont know how to use blogger very well :-)
> 3. Are you viewing on a narrow device?
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimal line length for haskell

[Rustom Mody]

On Mon, Oct 29, 2012 at 5:40 PM, Malcolm Wallace wrote:

> It is kind of ironic that the wide code examples in the blog post are
> wrapped at 65 chars by the blog formatting.
>
> Regards,
> Malcolm



Well that goes to underscore a couple of points:
1. The fixed 80 char width that was inviolable decades ago breaks today on
both sides: it may be too low or too high!
2. I guess I dont know how to use blogger very well :-)
3. Are you viewing on a narrow device?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimal line length for haskell

[Roman Cheplyaka]

* Rustom Mody  [2012-10-29 17:20:20+0530]
> There was a recent discussion on the python list regarding maximum line
> length.
> It occured to me that beautiful haskell programs tend to be plump (ie have
> long lines) compared to other languages whose programs are 'skinnier'.
> My thoughts on this are at
> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
> 
> Are there more striking examples than the lexer from the standard prelude?
> [Or any other thoughts/opinions :-) ]

Indeed, I've seen quite a few Haskell projects with long lines.

Personally, I find it hard to read and very irritating. I always use
80-chars lines in my projects.

It seems that people who write long lines mostly come from academic
background, where there's less emphasis on maintainability (no offense;
also, I haven't conducted a proper statistical research — this is just an
impression).

Roman

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

Re: [Haskell-cafe] Optimal line length for haskell

[Malcolm Wallace]

It is kind of ironic that the wide code examples in the blog post are wrapped 
at 65 chars by the blog formatting.

Regards,
Malcolm

On 29 Oct 2012, at 11:50, Rustom Mody wrote:

> There was a recent discussion on the python list regarding maximum line 
> length.
> It occured to me that beautiful haskell programs tend to be plump (ie have 
> long lines) compared to other languages whose programs are 'skinnier'.
> My thoughts on this are at 
> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
> 
> Are there more striking examples than the lexer from the standard prelude?
> [Or any other thoughts/opinions :-) ]


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

Re: [Haskell-cafe] Optimal line length for haskell

[Rustom Mody]

On Mon, Oct 29, 2012 at 5:29 PM, Iustin Pop  wrote:

> On Mon, Oct 29, 2012 at 05:20:20PM +0530, Rustom Mody wrote:
> > There was a recent discussion on the python list regarding maximum line
> > length.
> > It occured to me that beautiful haskell programs tend to be plump (ie
> have
> > long lines) compared to other languages whose programs are 'skinnier'.
> > My thoughts on this are at
> > http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
> >
> > Are there more striking examples than the lexer from the standard
> prelude?
> > [Or any other thoughts/opinions :-) ]
>
> For what is worth, in our project (Ganeti) which has a mixed
> Python/Haskell codebase, we're using the same maximum length
> (80-but-really-79) in both languages, without any (real) issues.
>
> regards,
> iustin
>

Sure!

There can hardly be a case that 80 causes any issues.
Just that a bit more than 80 can sometimes lead to distinctly more elegant
programs.
Too much more than 80 can cause issues with readability and/or other tools.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimal line length for haskell

[Iustin Pop]

On Mon, Oct 29, 2012 at 05:20:20PM +0530, Rustom Mody wrote:
> There was a recent discussion on the python list regarding maximum line
> length.
> It occured to me that beautiful haskell programs tend to be plump (ie have
> long lines) compared to other languages whose programs are 'skinnier'.
> My thoughts on this are at
> http://blog.languager.org/2012/10/layout-imperative-in-functional.html.
> 
> Are there more striking examples than the lexer from the standard prelude?
> [Or any other thoughts/opinions :-) ]

For what is worth, in our project (Ganeti) which has a mixed
Python/Haskell codebase, we're using the same maximum length
(80-but-really-79) in both languages, without any (real) issues.

regards,
iustin

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

[Haskell-cafe] Optimal line length for haskell

[Rustom Mody]

There was a recent discussion on the python list regarding maximum line
length.
It occured to me that beautiful haskell programs tend to be plump (ie have
long lines) compared to other languages whose programs are 'skinnier'.
My thoughts on this are at
http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude?
[Or any other thoughts/opinions :-) ]

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Eric Velten de Melo]

In his defense, from the perspective of a more or less newbie in the
subject matter, I had quite a bit of trouble using Haskell under Arch.
Not that it is so much better in other systems, I wouldn't know.

I often was in the position to decide whether to use cabal-install,
arch-haskell repositories or official repositories and many times the
thing that worked for me was a mix of everything, which is quite
sub-optimal, although more or less working for me at the moment. I'm
not saying that this is because the way Arch works or the way Cabal is
designed is wrong. Maybe it is because I'm not figuring it out. Some
people say you should not use cabal-install as a package manager,
because it is not supposed to be one. Again, other people say
arch-haskell repositories are very buggy at the moment and one should
install only cabal-install and ghc from the official repositories and
only use cabal-install for the rest.

Just telling my experience so far: I often have had to struggle
between cabal dependency hell and non-working packages in the
repositories. Either something is very wrong with the way things are
right now or I'm doing everything wrong (which is more likely).

I am still not in the condition of proposing things myself, but I
don't think this is fair treatment so far to someone that is proposing
a compromise solution to a problem he found. Anyway, hopefully this
would be better clarified in the arch-haskell mailing list.

2012/10/29 Magnus Therning :
> Hello Timothy,
>
> Now I'm going to run the risk of upsetting you quite a bit by being
> completely blunt.
>
> You come across in your mail like someone who has thought through your
> own situation, but fail to see the larger picture.  You do know *your*
> Haskell needs, and you know what *you* would want from a project like
> ArchHaskell.  Then however you completely fail to realise that these
> are *your needs*, not anyone else's, but still you suggest that
> ArchHaskelll is broken because it doesn't provide a system that solves
> *your* problems.
>
> I suggest you take your insights of your situation and try to find a
> solution that works for you, and it sounds like you're on the way
> already with cabal-install.  If you have suggestions on how to improve
> ArchHaskell *within the goals of the project* (which includes the
> general goals of ArchLinux) that would make ArchHaskell more usable to
> you, then you are more than welcome.  However, if all you do is
> suggest that we completely change the goals of ArchHaskell because
> they don't align with your needs, then we thank you for your input,
> but ask you to not hold your breath for any changes.
>
> /M
>
> On Sun, Oct 28, 2012 at 9:49 PM,   wrote:
>> Hello,
>> Who is in charge of the ghc and haskell packages on Arch linux?  The current
>> system isn't working.
>>
>> Arch linux tends to update packages very quickly.
>>
>> For ghc, always having the latest ghc isn't a good thing.  At least if you
>> actually want to get some work done.  A majority of the time the latest GHC
>> is unusable. This is because the packages in hackage simply don't keep up.
>> With the current ghc version(7.6.1) even some basic packages in hackage are
>> not upgraded yet.
>>
>> Right now, a large number of other haskell related packages are in the arch
>> repos. Other than gtk2hs, I think these packages are pointless duplications.
>> In the other cases, it has been my experience that it is simpler to maintain
>> these packages through cabal rather than through pacman.  Support for these
>> packages in Arch should probably be dropped.
>>
>> If you want to get work done in Arch with haskell, you should only install
>> ghc and cabal-install(right now, you'll have to search the Internet for the
>> old binaries, because the arch repos usually don't keep the old versions
>> around).  Then you should add these packages to "IgnorePkg =" in pacman.conf
>> this way things won't break every couple of months.  You can then choose to
>> upgrade when you wish.
>>
>> I hope that someone who is involved with the haskell Arch stuff reads this.
>> The current model needs to be rethought.  Linux should be sane by default,
>> but I've lost many many hours learning that arch's relationship with haskell
>> is not so :(  Probably the best solution would be to make Arch automatically
>> keep two versions of ghc around at any given time.
>>
>> Thank you for your time,
>> Timothy Hobbs
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Magnus Therning  OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe   http://therning.org/magnus
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Hask

Re: [Haskell-cafe] Segment Tree based Set

[Chaddaï Fouché]

On Mon, Oct 29, 2012 at 9:43 AM, Tony Morris  wrote:
> It is not a Set, but a Map. Of course, I could use it to implement the
> function I need with something like: type SSet a = STree [()] a, but
> then I'd have to unnecessarily go beyond Haskell98.
>

Couldn't you just use :

> instance Measured (Interval a) Bool where
>   measure _ = True

Then the normal functions of SegmentTree would do what you wish for,
no ? You don't need much beyond Haskell 98 (MPTC is used everywhere
already).

-- 
Jedaï

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Magnus Therning]

Hello Timothy,

Now I'm going to run the risk of upsetting you quite a bit by being
completely blunt.

You come across in your mail like someone who has thought through your
own situation, but fail to see the larger picture.  You do know *your*
Haskell needs, and you know what *you* would want from a project like
ArchHaskell.  Then however you completely fail to realise that these
are *your needs*, not anyone else's, but still you suggest that
ArchHaskelll is broken because it doesn't provide a system that solves
*your* problems.

I suggest you take your insights of your situation and try to find a
solution that works for you, and it sounds like you're on the way
already with cabal-install.  If you have suggestions on how to improve
ArchHaskell *within the goals of the project* (which includes the
general goals of ArchLinux) that would make ArchHaskell more usable to
you, then you are more than welcome.  However, if all you do is
suggest that we completely change the goals of ArchHaskell because
they don't align with your needs, then we thank you for your input,
but ask you to not hold your breath for any changes.

/M

On Sun, Oct 28, 2012 at 9:49 PM,   wrote:
> Hello,
> Who is in charge of the ghc and haskell packages on Arch linux?  The current
> system isn't working.
>
> Arch linux tends to update packages very quickly.
>
> For ghc, always having the latest ghc isn't a good thing.  At least if you
> actually want to get some work done.  A majority of the time the latest GHC
> is unusable. This is because the packages in hackage simply don't keep up.
> With the current ghc version(7.6.1) even some basic packages in hackage are
> not upgraded yet.
>
> Right now, a large number of other haskell related packages are in the arch
> repos. Other than gtk2hs, I think these packages are pointless duplications.
> In the other cases, it has been my experience that it is simpler to maintain
> these packages through cabal rather than through pacman.  Support for these
> packages in Arch should probably be dropped.
>
> If you want to get work done in Arch with haskell, you should only install
> ghc and cabal-install(right now, you'll have to search the Internet for the
> old binaries, because the arch repos usually don't keep the old versions
> around).  Then you should add these packages to "IgnorePkg =" in pacman.conf
> this way things won't break every couple of months.  You can then choose to
> upgrade when you wish.
>
> I hope that someone who is involved with the haskell Arch stuff reads this.
> The current model needs to be rethought.  Linux should be sane by default,
> but I've lost many many hours learning that arch's relationship with haskell
> is not so :(  Probably the best solution would be to make Arch automatically
> keep two versions of ghc around at any given time.
>
> Thank you for your time,
> Timothy Hobbs
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

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

Re: [Haskell-cafe] Maximum bipartite matching: 24 lines

[Dmitry Olshansky]

I didn't analyze it but anytime I see "M.insertWith" I am just in doubt -
do you know about a strict version M.insertWith' ?

2012/10/24 Stefan Klinger 

> On 2012-Oct-22 14:23 (-0700), Eugene Kirpichov wrote with possible
> deletions:
> >
> > fwd = foldr (\(x,y) -> M.insertWith (++) x [y]) M.empty $ S.toList g
> >
> > Use foldl' here, foldr is absolutely useless here and it only consumes
> > the stack space as your operation is strict.
>
> Thank you very much for that.  I'll review the code under strictness
> aspects.
>
> > As for the actual code: I'd prefer the code itself to be more
> > readable, rather than have a lot of literate comments around it;
>
> I like comments documenting why something's done, complementing the code
> which tells what's done.
>
> > currently, IMO all the uncurry's, flips, eithers, maybes and
> > point-free style hurt readability heavily.
>
> I agree.  Between babbling bloated and incomprehensible terse, my code
> is certainly towards the terse extreme.  For me, that's a balancing act
> that I find hard to do right.
>
> > I'll probably try to write my own version as an exercise :)
>
> Cool!  I'd like to see that...
>
> Cheers!
> Stefan
>
>
> --
> Stefan Klinger  o/klettern
> /\/  bis zum
> send plaintext only - max size 32kB - no spam \   Abfallen
> http://stefan-klinger.de
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] non-uniform recursive Trie

[山本和彦]

Andres,

> The code you've listed shows how to go from an already existing
> instance of class FiniteMap to an instance for the same class that
> adds a trie structure on top of the underlying finite map
> implementation. You have to add a "base instance" to the code so that
> it can work. For example, by importing Data.Map and adding an
> "instance FiniteMap Data.Map.Map Char" with the appropriate
> definitions.

Thank you.

I added the following:

instance FiniteMap Map Char where
empty = M.empty
look = M.lookup
bind = M.insert

> You'll also need to add extra type information to "empty" in your
> example expression so that GHC can know which instance you actually
> want.

Is the follwing what you mean?

> look "bar" $ bind "bar" 1 $ (empty :: Trie (Map Char) String Int)
Just 1

P.S.

FiniteMap uses another finite map, Data.Map in this case. I wonder why
we can call it bootstrapping...

--Kazu

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

Re: [Haskell-cafe] Segment Tree based Set

[Tony Morris]

It is not a Set, but a Map. Of course, I could use it to implement the
function I need with something like: type SSet a = STree [()] a, but
then I'd have to unnecessarily go beyond Haskell98.

Hoping there might be an interval tree or segment tree specifically for
this task.

On 29/10/12 18:36, Roman Cheplyaka wrote:
> If you searched hackage, you'd find
> http://hackage.haskell.org/package/SegmentTree
>
> Roman
>
> * Tony Morris  [2012-10-29 15:38:07+1000]
>> Er, oops.
>>
>> ...can be implemented as:
>> \a rs -> let s = Set.fromList (rs >>= \(a, b) -> [a..b]) in a `member` s
>>
>> Something like that!
>>
>> On Mon, Oct 29, 2012 at 2:48 PM, Tony Morris  wrote:
>>
>>> Hi,
>>> I was wondering if anyone knows of a package implementing a fast lookup
>>> for an element in ranges.
>>>
>>> For example, this operation:
>>> Ord a => a -> [(a, a)] -> Bool
>>>
>>> ...can be implemented:
>>> \a rs -> let s = Set.fromList rs in a `member` s
>>>
>>> This is not particularly efficient. A segment tree seems like a more
>>> appropriate data structure to store the ranges. Does such a library exist?


-- 
Tony Morris
http://tmorris.net/



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

Re: [Haskell-cafe] Segment Tree based Set

[Roman Cheplyaka]

If you searched hackage, you'd find
http://hackage.haskell.org/package/SegmentTree

Roman

* Tony Morris  [2012-10-29 15:38:07+1000]
> Er, oops.
> 
> ...can be implemented as:
> \a rs -> let s = Set.fromList (rs >>= \(a, b) -> [a..b]) in a `member` s
> 
> Something like that!
> 
> On Mon, Oct 29, 2012 at 2:48 PM, Tony Morris  wrote:
> 
> > Hi,
> > I was wondering if anyone knows of a package implementing a fast lookup
> > for an element in ranges.
> >
> > For example, this operation:
> > Ord a => a -> [(a, a)] -> Bool
> >
> > ...can be implemented:
> > \a rs -> let s = Set.fromList rs in a `member` s
> >
> > This is not particularly efficient. A segment tree seems like a more
> > appropriate data structure to store the ranges. Does such a library exist?

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

Re: [Haskell-cafe] non-uniform recursive Trie

[Andres Löh]

Hi Kazu.

> I'm now studying Trie in Okasaki's "Purely Functional Data Structure".
> Attached is the program in its appendix. I cannot understand how to
> use "empty", "look" and "bind". For instance, if I type 'look "" empty',
> I got an error:
>
>> look "" empty
> :2:1:
> No instance for (FiniteMap m0 [Char])
>   arising from a use of `look'
> Possible fix: add an instance declaration for (FiniteMap m0 [Char])
> In the expression: look "" empty
> In an equation for `it': it = look "" empty
>
> I have no idea how to determine the parameter 'm'. Suggestions would
> be appreciated.

The code you've listed shows how to go from an already existing
instance of class FiniteMap to an instance for the same class that
adds a trie structure on top of the underlying finite map
implementation. You have to add a "base instance" to the code so that
it can work. For example, by importing Data.Map and adding an
"instance FiniteMap Data.Map.Map Char" with the appropriate
definitions.

You'll also need to add extra type information to "empty" in your
example expression so that GHC can know which instance you actually
want.

Cheers,
  Andres

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

Re: [Haskell-cafe] GHC maintenance on Arch

[Ramana Kumar]

I believe your main question (how do I do my work without wasting time) has
already been answered: use IgnorePkg.

I would like to add, in case you missed it, that there is a mailing list
and community specifically for Haskell on Arch.
Here is the webpage: https://wiki.archlinux.org/index.php/ArchHaskell
The [haskell] repository is currently in sync with Hackage and builds with
the latest ghc. (It does not yet include all of Hackage; your help would be
welcome.)
(The [haskell-web] and [haskell-extra] repos include more packages, with
more or less in-sync-ness and omissions due to ghc 7.6 failures.)
Ultimately we do want Arch packages for Haskell packages, because cabal is
not a package manager (see
https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/
).

On Sun, Oct 28, 2012 at 8:49 PM,  wrote:

> Hello,
> Who is in charge of the ghc and haskell packages on Arch linux?  The
> current system isn't working.
>
> Arch linux tends to update packages very quickly.
>
> For ghc, always having the latest ghc isn't a good thing.  At least if you
> actually want to get some work done.  A majority of the time the latest GHC
> is unusable. This is because the packages in hackage simply don't keep up.
> With the current ghc version(7.6.1) even some basic packages in hackage are
> not upgraded yet.
>
> Right now, a large number of other haskell related packages are in the
> arch repos. Other than gtk2hs, I think these packages are pointless
> duplications.  In the other cases, it has been my experience that it is
> simpler to maintain these packages through cabal rather than through
> pacman.  Support for these packages in Arch should probably be dropped.
>
> If you want to get work done in Arch with haskell, you should only install
> ghc and cabal-install(right now, you'll have to search the Internet for the
> old binaries, because the arch repos usually don't keep the old versions
> around).  Then you should add these packages to "IgnorePkg =" in
> pacman.conf  this way things won't break every couple of months.  You can
> then choose to upgrade when you wish.
>
> I hope that someone who is involved with the haskell Arch stuff reads
> this.  The current model needs to be rethought.  Linux should be sane by
> default, but I've lost many many hours learning that arch's relationship
> with haskell is not so :(  Probably the best solution would be to make Arch
> automatically keep two versions of ghc around at any given time.
>
> Thank you for your time,
> Timothy Hobbs
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] non-uniform recursive Trie

[山本和彦]

Hello cafe,

I'm now studying Trie in Okasaki's "Purely Functional Data Structure".
Attached is the program in its appendix. I cannot understand how to
use "empty", "look" and "bind". For instance, if I type 'look "" empty',
I got an error:

> look "" empty
:2:1:
No instance for (FiniteMap m0 [Char])
  arising from a use of `look'
Possible fix: add an instance declaration for (FiniteMap m0 [Char])
In the expression: look "" empty
In an equation for `it': it = look "" empty

I have no idea how to determine the parameter 'm'. Suggestions would
be appreciated.

--Kazu

{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}

class FiniteMap m k where
empty :: m k v
look :: k -> m k v -> Maybe v
bind :: k -> v -> m k v -> m k v

data Trie m ks v = Trie (Maybe v) (m (Trie m ks v))

instance FiniteMap m k => FiniteMap (Trie (m k)) [k] where
empty = Trie Nothing empty

look [] (Trie b _) = b
look (k:ks) (Trie _ m) = look k m >>= look ks

bind [] x (Trie _ m) = Trie (Just x) m
bind (k:ks) x (Trie b m) = Trie b (bind k t' m)
  where
t = case look k m of
Just a  -> a
Nothing -> empty
t' = bind ks x t

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