On Feb 4, 2006, at 7:56 PM, Pablo Barenbaum wrote:
An awkwardness in Haskell I would like to see solved in
Haskell', is the fact that the behavior of tuple-like
constructors must be either built-in or "limited".
One thing I recall seeing on haskell-cafe some time back was the
notion that an
On Thu, Feb 02, 2006 at 03:53:11PM +, Henrik Nilsson wrote:
> What about the "FD Conditions" as defined in the paper by Sulzman, Duck,
> Peyton-Jones and Stuckey you referred to? (Mark Jones original
> conditions + a so called "bound variable condition").
> If those conditions are imposed, one
An awkwardness in Haskell I would like to see solved in
Haskell', is the fact that the behavior of tuple-like
constructors must be either built-in or "limited".
As far as I can see, these are two issues:
1. There is not a way, for the programmer, to define
infinite constructors for infinite assoc
Having thought about this for a while I'm coming down on the side of keeping
some sort of monomorphism restriction, for the following reason.
It's hard to bound the space consumption of a Haskell program, but easy to
bound its time consumption: its asymptotic runtime will be the same as or
bet
On Friday 03 February 2006 08:52, Tomasz Zielonka wrote:
> On Thu, Feb 02, 2006 at 01:05:57PM +, Ross Paterson wrote:
> > Personally, I'm not sure about caseless underscore, concurrency,
> > natural numbers and parallel list comprehensions.
>
> There is one more reason to leave concurrency out
On Sat, Feb 04, 2006 at 06:31:56PM +, Jon Fairbairn wrote:
> There ought to be a list_product somewhere (I mean [1..]
> `list_product` [4..] ==
> [(1,4),(2,4),(1,5),(3,4),(2,5),(1,6),...]). Is there?
This is called "fair conjunction" in "Backtracking, Interleaving, and
Terminating Monad Transf
Ian Lynagh <[EMAIL PROTECTED]> writes:
> On Fri, Feb 03, 2006 at 11:38:09AM -0800, Isaac Jones wrote:
>> I would like to strive to find objective data on the use of
>> extensions. I started a table here which summarizes how popular
>> extensions are in real-life code. We need more data points, t
cartesian xs ys = map (\[x,y] -> (x,y)) $ sequence [xs,ys]
On 04/02/06, Jan-Willem Maessen <[EMAIL PROTECTED]> wrote:
>
> On Feb 4, 2006, at 1:31 PM, Jon Fairbairn wrote:
> > ...
> > There ought to be a list_product somewhere (I mean [1..]
> > `list_product` [4..] ==
> > [(1,4),(2,4),(1,5),(3,4),(
On Feb 4, 2006, at 1:31 PM, Jon Fairbairn wrote:
...
There ought to be a list_product somewhere (I mean [1..]
`list_product` [4..] ==
[(1,4),(2,4),(1,5),(3,4),(2,5),(1,6),...]). Is there?
Not that I know of, but here's one which handles finite lists
correctly; it'd be a nice addition to Data
On Sat, Feb 04, 2006 at 11:58:15AM -0800, John Meacham wrote:
> On Sat, Feb 04, 2006 at 03:11:10PM +0100, John Hughes wrote:
> > I noticed ticket #55--add parallel list comprehensions--which according to
> > the ticket, will probably be adopted. I would argue against.
>
> I disagree. :) I use them
On Sat, Feb 04, 2006 at 03:11:10PM +0100, John Hughes wrote:
> I noticed ticket #55--add parallel list comprehensions--which according to
> the ticket, will probably be adopted. I would argue against.
I disagree. :) I use them all the time and find them very useful.
however, I do agree with some
On Sat, Feb 04, 2006 at 01:40:26PM +0300, Bulat Ziganshin wrote:
> GHC's libs (including handling of Handles) check "threaded" at
> run-time just to have one common compiled library instead of two ones
Yeah, but I don't expect a common compiled library between
different implementations.
Jo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I noticed ticket #55--add parallel list comprehensions--which
according to
the ticket, will probably be adopted. I would argue against.
[...]
For what's it worth: I totally agree with John. Not only does this
seems to me like a feature that'll
On Feb 4, 2006, at 9:11 AM, John Hughes wrote:
I noticed ticket #55--add parallel list comprehensions--which
according to
the ticket, will probably be adopted. I would argue against.
...
I tend to agree. But to back myself up, I thought I'd do an informal
survey of uses of "zip" or "zipW
On 2006-02-04 at 15:11+0100 John Hughes wrote:
> I noticed ticket #55--add parallel list comprehensions--which according to
> the ticket, will probably be adopted. I would argue against.
I also agree.
> Firstly: because in its more general forms the notation is confusing. Try
> this example:
>
> I noticed ticket #55--add parallel list comprehensions--which according to
> the ticket, will probably be adopted. I would argue against.
[Several good points removed.]
I agree.
Cheers,
Andres
___
Haskell-prime mailing list
Haskell-prime@haskell.or
On Feb 3, 2006, at 8:16 PM, Brian Hulley wrote:
Jan-Willem Maessen wrote:
I pointed out some problems with strict Haskell in a recent talk, but
I think it'd be worth underscoring them here in this forum.
Is the text of this talk or points raised in it available online
anywhere?
There i
On Fri, Feb 03, 2006 at 11:38:09AM -0800, Isaac Jones wrote:
> I would like to strive to find objective data on the use of
> extensions. I started a table here which summarizes how popular
> extensions are in real-life code. We need more data points, though.
>
> http://hackage.haskell.org/trac/h
Axel Simon <[EMAIL PROTECTED]> writes:
> The solution of representing a file name abstractly is also used by
> the Java libraries.
I think it is not. Besides using Java UTF-16 strings for filenames,
there is the File class, but it also uses Java strings. The
documentation of listFiles() says that
On Sat, 2006-02-04 at 15:11 +0100, John Hughes wrote:
> I noticed ticket #55--add parallel list comprehensions--which according to
> the ticket, will probably be adopted. I would argue against.
Can I second this?
The only time I ever used a parallel list comprehension was by accident.
I accidenta
Hello Tomasz,
Saturday, February 04, 2006, 12:39:38 PM, you wrote:
>> > make a strict Haskell dialect.
TZ> I am with you. If Haskell switches to strictness,
as i said, strict _dialect_ is interesting for optimization, moving
from other languages and making strict variants of data structures
--
Hello Dave,
Saturday, February 04, 2006, 3:52:46 AM, you wrote:
>> Now i'm trying to generalize my functions parameters/results to type
>> classes instead of single types. for example, getFileSize function can
>> return any numeric value, be it Integer, Word or Int64. This,
>> naturally, results i
Hello Marcin,
Saturday, February 04, 2006, 2:23:50 AM, you wrote:
>> if my idea was incorporated in Haskell, this change don't require
>> even changing signatures of most functions working with arrays -
>> just Array type become Array interface, what a much difference?
What would 'Eq -> Eq -> Ord
Hello John,
Friday, February 03, 2006, 8:11:48 PM, you wrote:
>> Yes. Plus, I'd say, the presence of threading primitives that return
>> certain well-defined exceptions or something along those lines, so that
>> it's not necessary to know whether multithreading is supported at
>> compile time.
I noticed ticket #55--add parallel list comprehensions--which according to
the ticket, will probably be adopted. I would argue against.
Firstly: because in its more general forms the notation is confusing. Try
this example:
[(i,j,k) | i<-[1..3], j<-[1..3] | k <- [1..9]]
In general it's hard to
Wolfgang Jeltsch wrote:
Since laziness often allows you to solve problems so elegantly, I'm really
scared of the idea of a "Strict Haskell"! :-( Is laziness really so "unreal"
that real-world programmers have to see it as an enemy which they have to
fight against?
Non-strictness gives you so
Chris Kuklewicz wrote:
Weak uses seq to achieve WHNF for it's argument
newtype Weak a = WeakCon {runWeak :: a}
mkWeak x = seq x (WeakCon x)
unsafeMkWeak x = WeakCon x
This doesn't actually do what you think it does. mkWeak and unsafeMkWeak are
the same function.
mkWeak 123 = seq 123 (W
On Thu, Feb 02, 2006 at 11:46:56PM +0100, Wolfgang Jeltsch wrote:
> Am Mittwoch, 1. Februar 2006 11:49 schrieb Bulat Ziganshin:
> > [...]
>
> > i had one idea, what is somewhat corresponding to his discussion:
> >
> > make a strict Haskell dialect. implement it by translating all
> > expressions o
28 matches
Mail list logo
