On Thu, 27 Dec 2007 17:45:04 +0200, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
On 27 Dec 2007, at 9:34 AM, Cristian Baboi wrote:
I'll have to trust you, because I cannot test it.
let x=(1:x); y=(1:y) in x==y .
I also cannot test this:
let x=(1:x); y=1:1:y in x==y
Correct. You could try p
On Thu, 27 Dec 2007 17:39:25 +0200, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
Haskell is not a computer programming language; Haskell implementations
are not required to run on computers. Haskell is a formal notation for
computation (completely unrelated to the Von Neuman machine sitting on
On Thu, 27 Dec 2007 17:35:54 +0200, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
Only on Von Neuman machines. Haskell implementations are not required
to run on Von Neuman machines. That's why the language is called
functional. (Imperative languages, by contrast, are just abstractions
of
On Thu, 27 Dec 2007 18:19:47 +0200, Wolfgang Jeltsch
<[EMAIL PROTECTED]> wrote:
Am Donnerstag, 27. Dezember 2007 16:34 schrieb Cristian Baboi:
I'll have to trust you, because I cannot test it.
let x=(1:x); y=(1:y) in x==y .
I also cannot test this:
let x=(1:x); y=1:1:y in x==y
In these e
On Thu, 27 Dec 2007 18:14:53 +0200, Wolfgang Jeltsch
<[EMAIL PROTECTED]> wrote:
Am Donnerstag, 27. Dezember 2007 15:53 schrieb Cristian Baboi:
On Thu, 27 Dec 2007 16:50:10 +0200, Lennart Augustsson
<[EMAIL PROTECTED]> wrote:
> Absolutly. Every expression in Haskell denotes a value.
> Now, w
On Thu, 27 Dec 2007 18:13:57 +0200, Wolfgang Jeltsch
<[EMAIL PROTECTED]> wrote:
Am Donnerstag, 27. Dezember 2007 16:57 schrieb Cristian Baboi:
On Thu, 27 Dec 2007 17:52:19 +0200, Jonathan Cast
> Which is why Haskell treats IO as a domain specific language.
Good to know. I intended to use Has
On Thu, 27 Dec 2007 18:45:23 +0200, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
On 27 Dec 2007, at 9:57 AM, Cristian Baboi wrote:
Good to know. I intended to use Haskell for algorithms, but it seems it
is not so good at them.
Very sad. The entire point of Haskell is that it allows the user
On 27 Dec 2007, at 8:38 PM, Albert Y. C. Lai wrote:
Achim Schneider wrote:
[n..] == [m..], the first thing I notice is
n == m && n+1 == m+1
, which already expresses all of infinity in one instance and can be
trivially cancelled to
n == m
, which makes the whole darn thing only _|_ if n or m is
This monad seems to be basically the same as Prompt; see
http://www.haskell.org/pipermail/haskell-cafe/2007-November/034830.html, the
only difference I see is that Prompt allows the return value's type to
be based on the request instead of forcing everything to be wrapped in a
single result type.
Achim Schneider wrote:
[n..] == [m..],
the first thing I notice is
n == m && n+1 == m+1
, which already expresses all of infinity in one instance and can be
trivially cancelled to
n == m
, which makes the whole darn thing only _|_ if n or m is _|_, which no
member of [n..] can be as long as
Don Stewart <[EMAIL PROTECTED]> writes:
> "A Wake Up Call for the Logic Programming Community"
>
>
> http://www.cs.kuleuven.ac.be/%7Edtai/projects/ALP//newsletter/dec07/content/Articles/tom/content.html
>
> Interesting read!
Clearly, the logic programming people are vastly more successful at
"Tim Docker" <[EMAIL PROTECTED]> wrote:
> I'm using a control structure that's a variation of a monad and I'm
> interested in whether
>
> - it's got a name
> - it deserves a name (!)
> - anything else similar is used elsewhere
>
You might have reinvented arrows in some sense:
http://
I'm using a control structure that's a variation of a monad and I'm
interested in whether
- it's got a name
- it deserves a name (!)
- anything else similar is used elsewhere
Please excuse the longer post...
I have two programs that need to interact with the outside world, and
I wan
* Justin Bailey wrote:
> When I joined the haskell-cafe mailing list, I was surprised to see
> the "reply-to" header on each message was set to the sender of a given
> message to the list, rather than the list itself.
That's good practice.
> That seemed counter to other mailing lists I had been s
On Dec 27, 2007 3:36 PM, Justin Bailey <[EMAIL PROTECTED]> wrote:
> When I joined the haskell-cafe mailing list, I was surprised to see
> the "reply-to" header on each message was set to the sender of a given
> message to the list, rather than the list itself. That seemed counter
> to other mailin
When I joined the haskell-cafe mailing list, I was surprised to see
the "reply-to" header on each message was set to the sender of a given
message to the list, rather than the list itself. That seemed counter
to other mailing lists I had been subscribed to, but I didn't think
too much about it.
We
On 27 Dec 2007, at 4:54 PM, Achim Schneider wrote:
Jonathan Cast <[EMAIL PROTECTED]> wrote:
_|_ is the denotation of every Haskell expression whose
denotation is _|_.
Mu.
Why take away _|_?
Because, when zenning about
instance (Eq a) => Eq [a] where
[] == [] = True
(x:xs
Jonathan Cast <[EMAIL PROTECTED]> wrote:
>
> _|_ is the denotation of every Haskell expression whose
> denotation is _|_.
>
Mu.
> Why take away _|_?
>
Because, when zenning about
instance (Eq a) => Eq [a] where
[] == [] = True
(x:xs) == (y:ys) = x == y && xs == ys
_xs==
Alfonso Acosta wrote:
> 2) Think of a change in the internal representation of signals which
> made polymorphic processes possible. Polymorphic processes don't have
> to
> be necessarily definable by the user. They should be happy enough
> with a few polymorphic primitives (mapSnd would be one
On the one hand I like to use lists in my code because element types can
be freely chosen and maximum laziness allows feedback and other tricks. On
the other hand there are ByteString.Lazy and one could build chunky
sequences from other fast array implementations. They have constraints on
the elem
Bulat Ziganshin wrote:
here T is any type. you said that values of ANY TYPE can be saved to
disk, so show us the way
...
try to prove that this mean that value of ANY type may be saved to
disk
Run another program that uses lots of memory, and watch the entire
Haskell program's memory be sw
Wolfgang Jeltsch wrote:
>> If x doesn't equal y, x == y is False, but if x
>> equals y, x == y might be True or undefined.
apfelmus wrote:
> x == y may be _|_ for the False case, too, depending on its
> implementation (like first comparing all list elements on even indices
> and then comparing al
On Tue, 25 Dec 2007, Felipe Lessa wrote:
> On Dec 25, 2007 4:27 PM, Henning Thielemann
> <[EMAIL PROTECTED]> wrote:
> > test :: (Integral a, RealFrac a) => a
> > test =
> >let c = undefined
> >in asTypeOf (round c) c
> >
> >
> > When compiling I get:
> >
> > Compiling StorableInstance (
On 27 Dec 2007, at 12:20 PM, Achim Schneider wrote:
Jonathan Cast <[EMAIL PROTECTED]> wrote:
On 27 Dec 2007, at 10:44 AM, Achim Schneider wrote:
Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
Am Donnerstag, 27. Dezember 2007 16:34 schrieb Cristian Baboi:
I'll have to trust you, because I can
apfelmus <[EMAIL PROTECTED]> wrote:
>
> Ah, that's only a glitch in the wording. [1..] == [1..] is still _|_
> since it loops forever.
>
And if it wouldn't? After all, arguing that |N == |N is undefined
because it takes too long to check would earn you a straight F in any
math test.
It's just th
Achim Schneider wrote:
Jonathan Cast wrote:
More importantly, we can prove that [1..] == [1..] = _|_, since
[1..] == [1..]
= LUB (n >= 1) [1..n] ++ _|_ == [1..n] ++ _|_
= LUB (n >= 1) _|_
= _|_
As far as I understand
http://www.haskell.org/haskellwiki/Bottom
, only computations which canno
Jonathan Cast <[EMAIL PROTECTED]> wrote:
> On 27 Dec 2007, at 10:44 AM, Achim Schneider wrote:
>
> > Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> >
> >> Am Donnerstag, 27. Dezember 2007 16:34 schrieb Cristian Baboi:
> >>> I'll have to trust you, because I cannot test it.
> >>>
> >>> let x=(1:x);
"A Wake Up Call for the Logic Programming Community"
Or what the logic programming community can learn from the Haskell
community (in particular):
http://www.cs.kuleuven.ac.be/%7Edtai/projects/ALP//newsletter/dec07/content/Articles/tom/content.html
Interesting read!
-- Don
On 27 Dec 2007, at 10:44 AM, Achim Schneider wrote:
Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
Am Donnerstag, 27. Dezember 2007 16:34 schrieb Cristian Baboi:
I'll have to trust you, because I cannot test it.
let x=(1:x); y=(1:y) in x==y .
I also cannot test this:
let x=(1:x); y=1:1:y in x
Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 27. Dezember 2007 16:34 schrieb Cristian Baboi:
>> I'll have to trust you, because I cannot test it.
>>
>> let x=(1:x); y=(1:y) in x==y .
>>
>> I also cannot test this:
>>
>> let x=(1:x); y=1:1:y in x==y
>
> In these examples, x and y d
On 27 Dec 2007, at 9:57 AM, Cristian Baboi wrote:
Good to know. I intended to use Haskell for algorithms, but it
seems it is not so good at them.
Very sad. The entire point of Haskell is that it allows the user to
transcend the algorithm as a way of expressing computations.
I hope someda
Wolfgang Jeltsch wrote:
If x doesn’t equal y, x == y is False, but if x
equals y, x == y might be True or undefined.
x == y may be _|_ for the False case, too, depending on its
implementation (like first comparing all list elements on even indices
and then comparing all list elements on odd
Am Donnerstag, 27. Dezember 2007 16:34 schrieb Cristian Baboi:
> I'll have to trust you, because I cannot test it.
>
> let x=(1:x); y=(1:y) in x==y .
>
> I also cannot test this:
>
> let x=(1:x); y=1:1:y in x==y
In these examples, x and y denote the same value but the result of x == y is
_|_ (und
Am Donnerstag, 27. Dezember 2007 15:53 schrieb Cristian Baboi:
> On Thu, 27 Dec 2007 16:50:10 +0200, Lennart Augustsson
>
> <[EMAIL PROTECTED]> wrote:
> > Absolutly. Every expression in Haskell denotes a value.
> > Now, we've not agreed what "value" means, but to me it is a value. :)
>
> It is one
Am Donnerstag, 27. Dezember 2007 16:57 schrieb Cristian Baboi:
> On Thu, 27 Dec 2007 17:52:19 +0200, Jonathan Cast
> > Which is why Haskell treats IO as a domain specific language.
>
> Good to know. I intended to use Haskell for algorithms, but it seems it is
> not so good at them.
Why is I/O need
Good to know. I intended to use Haskell for algorithms, but it seems it is
not so good at them.
On Thu, 27 Dec 2007 17:52:19 +0200, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
On 27 Dec 2007, at 9:47 AM, Cristian Baboi wrote:
I don't know. I'm a beginner in Haskell, and I down't know ab
On 27 Dec 2007, at 9:47 AM, Cristian Baboi wrote:
I don't know. I'm a beginner in Haskell, and I down't know
about T.
You mean they cannot ?
I was under the impression that the purpose of computers cannot
be fulfiled if we cannot get the result of computations out of
the computers.
H
I don't know. I'm a beginner in Haskell, and I down't know about T.
You mean they cannot ?
I was under the impression that the purpose of computers cannot be
fulfiled if we cannot get the result of computations out of the
computers.
Haskell is not a computer programming language; Haskell
On 27 Dec 2007, at 9:41 AM, Cristian Baboi wrote:
On Thu, 27 Dec 2007 17:39:25 +0200, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
On 27 Dec 2007, at 6:51 AM, Cristian Baboi wrote:
On Thu, 27 Dec 2007 14:42:37 +0200, Bulat Ziganshin
<[EMAIL PROTECTED]> wrote:
Hello Cristian,
Thursday, Dec
On 27 Dec 2007, at 9:34 AM, Cristian Baboi wrote:
I'll have to trust you, because I cannot test it.
let x=(1:x); y=(1:y) in x==y .
I also cannot test this:
let x=(1:x); y=1:1:y in x==y
Correct. You could try proving it.
Or you could try proving that these expressions are equal to _|_.
On 27 Dec 2007, at 8:53 AM, Cristian Baboi wrote:
On Thu, 27 Dec 2007 16:50:10 +0200, Lennart Augustsson
<[EMAIL PROTECTED]> wrote:
Absolutly. Every expression in Haskell denotes a value.
Now, we've not agreed what "value" means, but to me it is a value. :)
It is one value, or several ?
On 27 Dec 2007, at 8:28 AM, Cristian Baboi wrote:
How about x below:
let x=(1:x) in x ?
Is x a single value in Haskell ?
(let x=1:x in x) is. x went out of scope a couple of lines back.
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Thu, 27 Dec 2007 17:39:25 +0200, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
On 27 Dec 2007, at 6:51 AM, Cristian Baboi wrote:
On Thu, 27 Dec 2007 14:42:37 +0200, Bulat Ziganshin
<[EMAIL PROTECTED]> wrote:
Hello Cristian,
Thursday, December 27, 2007, 12:19:08 PM, you wrote:
Yes, but on
On 27 Dec 2007, at 8:08 AM, Cristian Baboi wrote:
On Thu, 27 Dec 2007 14:02:36 +0200, Lennart Augustsson
<[EMAIL PROTECTED]> wrote:
Comparing functions is certainly possible in Haskell, but there's no
standard function that does it.
If course, it might not terminate, but the same is true for
On 27 Dec 2007, at 6:51 AM, Cristian Baboi wrote:
On Thu, 27 Dec 2007 14:42:37 +0200, Bulat Ziganshin
<[EMAIL PROTECTED]> wrote:
Hello Cristian,
Thursday, December 27, 2007, 12:19:08 PM, you wrote:
Yes, but one can store the result of an operation to disk except
in the
particular case t
On 27 Dec 2007, at 4:57 AM, Cristian Baboi wrote:
On Thu, 27 Dec 2007 12:40:22 +0200, Yitzchak Gale <[EMAIL PROTECTED]>
wrote:
I wrote:
On the other hand, functions are members of types
that are just like any other Haskell type. They are
first-class in that sense.
Cristian Baboi wrote:
I
I'll have to trust you, because I cannot test it.
let x=(1:x); y=(1:y) in x==y .
I also cannot test this:
let x=(1:x); y=1:1:y in x==y
On Thu, 27 Dec 2007 17:29:12 +0200, Lennart Augustsson
<[EMAIL PROTECTED]> wrote:
One value. One "infinite" value.
On Dec 27, 2007 3:53 PM, Cristian
One value. One "infinite" value.
On Dec 27, 2007 3:53 PM, Cristian Baboi <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Dec 2007 16:50:10 +0200, Lennart Augustsson
> <[EMAIL PROTECTED]> wrote:
>
> > Absolutly. Every expression in Haskell denotes a value.
> > Now, we've not agreed what "value" means, b
Simon Peyton-Jones wrote:
As others have pointed out, GHC allows you to put a context on any data constructor. I
prefer this "where" syntax:
But, in 6.8.x, you will need -XGADTS to permit this.
6.6.x permitted it anyway, arguably in error.
http://hackage.haskell.org/trac/ghc/ticket/1901
Ju
On Thu, 27 Dec 2007 16:50:10 +0200, Lennart Augustsson
<[EMAIL PROTECTED]> wrote:
Absolutly. Every expression in Haskell denotes a value.
Now, we've not agreed what "value" means, but to me it is a value. :)
It is one value, or several ?
Information from NOD32
This messa
Absolutly. Every expression in Haskell denotes a value.
Now, we've not agreed what "value" means, but to me it is a value. :)
-- Lennart
On Dec 27, 2007 3:28 PM, Cristian Baboi <[EMAIL PROTECTED]> wrote:
>
> How about x below:
>
> let x=(1:x) in x ?
>
> Is x a single value in Haskell ?
>
> --
How about x below:
let x=(1:x) in x ?
Is x a single value in Haskell ?
--- Forwarded message ---
From: "Cristian Baboi" <[EMAIL PROTECTED]>
To: "Lennart Augustsson" <[EMAIL PROTECTED]>
Cc: "haskell-cafe@haskell.org"
Subject: Re: [Haskell-cafe] Wikipedia on first-class object
Date: Thu
On Thu, 27 Dec 2007 16:12:04 +0200, Bulat Ziganshin
<[EMAIL PROTECTED]> wrote:
Hello Cristian,
Thursday, December 27, 2007, 3:51:17 PM, you wrote:
Yes, but one can store the result of an operation to disk except in
the
particular case the result happen to be a function.
how can values
Hello Cristian,
Thursday, December 27, 2007, 3:51:17 PM, you wrote:
>>> Yes, but one can store the result of an operation to disk except in the
>>> particular case the result happen to be a function.
>> how can values of type T be saved to disk?
> I don't know.
> I'm a beginner in Haskell, and
On Thu, 27 Dec 2007 14:02:36 +0200, Lennart Augustsson
<[EMAIL PROTECTED]> wrote:
Comparing functions is certainly possible in Haskell, but there's no
standard function that does it.
If course, it might not terminate, but the same is true for many other
comparable objects in Haskell, e.g., inf
On Thu, 27 Dec 2007 14:37:51 +0200, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
I wrote:
Like any type, only certain operations make
sense on functions...
Yes, but one can store the result of an operation to disk except in
the
particular case the result happen to be a function.
No, you can
On Dec 26, 2007 10:28 PM, Steve Lihn <[EMAIL PROTECTED]> wrote:
> >arising from use of `/' at DSLTest.hs:11:14-28
>
> Thanks for the example. I am particularly amazed GHC is complaining at
> '/', not '+'. The type mismatch occurs (is reported) at much lower
> level. It would be nice if ther
On Thu, 27 Dec 2007 14:42:37 +0200, Bulat Ziganshin
<[EMAIL PROTECTED]> wrote:
Hello Cristian,
Thursday, December 27, 2007, 12:19:08 PM, you wrote:
Yes, but one can store the result of an operation to disk except in the
particular case the result happen to be a function.
how can values o
On Thu, 27 Dec 2007 14:37:51 +0200, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
I wrote:
Like any type, only certain operations make
sense on functions...
Yes, but one can store the result of an operation to disk except in
the
particular case the result happen to be a function.
No, you ca
Hello Cristian,
Thursday, December 27, 2007, 12:19:08 PM, you wrote:
> Yes, but one can store the result of an operation to disk except in the
> particular case the result happen to be a function.
how can values of type T be saved to disk?
--
Best regards,
Bulatma
Hello Yitzchak,
Thursday, December 27, 2007, 12:10:21 PM, you wrote:
>> http://en.wikipedia.org/wiki/First-class_object
>> I'll guess that 5,9,12 does not apply to Haskell functions.
you mean 5, 9-12?
> In particular,
> two functions are equal only if they produce
> the same value for every i
Cristian Baboi wrote:
> Ah! You must have been thinking that function in Haskell are members of
> DATA types.
> Or, to put it another way, Haskell make no distinction between data types
> and function types.
Yes.
I wrote:
Like any type, only certain operations make
sense on functions...
Thinking about files and types, I recalled that in Pascal files must have
types.
On Thu, 27 Dec 2007 12:40:22 +0200, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
I'm not sure that in Haskell one can say that storing a value of some
type
to disk is an operation defined on that type.
It is. Fo
"Neil Mitchell" <[EMAIL PROTECTED]> writes:
> I should have been more precise with my question. Given the code:
>
> fred = 2 + 2
>
> bob = fred + fred
>
> In a Haskell implementation fred would be evaluated once to 4, then
> used twice. The 2+2 would only happen once (ignore defaulting and
> overlo
Cristian Baboi wrote:
> I think I found the answer to why functions cannot be written to files.
> This is by design. Haskell must be free.
> Enabling writing functions to files, might make it ilegal in some
> countries. :-)
Ha, excellent!
I imagine that is what Haskell must have been
like before
On Thu, 27 Dec 2007 12:40:22 +0200, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
I wrote:
On the other hand, functions are members of types
that are just like any other Haskell type. They are
first-class in that sense.
Cristian Baboi wrote:
I guess that would apply to any typed language.
Perh
I wrote:
>> On the other hand, functions are members of types
>> that are just like any other Haskell type. They are
>> first-class in that sense.
Cristian Baboi wrote:
> I guess that would apply to any typed language.
Perhaps. But for many typed languages, it is not
practical to use. There may b
--- Forwarded message ---
From: "Cristian Baboi" <[EMAIL PROTECTED]>
To: "Yitzchak Gale" <[EMAIL PROTECTED]>
Cc:
Subject: Re: [Haskell-cafe] Wikipedia on first-class object
Date: Thu, 27 Dec 2007 12:21:44 +0200
I think I found the answer to why functions cannot be written to files.
Thi
On Thu, 27 Dec 2007 11:10:21 +0200, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
On the other hand, functions are members of types
that are just like any other Haskell type. They are
first-class in that sense.
I guess that would apply to any typed language.
Like any type, only certain operation
Cristian Baboi wrote:
> http://en.wikipedia.org/wiki/First-class_object
> I'll guess that 5,9,12 does not apply to Haskell functions.
I think there is a basic semantic difference between
what the author of that article meant by the word
"function" and what we mean by that word when
we are talkin
On 12/27/07, Cristian Baboi <[EMAIL PROTECTED]> wrote:
> http://en.wikipedia.org/wiki/First-class_object
>
> The term was coined by Christopher Strachey in the context of "functions
> as first-class citizens" in the mid-1960's.[1]
>
> Depending on the language, this can imply:
> 1. being express
71 matches
Mail list logo
