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 sho
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
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 f
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 an
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 won
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
Haskel
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 gr
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 be
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/ic
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
>
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 need
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 somewher
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,
Con
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 treate
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 c
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 signa
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 leng
"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
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
> "(.)/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.
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
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
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 chec
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'
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
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 hask
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 g
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 differ
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 hav
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 traditiona
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 co
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 l
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 Oc
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
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
tha
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
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 o
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 l
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
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
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
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 onl
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
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 inviolabl
* 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 a
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 beauti
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
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
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-imper
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
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
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
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.e
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 exam
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, Rom
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, 2
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 (Fin
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/ArchH
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 [
59 matches
Mail list logo
