Tue, 16 May 2000 02:03:53 +0200, Sven Panne [EMAIL PROTECTED]
pisze:
Well, "time" is a builtin in bash and {,t}csh, but not in {,z,k}sh.
time is a builtin in {z,k}sh.
OK, I am installing /usr/bin/time now. I thought time is always
a builtin and "time true | sleep 3" should always report 3.
Marcin 'Qrczak' Kowalczyk wrote:
As for the language standard: I hope that Char will be allowed or
required to have =30 bits instead of current 16; but never more than
Int, to be able to use ord and chr safely.
Er does it have to? The Java Virtual Machine implements Unicode with
16 bits.
OTOH, it wouldn't be hard to change GHC's Char datatype to be a
full 32-bit integral data type.
Could we do it please?
It will not break anything if done slowly. I imagine that
{read,write}CharOffAddr and _ccall_ will still use only 8 bits of
Char. But after Char is wide, libraries
George Russell writes:
Marcin 'Qrczak' Kowalczyk wrote:
As for the language standard: I hope that Char will be allowed or
required to have =30 bits instead of current 16; but never more than
Int, to be able to use ord and chr safely.
Er does it have to? The Java Virtual Machine
Tue, 16 May 2000 10:44:28 +0200, George Russell [EMAIL PROTECTED] pisze:
As for the language standard: I hope that Char will be allowed or
required to have =30 bits instead of current 16; but never more than
Int, to be able to use ord and chr safely.
Er does it have to? The Java
Tue, 16 May 2000 12:26:12 +0200 (MET DST), Frank Atanassow [EMAIL PROTECTED] pisze:
Of course, you can always come up with specialized schemes involving stateful
encodings and/or "block-swapping" (using the Unicode private-use areas, for
example), but then, that subverts the purpose of
Frank Atanassow [EMAIL PROTECTED] wrote,
George Russell writes:
Marcin 'Qrczak' Kowalczyk wrote:
As for the language standard: I hope that Char will be allowed or
required to have =30 bits instead of current 16; but never more than
Int, to be able to use ord and chr safely.
Er
Tue, 16 May 2000 09:28:15 +0400 (MSD), S.D.Mechveliani [EMAIL PROTECTED] pisze:
(+) = Prelude.Num.(+) reports wrong syntax.
(+) = Prelude.+
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++
Mon, 15 May 2000 17:23:29 -0700, Sigbjorn Finne [EMAIL PROTECTED] pisze:
Really, it terminates? My copy (ghc-4.05) blows the stack, which is
sort of what I'd expect here ( Eq.(==) is defined in terms of Eq.(/=),
and vice versa,
Ah, I see: in ghc-4.07 the default implementation of (==) always
ghc-4.06:
T.hs:10: parse error on input `Prelude.+'
On Tue, 16 May 2000, S.D.Mechveliani wrote:
ghc-4.06:
T.hs:10: parse error on input `Prelude.+'
However strange it might look, qualified operators still obey the same
rules as unqualified operators: "Prelude.+" is an infix operator and must
be surrounded by parenthesis to make it a function.
Tue, 16 May 2000 11:14:50 +0400 (MSD), S.D.Mechveliani [EMAIL PROTECTED] pisze:
(+) = Prelude.+
ghc-4.06:
T.hs:10: parse error on input `Prelude.+'
Sorry, (+) = (Prelude.+)
And also: `Prelude.elem`, not Prelude.`elem`.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED]
Ok I understand this isomorphism better. However this remark seems to be of
no value to functional programmers.
Why trying to mix terms( otr types) with relations ?
Anyway, in intuitionistic logic it is natural indentify proofs and
programs and proposition and types. Maybe best
I reply , but I like to make some comments before:
As readers would have noticed from the former email my answers are put here
in a different context.
This might give the reader the false impression that I made some serious
mistakes in the formal
email.
Fri, 12 May 2000 00:42:52 +0200, Jan
Tue, 16 May 2000 10:54:59 +0200, Jan Brosius [EMAIL PROTECTED] pisze:
newSTRef v has type ST s (STRef s (STRef s a))
(THIS is of the form ST s (STRef s T(s))
No. It has the type
ST s1 (STRef s1 (STRef s a))
That is indeed what I said in my former email where I stated that
On Tue, 16 May 2000, Jan Brosius wrote:
Ok I understand this isomorphism better. However this remark seems to be of
no value to functional programmers.
Why trying to mix terms( otr types) with relations ?
What is a 'type' in your oppinion?
Isn't a type a statement about pre- and
From: Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 16, 2000 11:42 AM
Subject: Re: more detailed explanation about forall in Haskell
Tue, 16 May 2000 10:54:59 +0200, Jan Brosius [EMAIL PROTECTED]
pisze:
newSTRef v has type ST s (STRef s (STRef s
- Original Message -
From: Lars Lundgren [EMAIL PROTECTED]
Sent: Tuesday, May 16, 2000 1:54 PM
Subject: Re: more detailed explanation about forall in Haskell
On Tue, 16 May 2000, Jan Brosius wrote:
Ok I understand this isomorphism better. However this remark seems to be
of
no
although this argument originated from a discussion of rank-2
polymorphism in Haskell's type system, the part I am replying to
addresses only first-order predicate logic (also called "predicate
calculus").
Jan Brosius asserts
Now forall s1. ( ST s1 T(s)) IMPLIES forall s . ( ST s T(s) )
Tue, 16 May 2000 22:37:45 +0200, Jan Brosius [EMAIL PROTECTED] pisze:
newSTRef applied to some value can have a type ST s (STRef s T(s)),
That is strange , can you give a little example?
I've given it four mail pairs ago, but here it is again:
refRef :: ST s Int
refRef = do
- Original Message -
From: Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED]
Sent: Tuesday, May 16, 2000 11:40 PM
Subject: Re: more detailed explanation about forall in Haskell
Tue, 16 May 2000 22:37:45 +0200, Jan Brosius [EMAIL PROTECTED]
pisze:
newSTRef applied to some value can have
- Original Message -
From: Jan Brosius [EMAIL PROTECTED]
To: Richard Uhtenwoldt [EMAIL PROTECTED]
Sent: Wednesday, May 17, 2000 1:23 AM
Subject: Re: more detailed explanation about forall in Haskell
- Original Message -
From: Richard Uhtenwoldt [EMAIL PROTECTED]
To: Jan
"Jan Brosius" [EMAIL PROTECTED] writes:
SORRY, this is quite TRUE , in fact [forall x. alpha(x)] = alpha(x)
the above true equivalence seems to be easily considered as wrong . Why?
Because alpha(x) is TRUE can be read as alpha(x) is TRUE for ANY x.
(Is there something wrong with
23 matches
Mail list logo
