On Thu, Mar 17, 2011 at 11:14 PM, Andrew Coppin
wrote:
>>> Right. So somebody else came up with an idea similar to mine, but since
>>> nobody could agree on anything more than a rough idea, nothing actually
>>> got
>>> done...(?)
>>
>> Well, I also got the sense that it would be more than a little
Right. So somebody else came up with an idea similar to mine, but since
nobody could agree on anything more than a rough idea, nothing actually got
done...(?)
Well, I also got the sense that it would be more than a little
nontrivial to implement. Or at least, someone was talking about how it
wou
On Thu, Mar 17, 2011 at 10:37 PM, Andrew Coppin
wrote:
> On 17/03/2011 12:11 PM, Gábor Lehel wrote:
>>
>> Necroing this thread because I just noticed there's a (rather old!)
>> bug report which covers much of the same ground and doesn't seem to
>> have been mentioned by anyone:
>>
>> http://hackag
On 17/03/2011 12:11 PM, Gábor Lehel wrote:
Necroing this thread because I just noticed there's a (rather old!)
bug report which covers much of the same ground and doesn't seem to
have been mentioned by anyone:
http://hackage.haskell.org/trac/ghc/ticket/1349
Right. So somebody else came up with
Necroing this thread because I just noticed there's a (rather old!)
bug report which covers much of the same ground and doesn't seem to
have been mentioned by anyone:
http://hackage.haskell.org/trac/ghc/ticket/1349
2011/2/8 Gábor Lehel :
> 2011/2/8 Ketil Malde :
>> Gábor Lehel writes:
>>
>>> Is
On 2011-02-11 02:06, wren ng thornton wrote:
> And it is clear
> that pointed and unpointed versions are different types[1].
...
> [1] Though conversion between them is easy. From unpointed to pointed is
> just a forgetful functor; from pointed to unpointed is the monad of
> evaluation.
I'm unski
On 2/8/11 6:00 AM, Ketil Malde wrote:
This does seem a bit excessive. As a start, I don't remember anyone
asking for control over (un)boxedness, so hopefully we could jettison
that part of it?
Uh, you mean like in IOUArrays, the UNPACK pragma, or
-funbox-strict-fields? Unboxing is an important
On Tue, Feb 8, 2011 at 12:33 PM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:
> On 8 February 2011 23:25, John Lato wrote:
> >> class Container c where
> >> type Elem c :: *
> >>
> >> class (Container cIn, Container cOut) => CMap cIn cOut where
> >> cmap :: (Elem cIn -> Elem
On 8 February 2011 23:25, John Lato wrote:
>> class Container c where
>> type Elem c :: *
>>
>> class (Container cIn, Container cOut) => CMap cIn cOut where
>> cmap :: (Elem cIn -> Elem cOut) -> cIn -> cOut
>>
>> instance (a ~ Elem (c a), b ~ Elem (c b), Functor c, Container (c a),
>> Cont
On Mon, Feb 7, 2011 at 11:30 PM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:
> On 8 February 2011 09:57, John Lato wrote:
> > I think the real problem we have with container classes has a lot more to
> do
> > with what we would use them for. That is, Haskell already has Monoid,
> >
2011/2/8 Ketil Malde :
> Gábor Lehel writes:
>
>> Is there any sensible meaning for bangs on return types? I've been
>> trying to think this through but not necessarily succeeding.
>
> Not knowing Clean in any detail, I've always just thought that a type
> signature of, say:
>
> something
Gábor Lehel writes:
> Is there any sensible meaning for bangs on return types? I've been
> trying to think this through but not necessarily succeeding.
Not knowing Clean in any detail, I've always just thought that a type
signature of, say:
something :: !Foo -> Bar
would mean the sam
2011/2/7 Richard O'Keefe :
>
> On 8/02/2011, at 3:47 AM, Gábor Lehel wrote:
>>
>> I dunno. As a language extension, would - let's call it BangTypes - be
>> backwards-incompatible in any way?
>
> Let's look at an intermediate step first, BangFunctions.
>
> What this does is to say that there are two
On Mon, Feb 7, 2011 at 11:57 PM, John Lato wrote:
> I think the real problem we have with container classes has a lot more to do
> with what we would use them for. That is, Haskell already has Monoid,
> Foldable and Traversable. These three (especially Foldable) cover nearly
> everything OOP pro
On 8 February 2011 09:57, John Lato wrote:
> I think the real problem we have with container classes has a lot more to do
> with what we would use them for. That is, Haskell already has Monoid,
> Foldable and Traversable. These three (especially Foldable) cover nearly
> everything OOP programmer
From: Johan Tibell
>
> >
> > (The OOP people, of course, just don't bother trying. They use typecasts
> > everywhere...)
> >
> > Do associated types solve this? Or are there still problems?
>
> Duncan showed me a definition using associated types, which I have
> unfortunately forgotten.
>
Yes, a
On 8/02/2011, at 10:43 AM, Roel van Dijk wrote:
> On 7 February 2011 22:00, Andrew Coppin wrote:
>> I clearly have my languages mixed up.
>>
>> The language I'm thinking of required all variables (even top-level ones) to
>> be declared with "let" - unless the definition is recursive, in which c
> The distinction between let and letrec predates OCAML. Scheme does it too.
Haskell's choice of recursive everywhere is nice for the syntax, but
occasionally error prone. I don't actually use explicit recursion too
often because there are functions for that, but I still occasionally
typo a vari
On 8/02/2011, at 10:00 AM, Andrew Coppin wrote:
> I clearly have my languages mixed up.
>
> The language I'm thinking of required all variables (even top-level ones) to
> be declared with "let" - unless the definition is recursive, in which case
> you have to say "letrec" (i.e., the compiler it
On 7 February 2011 22:00, Andrew Coppin wrote:
> I clearly have my languages mixed up.
>
> The language I'm thinking of required all variables (even top-level ones) to
> be declared with "let" - unless the definition is recursive, in which case
> you have to say "letrec" (i.e., the compiler it too
On Mon, Feb 7, 2011 at 10:01 PM, Andrew Coppin
wrote:
>> I think haskell2010's type system is just not expressive enough to
>> create interface generic enough. It's not possible to create type class
>> which will work for both ByteStrings (or IntSet) and lists.
>
> It seems that most people agree:
On 8/02/2011, at 3:47 AM, Gábor Lehel wrote:
>
> I dunno. As a language extension, would - let's call it BangTypes - be
> backwards-incompatible in any way?
Let's look at an intermediate step first, BangFunctions.
What this does is to say that there are two versions of "->":
t1 -> t2
I think haskell2010's type system is just not expressive enough to
create interface generic enough. It's not possible to create type class
which will work for both ByteStrings (or IntSet) and lists.
It seems that most people agree: The reason why we don't have container
classes is that it's dif
Haskell en Clean are very much alike.
From what I could determine from a basic Clean introduction, Clean is very
*unlike* Haskell, having a far more verbose and low-level syntax. (E.g., the
compiler can't even determine whether a binding is recursive or not for itself.
You have to say that m
On Mon, Feb 7, 2011 at 1:36 PM, Jimbo Massive
wrote:
> On 07/02/2011 11:40, Stephen Tetley wrote:
>
>> Interesting point, but excepting that its adding more complexity
>> Haskell type system, the Clean way of putting strictness information
>> into the type system seems preferable don't you think?
On 07/02/2011 11:40, Stephen Tetley wrote:
> Interesting point, but excepting that its adding more complexity
> Haskell type system, the Clean way of putting strictness information
> into the type system seems preferable don't you think?
If we were starting from a clean sheet (no pun intended) th
On Mon, Feb 07, 2011 at 11:05:53AM +, John Lato wrote:
> From: Ivan Lazar Miljenovic
>
> On 7 February 2011 12:30, wren ng thornton wrote:
> > On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote:
> >>
> >> On 7 February 2011 08:12, Alexey Khudyakov
> >> ?wrote:
> >>>
>
On 7 February 2011 10:16, Jimbo Massive wrote:
> It's often struck me that, this information is clearly part of the
> interface to a function, given that correct operation of calls to that
> function may depend on it, yet we (implicitly) pretend that it's not (by
> rarely documenting it).
>
> Wou
>
> From: Ivan Lazar Miljenovic
>
> On 7 February 2011 12:30, wren ng thornton wrote:
> > On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote:
> >>
> >> On 7 February 2011 08:12, Alexey Khudyakov
> >> ?wrote:
> >>>
> >>> Also there is a container-classes package which provide set of type
> class
> >>>
On 05/02/2011 15:35, Andrew Coppin wrote:
>> At the very
>> least we need to teach people how to tell which arguments a pure
>> function is strict in by looking at its definition.
>
> That's not necessarily tractible. It depends on what other functions you
> call. Many functions have obvious stri
Johan Tibell writes:
>> The GHC documentation says the information is in the interface files,
>> but they are binary now, and I can't find it there.
> ghc --show-iface HI_FILE
> The strictness signatures are a bit hard to parse though. Having a
> cheat sheet would be nice.
Am I the only one wh
On 7/02/2011, at 8:41 AM, Andrew Coppin wrote:
> On 06/02/2011 09:13 AM, Roel van Dijk wrote:
>
>> Haskell en Clean are very much alike.
>
> From what I could determine from a basic Clean introduction, Clean is very
> *unlike* Haskell, having a far more verbose and low-level syntax. (E.g., the
On 7 February 2011 12:30, wren ng thornton wrote:
> On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote:
>>
>> On 7 February 2011 08:12, Alexey Khudyakov
>> wrote:
>>>
>>> Also there is a container-classes package which provide set of type class
>>> for containers.
>>>
>>> [1] http://hackage.haskell.o
On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote:
On 7 February 2011 08:12, Alexey Khudyakov wrote:
Also there is a container-classes package which provide set of type class
for containers.
[1] http://hackage.haskell.org/package/container-classes
Don't use that package: it's broken. I did sta
On 6/02/2011, at 4:21 AM, Andrew Coppin wrote:
> I didn't think Clean supported laziness at all? I thought it was a strict
> language.
Absolutely not. Back in the Good Old Days the one thing that
used to keep on tripping me up is that
Haskellif e0 then e1 else e2
<=>Clean
On 7 February 2011 08:12, Alexey Khudyakov wrote:
> Also there is a container-classes package which provide set of type class
> for containers.
>
> [1] http://hackage.haskell.org/package/container-classes
Don't use that package: it's broken. I did start on a re-write that
works (and there are si
On 07.02.2011 00:37, Johan Tibell wrote:
Also there is a container-classes package which provide set of type class
for containers.
I'd like to avoid MPTC and fundeps if possible.
I think haskell2010's type system is just not expressive enough to
create interface generic enough. It's not possi
On Sun, Feb 6, 2011 at 10:12 PM, Alexey Khudyakov
wrote:
> Well Foldable and Traversable provide set of generic operations for
> containers. Although they are quite limited, containter must be polymorphic
> (e.g. no IntMap) and parameter must be of any type (e.g. no unboxed vectors)
> both are sti
On 06.02.2011 23:29, Johan Tibell wrote:
On Sun, Feb 6, 2011 at 8:48 PM, Andrew Coppin
wrote:
In particular, I get strange looks from people in the OOP community when I
say I'm using a language that doesn't have any abstractions at all for
dealing polymorphically with containers. In general, i
On Sun, Feb 6, 2011 at 8:48 PM, Andrew Coppin
wrote:
> In particular, I get strange looks from people in the OOP community when I
> say I'm using a language that doesn't have any abstractions at all for
> dealing polymorphically with containers. In general, it's almost impossible
> to write a Hask
On 6 February 2011 19:41, Andrew Coppin wrote:
. (E.g., the
> compiler can't even determine whether a binding is recursive or not for
> itself. You have to say that manually.) It seems a very unecessarily
> complicated and messy language - which makes the name rather ironic.
Erm - nope. Sure you
Random fact: Data.Map.insertWith' exists. Data.IntMap.insertWith' does *not*
exist.
The containers library is a mess.
I'm inclined to agree.
In particular, I get strange looks from people in the OOP community when
I say I'm using a language that doesn't have any abstractions at all for
deal
On 06/02/2011 09:13 AM, Roel van Dijk wrote:
Haskell en Clean are very much alike.
From what I could determine from a basic Clean introduction, Clean is
very *unlike* Haskell, having a far more verbose and low-level syntax.
(E.g., the compiler can't even determine whether a binding is recurs
On Thu, Feb 3, 2011 at 11:40 PM, Richard O'Keefe wrote:
>
> On 4/02/2011, at 10:10 AM, Andrew Coppin wrote:
>>
>> The important obsevation is this: One tiny, almost insignificant change can
>> transform a program from taking 50 seconds and 400 MB of RAM into one that
>> takes 0.02 seconds and 0.
On Sat, Feb 5, 2011 at 4:16 PM, Andrew Coppin
wrote:
> Random fact: Data.Map.insertWith' exists. Data.IntMap.insertWith' does *not*
> exist.
The containers library is a mess. For example, Data.Map has 10+
functions (e.g. adjust) that don't have strict counterparts even
though the strict version i
On 5 February 2011 16:21, Andrew Coppin wrote:
> I didn't think Clean supported laziness at all? I thought it was a strict
> language.
"CLEAN is a practical applicable general-purpose lazy pure functional
programming language suited for the development
of real world applications." [1]
Haskell en
On 6 February 2011 02:40, Andrew Coppin wrote:
> Then again, if you could actually single-step through a Haskell program's
> execution, most strictness issues would become quite shallow.
You can single-step through a Haskell program's execution with the
GHCi debugger. It can provide considerable
On 04/02/2011 07:30 AM, Johan Tibell wrote:
Right. It can still be tricky. I think we can get rid of a large
number of strictness issues by using strict data structures more
often, this should help beginners in particular. For the rest better
tooling would help. For example, a lint tool that mar
For what it's worth I saw the problems in your counting examples right
away, without reading the explanatory text below.
Yes, they were pretty obvious with enough experience. For beginners I
expect it to be a rather insidious trap.
Beginners or anybody coding Haskell while not completely awake
On 03/02/2011 10:15 PM, Johan Tibell wrote:
First, we need to stop pretending that you can use Haskell effectively
without first learning to reason about program evaluation order.
Writing a program in *any* language without understanding the
performance implications of different language cons
That got me thinking... What would happen if, instead of "Integer", we had two types,
"evaluated Integer" and "possibly unevaluated Integer"? What if the strictness or
otherwise of a data structure were exposed at the type level?
Oh, you mean like "!Int" and "Int" in Clean? I used to find ban
On 03/02/2011 09:37 PM, Daniel Fischer wrote:
To illustrate your prediction about the side-issues:
On Thursday 03 February 2011 22:10:51, Andrew Coppin wrote:
Consider for a moment the original implementation with Data.Map. Adding
a seq or two here will do no good at all; seq reduces to WHNF. W
On 2/5/11 4:26 AM, Claus Reinke wrote:
Lately I've been trying to go the other direction: make a large
section of formerly strict code lazy.
There used to be a couple of tools trying to make suggestions when a
function could be made less strict (Olaf Chitil's StrictCheck and
another that escape
On 2/5/11 4:26 AM, Claus Reinke wrote:
Lately I've been trying to go the other direction: make a large
section of formerly strict code lazy.
There used to be a couple of tools trying to make suggestions
when a function could be made less strict (Olaf Chitil's StrictCheck and
another that escape
Lately I've been trying to go the other direction: make a large
section of formerly strict code lazy.
There used to be a couple of tools trying to make suggestions
when a function could be made less strict (Olaf Chitil's StrictCheck
and another that escapes memory at the moment). Often, it
c
On Thu, Feb 3, 2011 at 3:38 PM, Erik de Castro Lopo
wrote:
> I am a relative newcomer to Haskell, but I think I have a reasonable
> understanding of the executaion model. Enough to fix performance
> issues in simple code like the example given.
>
> However, one of the Haskell projects I work on is
On 4/02/2011, at 8:26 PM, Johan Tibell wrote:
> --show-iface HI_FILE
sort.hs has 50 top level functions.
One of them is main, and the others are all reachable from it.
ghc -O sort.hs
ghc --show-iface sort.hi
The only functions listed are variants of main.
Dropping -O leaves one variant of main
On 02/03/2011 03:10 PM, Andrew Coppin wrote:
(Unless you're seriously going to suggest that GHC's native code
generator is any match for the might of a half-decent C compiler...)
I don't know enough about the native code generator to make a claim like
that, but we're not comparing the native c
On Fri, Feb 4, 2011 at 12:38 AM, Erik de Castro Lopo
wrote:
> However, one of the Haskell projects I work on is Ben Lippmeier's
> DDC compiler. Thats about 5 lines of Haskell code and finding
> performance issues there is really difficult.
Right. It can still be tricky. I think we can get rid
On Thu, Feb 3, 2011 at 11:40 PM, Richard O'Keefe wrote:
> Back in the days when systems other than Wintel and maybe sort of intel Linux
> were
> supported by Clean, I used to really love one of the features of the Clean
> compiler.
> One simple command line switch and the compiler would list the
Daniel Fischer wrote:
> On Thursday 03 February 2011 23:19:31, Johan Tibell wrote:
> > Hi,
> >
> > For what it's worth I saw the problems in your counting examples right
> > away, without reading the explanatory text below.
>
> Yes, they were pretty obvious with enough experience. For beginners I
On 4/02/2011, at 10:10 AM, Andrew Coppin wrote:
>
> The important obsevation is this: One tiny, almost insignificant change can
> transform a program from taking 50 seconds and 400 MB of RAM into one that
> takes 0.02 seconds and 0.1 MB of RAM. And, at least in this case, the simpler
> version
On Thursday 03 February 2011 23:19:31, Johan Tibell wrote:
> Hi,
>
> For what it's worth I saw the problems in your counting examples right
> away, without reading the explanatory text below.
Yes, they were pretty obvious with enough experience. For beginners I
expect it to be a rather insidious
Hi,
For what it's worth I saw the problems in your counting examples right
away, without reading the explanatory text below. Hopefully that means
that it's possibly to learn how to spot such things without resorting
to e.g. running the program or reading Core *gasp*.
Johan
__
On Thu, Feb 3, 2011 at 11:10 PM, Andrew Coppin
wrote:
> Wouldn't that still mean that the spine of the map is still lazy though?
No, Data.Map and Data.Set are both spine strict (which should be
documented!). Data.Map is key strict in addition. Both are value lazy.
Johan
Hi,
Thanks for bringing up these issues. It's something we could be better
at addressing as a community.
First, we need to stop pretending that you can use Haskell effectively
without first learning to reason about program evaluation order.
Learning how is not terrible difficult, but there's very
On 03/02/2011 09:37 PM, Daniel Fischer wrote:
To illustrate your prediction about the side-issues:
On Thursday 03 February 2011 22:10:51, Andrew Coppin wrote:
Consider for a moment the original implementation with Data.Map. Adding
a seq or two here will do no good at all; seq reduces to WHNF. W
To illustrate your prediction about the side-issues:
On Thursday 03 February 2011 22:10:51, Andrew Coppin wrote:
> Consider for a moment the original implementation with Data.Map. Adding
> a seq or two here will do no good at all; seq reduces to WHNF. What we
> are wanting is NF, and I can see no
There now follows a small grab-bag of miscelaneous but related thoughts.
(Which probably means that this post will spawn a 2000 message thread
discussing one tiny side-issue, rather than the main thrust of the
message...)
First of all, benchmarking. We have The Great Language Shootout, which
69 matches
Mail list logo
