2008/3/11, David Menendez <[EMAIL PROTECTED]>:
> I think Adrian is just arguing that a == b should imply f a == f b,
> for all definable f, in which case it doesn't *matter* which of two
> equal elements you choose, because there's no semantic difference.
>
> (Actually, it's probably not desirab
On 11 Mar 2008, at 12:27 pm, Krzysztof Skrzętnicki wrote:
I've written little framework to work on. See sortbench.hs and
sortbench.py attachments.
Furthermore, I checked Yhc's implementation of sort: it is indeed
very fast:
I took his earlier code and plugged yhc's sort into it.
Compiling
On Mon, Mar 10, 2008 at 9:08 PM, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
> On 10 Mar 2008, at 4:00 AM, Adrian Hey wrote:
>
> > I would consider such an Ord instance to be hopelessly broken, and I
> > don't think it's the responsibility of authors of functions with Ord
> > constraints in their s
On 10 Mar 2008, at 4:00 AM, Adrian Hey wrote:
Neil Mitchell wrote:
2) What does it do with duplicate elements in the list? I expect
it deletes
them. To avoid this, you'd need to use something like
fromListWith, keeping
track of how many duplicates there are, and expanding at the end.
Th
On 10 Mar 2008, at 12:37 AM, Donn Cave wrote:
On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
Errors are programming errors and must be fixed as Denis
explained. Thus
there is no need for a complex system of handling these situations at
run-time. The program error might be unexpect
Hi all,
I have encoded a type family such that:
type family F a :: * -> *
and a function (I know it is complicated, but I think the problem is self
explanatory):
hyloPara :: (Functor (F a), Functor (F d), F d a ~ F a (a,a), F d c ~ F a
(c,a)) => d -> (F d c -> c) -> (a -> F d a) -> a -> c
hyloPa
2008/3/10 Krzysztof Skrzętnicki <[EMAIL PROTECTED]>:
> In Python the syntax to create 1-tuple is (element,). Note the ",". It's not
> the most beautiful but is acceptable.
But that syntax ought to be for tuple sections. Is there a good
reason that Haskell doesn't have tuple sections?
("hello",
Roman Cheplyaka:
I'm looking for interesting project to work on during Google Summer of
Code. So I found [1]"A data parallel physics engine" ticket and got
excited about it. I'd like to know interested mentors and community
opinion about the complexity of such project.
I have not very deep knowl
Hi
> In Python the syntax to create 1-tuple is (element,). Note the ",". It's not
> the most beautiful but is acceptable.
But in Haskell we can write tuples in infix syntax, i.e. (,) is the 2
tuple. Unfortunately, this syntax doesn't suggest anything for the
infix 1-tuple, and clashes with the 2-
In Python the syntax to create 1-tuple is *(element,)*. Note the ",". It's
not the most beautiful but is acceptable.
Christopher Skrzętnicki
On Tue, Mar 11, 2008 at 12:24 AM, Neil Mitchell <[EMAIL PROTECTED]>
wrote:
> Hi
>
> > I understand the lack of distinction between a unit type and a 0-tu
Hi all,
I've been plugging away at this all day and some discussion in
#haskell has been fruitless. Perhaps you have the inspiration to see
what's happening!
Concerning this minimal example:
http://hpaste.org/6268
It works as required, loading K/V pairs into a Data.Map, the concern
is the amount
I've written little framework to work on. See sortbench.hs and
sortbench.pyattachments.
Furthermore, I checked Yhc's implementation of sort: it is indeed very fast:
[EMAIL PROTECTED] sorting]$ python sortbench.py
Benchmark type: OnSorted
[1 of 1] Compiling Main ( sortbench.hs, sortbenc
Hi
> I understand the lack of distinction between a unit type and a 0-tuple,
> since they are isomorphic.
It's more we pronounce 0-tuple as unit, they are identical.
> But it is strange that there is no 1-tuple,
> since _|_ and the 1-tuple (_|_) would be different things entirely, no?
Yes, i
I understand the lack of distinction between a unit type and a 0-tuple,
since they are isomorphic. But it is strange that there is no 1-tuple,
since _|_ and the 1-tuple (_|_) would be different things entirely, no?
Dan
Rodrigo Queiro wrote:
You're looking for mapM_
mapM_ :: (Monad m) => (a ->
At Mon, 10 Mar 2008 22:11:33 +,
Paulo J. Matos wrote:
> I would like to know if in fact there's any difference in practice
> between (), [()], i.e. if in practice the difference matters.
Well, you could do something like this:
outputLines :: Int -> IO [()]
outputLines i = mapM (putStrLn . sh
On Mon, Mar 10, 2008 at 3:11 PM, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> I would like to know if in fact there's any difference in practice
> between (), [()], i.e. if in practice the difference matters.
The type [()] is very similar to the type Integer and it's quite
different from () becau
On Mon, Mar 10, 2008 at 11:48 PM, Daniel Fischer
<[EMAIL PROTECTED]> wrote:
> But print is (putStrLn . show), so what may be missing is (putStr . show).
That's what I meant sorry ..
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haske
Hi
> BTW, considering how often is (putStrLn.show) used, it is surprising
> that there is no Ln variant for print (just like it happens with
> putStr and putStrLn)
print = putStrLn . show
There is no non-trailing-line version of print.
Thanks
Neil
__
Am Montag, 10. März 2008 23:34 schrieb Alfonso Acosta:
> On Mon, Mar 10, 2008 at 11:11 PM, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> > outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1)
> >
> > However, this is in fact
> > outputLines :: Int -> IO [()]
>
> As others suggested
On Mon, Mar 10, 2008 at 7:34 PM, Alfonso Acosta
<[EMAIL PROTECTED]> wrote:
> BTW, considering how often is (putStrLn.show) used, it is surprising
> that there is no Ln variant for print (just like it happens with
> putStr and putStrLn)
Actually,
> print = putStrLn . show
so
> outputLines i
G'day all.
Quoting Dan Weston <[EMAIL PROTECTED]>:
6.3.2 (The Ord Class):
"The Ord class is used for totally ordered datatypes."
So... Double shouldn't be there, then?
As previously noted, nowhere is it even required that x /= y should
"do the same thing" as not (x == y).
Cheers,
Andrew Br
On Mon, Mar 10, 2008 at 11:11 PM, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1)
>
> However, this is in fact
> outputLines :: Int -> IO [()]
As others suggested you can use mapM_
Furthermore, you can simplify it a bit with some
On Mon, Mar 03, 2008 at 10:56:55PM -0600, Galchin Vasili wrote:
>Say i am building package X that depends on A, H, D. How can I
> automagically check to A, H, D need to "darcs get" down and built/install
> before X? If this feature is not available it should be, i.e. an integration
> of darcs
On Mon, Mar 10, 2008 at 10:11:33PM +, Paulo J. Matos wrote:
> mapM :: (Monad m) => (a -> m b) -> [a] -> m [b]
>
> So I guess that it makes sense that you get IO [()] instead of IO (),
> and adding an exception just to say that [()] == () isn't good.
> By the way, as a consequence can you possi
You're looking for mapM_
mapM_ :: (Monad m) => (a -> m b) -> [a] -> m ()
(see also sequence_ :: (Monad m) => [m a] -> m () )
I don't think that it is possible to have a 1-tuples, just 2 and up. () is a
unit rather than a 0-tuple, apparently:
http://www.haskell.org/onlinereport/basic.html#sect6.1.4
Hi
> I would like to know if in fact there's any difference in practice
> between (), [()], i.e. if in practice the difference matters.
Usually, not so much. A lot of Monad functions have _ variants, i.e.
mapM and mapM_. If you don't need the result, use the mapM_ version,
as it will run faster
Hello all,
I find it funny that IO () is different from IO [()].
For example, if I define a function to output some lines with mapT, I would do:
outputLines :: Int -> IO ()
outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1)
However, this is in fact
outputLines :: Int -> IO [()]
Am Montag, 10. März 2008 21:34 schrieb Neil Mitchell:
> Hi
>
> > But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '='
> > means identity. Now what does (should) 'identity' mean?
>
> I think you are using the word identity when the right would would be
> equality. Hence, the answer
On Mon, Mar 10, 2008 at 10:13 PM, Adrian Hey <[EMAIL PROTECTED]> wrote:
>
> (sort [a,b]) in the case we have: (compare a b = EQ)
>
> Which of the following 4 possible results are correct/incorrect?
> 1- [a,a]
> 2- [a,b]
> 3- [b,a]
> 4- [b,b]
I'd say 2 and 3 are sane, while 2 is correct - because
Hi
> (sort [a,b]) in the case we have: (compare a b = EQ)
>
> Which of the following 4 possible results are correct/incorrect?
> 1- [a,a]
> 2- [a,b]
> 3- [b,a]
> 4- [b,b]
Fortunately the Haskell sort is meant to be stable, and sorting is
meant to be a permutation, so we happily have the sit
Krzysztof Skrze;tnicki wrote:
Ok, my turn now. Let's think about algorithm that takes equivalence
relation EQ, ordering relation ORD on abstraction classes generated by
this equivalence ( -> equivalence classes ) and divides given input
elements XS into appropriate classes and then prints them
Hi
> If x <= y && y <= x does not imply that x == y, then Ord has no business
> being a subclass of Eq. By your logic, there is absolutely no
> constructive subclassing going on here, only an existence proof of (==)
> given (<=). What is the rational basis of such an existence claim,
> unless
If x <= y && y <= x does not imply that x == y, then Ord has no business
being a subclass of Eq. By your logic, there is absolutely no
constructive subclassing going on here, only an existence proof of (==)
given (<=). What is the rational basis of such an existence claim,
unless == has the obv
Hi
> But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' means
> identity. Now what does (should) 'identity' mean?
I think you are using the word identity when the right would would be
equality. Hence, the answer is, without a doubt, (==). If you define
equality, then you are
No, '=' should not mean an identity but any equivalence relation. Therefore,
we can use whatever equivalence relation suits us. The reasoning you
provided is IMHO rather blur. Anyway, having possibility of using different
equivalence relations is great because they mean different abstraction
classe
Am Montag, 10. März 2008 20:12 schrieb Neil Mitchell:
> Hi
>
> > "The Ord class is used for totally ordered datatypes."
> >
> > This *requires* that it be absolutely impossible in valid code to
> > distinguish equivalent (in the EQ sense, not the == sense) things via
> > the functions of Ord. T
It certainly makes perfect sense, because total order antisymmetry law
states that
IF a <= b AND b <= a THEN a = b
However it should rather be written
IF a <= b AND b <= a THEN a ~= b,
since = could be any equivalence class. However, we can also specify the Ord
on type
type Foo = Foo Int (Int-
On Mon, Mar 10, 2008 at 3:12 PM, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Hi
>
>
> > "The Ord class is used for totally ordered datatypes."
> >
> > This *requires* that it be absolutely impossible in valid code to
> > distinguish equivalent (in the EQ sense, not the == sense) things via
>
Hi
> "The Ord class is used for totally ordered datatypes."
>
> This *requires* that it be absolutely impossible in valid code to
> distinguish equivalent (in the EQ sense, not the == sense) things via
> the functions of Ord. The intended interpretation of these functions is
> clear and can b
On the other hand, though the behavior of == is not defined by the
Report, it does require in 6.3.1 that if compare is defined, then ==
must be defined. That strongly implies a semantic causal link (in the
Free Theorem kind of way), that the semantics of Ord completely specify
the semantics of
Ok, my turn now. Let's think about algorithm that takes equivalence relation
EQ, ordering relation ORD on abstraction classes generated by this
equivalence ( -> equivalence classes ) and divides given input elements XS
into appropriate classes and then prints them out according to given
ordering OR
> Unfortunately the Haskell standards don't currently specify sane laws
> for Eq and Ord class instances, but they should.
In fact there are requirements in the Haskell98 report:
6.3 Standard Haskell Classes
Note the word "reasonable" in the paragraph below:
"Default class method declarations
Neil Mitchell wrote:
Hi
We're talking about *semantic correctness*, not efficiency. If you
want to fine tune your code like this you shouldn't be relying
on overloaded general purpose function implementations. E.G. the
COrdering type used by AVL lib is one way to do this. This lets
a combi
Roman Cheplyaka wrote:
> I have not very deep knowledge about both NDP and physics engines.
I've done some physics simulation work for games. One could certainly
learn enough to be able to write a straightforward implementation in
that time. Broadphase collision detection is easy; narrowphase s
Neil Mitchell wrote:
> instance Eq Foo where
> (==) (Foo a _) (Foo b _) = (==) a b
[...]
> Please give the sane law that this ordering violates. I can't see any!
The (non-existant) law would be
(Eq1) x == y => f x == f y, for all f of appropriate type
which is analogous to this (exi
On Mon, Mar 10, 2008 at 12:19 PM, Adrian Hey <[EMAIL PROTECTED]> wrote:
> Denis Bueno wrote:
> > On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey <[EMAIL PROTECTED]> wrote:
> >> >> The Eq instance you've given violates the law that (x == y) = True
> >> >> implies x = y. Of course the Haskell sta
Denis Bueno wrote:
On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey <[EMAIL PROTECTED]> wrote:
>> The Eq instance you've given violates the law that (x == y) = True
>> implies x = y. Of course the Haskell standard doesn't specify this law,
>> but it should.
Unless I'm missing something obvio
Duncan Coutts wrote:
Sounds to me like we should try a heap sort. As a data structure it
should have similar constant factors to Data.Map (or .Set) but a heap is
less ordered than a search tree and gives the O(n + k*log n) property.
Thanks to lazyness, mergesort is really a heapsort in disgui
Hi
> We're talking about *semantic correctness*, not efficiency. If you
> want to fine tune your code like this you shouldn't be relying
> on overloaded general purpose function implementations. E.G. the
> COrdering type used by AVL lib is one way to do this. This lets
> a combining compariso
Ketil Malde wrote:
Adrian Hey <[EMAIL PROTECTED]> writes:
But seriously, once you admit the possibility that even if x == y it
still matters which of x or y is used in expressions than all hell
breaks loose. I shudder to think just how much Haskell code there must
be out there that is (at best)
On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey <[EMAIL PROTECTED]> wrote:
> >> The Eq instance you've given violates the law that (x == y) = True
> >> implies x = y. Of course the Haskell standard doesn't specify this law,
> >> but it should.
Unless I'm missing something obvious, the example N
Bulat Ziganshin wrote:
Hello Adrian,
Monday, March 10, 2008, 2:00:18 PM, you wrote:
instance Ord Foo where
compare (Foo a _) (Foo b _) = compare a b
I would consider such an Ord instance to be hopelessly broken, and I
h. for example, imagine files in file manager sorted by size or
Adrian Hey <[EMAIL PROTECTED]> writes:
> But seriously, once you admit the possibility that even if x == y it
> still matters which of x or y is used in expressions than all hell
> breaks loose. I shudder to think just how much Haskell code there must
> be out there that is (at best) ambiguious or
I'm looking for interesting project to work on during Google Summer of
Code. So I found [1]"A data parallel physics engine" ticket and got
excited about it. I'd like to know interested mentors and community
opinion about the complexity of such project.
I have not very deep knowledge about both NDP
Neil Mitchell wrote:
Hi
The Eq instance you've given violates the law that (x == y) = True
implies x = y. Of course the Haskell standard doesn't specify this law,
but it should.
Wrong. It shouldn't,
Should too
it doesn't,
indeed
and I don't think it even can!
Well we need to be p
On Mar 10, 2008, at 9:55 , Zsolt SZALAI wrote:
Er? Refactoring the grammar like that is the clean and preferred
way. But if you insist, use the try combinator.
Oh, all right, i was trying to be loyal to the BNF in standard.
BNF doesn't necessarily apply cleanly to all types of parsers.
>
>
> Er? Refactoring the grammar like that is the clean and preferred
> way. But if you insist, use the try combinator.
>
Oh, all right, i was trying to be loyal to the BNF in standard.
>
> structuredTypeDef = try recordDef <|> recordOfDef
>
> --
> brandon s. allbery [solaris,freebsd,perl
On Mar 10, 2008, at 9:41 , Zsolt SZALAI wrote:
It is a possibility to do something like swap "recordDef <|>
recordOfDef" with "recordlikeDefs "
where recordlikeDefs = do { reserved "record" ; others }
but that would be the dirty way...
Er? Refactoring the grammar like that is the clean a
Hi!
I'm writing a parser for a language, with a BNF like this:
Type = "type" Def
Def = RecordDef | RecordOfDef ...
RecordDef = "record" Body
RecordOfDef = "record" "of"
With a perser what uses parsec module it can be mapped to haskell easily:
structuredTypeDef = recordDef
<|>
Hi
> The Eq instance you've given violates the law that (x == y) = True
> implies x = y. Of course the Haskell standard doesn't specify this law,
> but it should.
Wrong. It shouldn't, it doesn't, and I don't think it even can!
> The Haskell standard doen't even specify that compare x y = EQ
Luke Palmer wrote:
It could be. I actually don't know what Haskell specifies here. If a
type has an Eq instance and x == y, must x and y be observationally
equivalent?
I would say yes, without exception, at least as far as the public
(exported) interface is concerned.
Or is it reasonable t
Hello Adrian,
Monday, March 10, 2008, 2:00:18 PM, you wrote:
>> instance Ord Foo where
>> compare (Foo a _) (Foo b _) = compare a b
> I would consider such an Ord instance to be hopelessly broken, and I
h. for example, imagine files in file manager sorted by size or date
--
Best rega
On Monday 10 March 2008, Neil Mitchell wrote:
> That would be wrong. Consider:
>
> data Foo = Foo Int Int
>
> instance Ord Foo where
> compare (Foo a _) (Foo b _) = compare a b
>
> sort [Foo 1 2, Foo 1 -2] must return the original list back, in that
> order. You cannot delete things and duplica
Neil Mitchell wrote:
Hi
> instance Ord Foo where
> compare (Foo a _) (Foo b _) = compare a b
I would consider such an Ord instance to be hopelessly broken, and I
don't think it's the responsibility of authors of functions with Ord
constraints in their sigs (such as sort) to consider s
Hi
> > instance Ord Foo where
> > compare (Foo a _) (Foo b _) = compare a b
>
> I would consider such an Ord instance to be hopelessly broken, and I
> don't think it's the responsibility of authors of functions with Ord
> constraints in their sigs (such as sort) to consider such possibili
On Mon, Mar 10, 2008 at 11:00 AM, Adrian Hey <[EMAIL PROTECTED]> wrote:
> Neil Mitchell wrote:
> >> 2) What does it do with duplicate elements in the list? I expect it
> deletes
> >> them. To avoid this, you'd need to use something like fromListWith,
> keeping
> >> track of how many duplica
Adrian Hey wrote:
or specify and control the behaviour of their behaviour for such
instances.
Urk, sorry for the gibberish. I guess I should get into the habit of
reading what I write before posting :-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailin
Neil Mitchell wrote:
2) What does it do with duplicate elements in the list? I expect it deletes
them. To avoid this, you'd need to use something like fromListWith, keeping
track of how many duplicates there are, and expanding at the end.
That would be wrong. Consider:
data Foo = Foo Int In
On Mon, 10 Mar 2008, Donn Cave wrote:
On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
How precisely would you handle IndexError if it would be an exception and
not just an error?
Well, to take a hypothetical example ... I have never looked into JPEG
image decoding, but suppose that it
On 10 Mar 2008, at 08:36, Neil Mitchell wrote:
Can whoever picks this up please try the sort code from Yhc in their
comparisons. In my benchmarks it ran up to twice as fast as the GHC
code. http://darcs.haskell.org/yhc/src/packages/yhc-base-1.0/Data/List.hs
I believe the Yhc sort implementatio
Hi
Can whoever picks this up please try the sort code from Yhc in their
comparisons. In my benchmarks it ran up to twice as fast as the GHC
code. http://darcs.haskell.org/yhc/src/packages/yhc-base-1.0/Data/List.hs
I think what we really need is first quickCheck and timing framework
for measuring
On Mon, Mar 10, 2008 at 7:37 AM, Donn Cave <[EMAIL PROTECTED]> wrote:
>
> On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
>
> >
> > Errors are programming errors and must be fixed as Denis explained.
> > Thus
> > there is no need for a complex system of handling these situations at
> >
Hi
> 2) What does it do with duplicate elements in the list? I expect it deletes
> them. To avoid this, you'd need to use something like fromListWith, keeping
> track of how many duplicates there are, and expanding at the end.
That would be wrong. Consider:
data Foo = Foo Int Int
instance Or
On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
Errors are programming errors and must be fixed as Denis explained.
Thus
there is no need for a complex system of handling these situations at
run-time. The program error might be unexpected but it isn't the
fault of
the user or of th
74 matches
Mail list logo
