On Thu, Oct 16, 2008 at 05:31:50PM -0400, Isaac Dupree wrote:
> Christopher Lane Hinson wrote:
>>
>> I agree with David, we should be using multiplication, not addition.
>> However, I think that under the law of least surprise, we should
>> require that for all a,b,z:
>>
>> all (\x -> x >= a && x <
et exactly what they deserve if x is not included. Floating
> point numbers are not the real numbers, and the sooner they learn that
> the better. We can fudge this all we like, but 0.1 is never going to
> be exactly representable as a binary floating point number no matter
> what we do
On Wed, Oct 15, 2008 at 10:41:25AM +0100, Malcolm Wallace wrote:
> Dear Haskell-Primers (and libraries).
>
> Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98
> Prelude, regarding numeric enumerations for Floats/Doubles:
>
> Prelude> [0, 0.3 .. 1.1]
> [0.0,0.3,0.6,0.89
On Thu, Feb 01, 2007 at 09:12:02AM -0800, David Roundy wrote:
> On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote:
> > Next, i don't think that ability to use any functions in view buy
> > something important. pattern guards can be used for arbitrary
> > f
y a subset of the function syntax? Or is this valid code that causes an
error when you match
f (Polar r a) = ...
if the argument is Coord 0 0? If we don't allow this syntax (if statement
on the RHS of the matching definition), why not? The syntax you propose can
be used to decribe arbitrary f
st bombing out
when given invalid input. I suppose you'll point out that the view Coord
is a function that you can never explicitely call, but to me that just
makes things even more confusing. Now we're defining functions that we can
only use
to come up
with one above) that there are sets of pattern matches that aren't
reducible in that way, which it'd be nice to be able to express succinctly
by matching on failure to match a pattern.
Maybe this should be
foo (x, view /->, []) = foo2 x
or something like that, to indica
, for example to have something like
> > (a :<: b) rather than the always-vague (LT a b) which either reads the
> > same as the infix version or backwards.
> > [...]
>
> I think they are valid now!
Silly me! I didn't even think to try! Nice. And thanks!
ation, and yet still not too insane to
parse?
--
David Roundy
Department of Physics
Oregon State University
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
le Haskell',
even with the FFI.
It'd be nice, though, to see some work towards a set of "standard" (either
de facto or otherwise) libraries developed to work nicely with Haskell',
once that exists. But my guess is that it'd be best to wait quite a while
before set
On Sun, Oct 01, 2006 at 02:08:35AM +0200, Yitzchak Gale wrote:
> David Roundy wrote:
> >>foo (Left "bar") = "a"
> >>foo (Right x) | (b,"foo") <- break (==' ') x = "b " ++ b
> >> | ["Hello&quo
but " ++ n ++ " is " ++
init d ++ " fine."
> foo (Left x) | length x == 13 = "Unlucky!"
> foo (Right x) = x
> foo (Left x) = x
It's a contrived example, but the usefulness of pattern guards is only
greater on more realistic, more complicated functions.
--
David Roundy
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
close-to-limiting case, when a pure function might run for longer than
your desired latency. His spec does this in a rigorous, but achievable
manner (i.e. a useful spec).
--
David Roundy
http://www.darcs.net
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
rtant long-running ffi call
to make, and didn't want exiting to be slowed down by waiting for it to
complete. It would definitely be nice to have interruptible ffi calls (and
not just interruptible by exiting), but I'm not really sure how one would
go about that.
--
David Roundy
http://ww
bracket and once by the exit handler.
If signals don't generate exceptions, I'd at least like some sort of
really_bracket to make it into the standard, as this is probably the most
troublesome aspect of existing Haskell.
--
David Roundy
http://www.darcs.net
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
e you could do this with a (cooperative) implementation
of asynchronous exceptions using just MVars and concurrency by rewriting
all the IO calls you use to first check whether an asynchronous exception
has been thrown, but rewriting all the std library functions seems like a
rather crude way of
On Sun, Apr 02, 2006 at 11:38:23PM -0700, John Meacham wrote:
> On Sat, Apr 01, 2006 at 07:31:05AM -0500, David Roundy wrote:
> > I'd like to be sure that asynchronous exceptions can get into the
> > standard. They require concurrency, but I'm not sure that they'
g guarantees, but would seem convenient. It
might also relax the requirement that yield will always switch threads,
allowing the implementation to decide not to switch too frequently if yield
is called very often. Or introduce a maybe_yield that is weaker.
--
David Roundy
http://www.darcs.net
_
ared that this couldn't be
fixed. jhc's behavior sounds nicer, but I'd rather there were the
possibility of naming our haskell files whatever we liked. Currently, as
far as I can see, we can only do this with Main, and even then there are
weirdnesses in ghc because Main.hi gets g
19 matches
Mail list logo
