At 09:46 -0700 1999/07/20, Carl R. Witty wrote:
>For these new lists to be computationally useful, you need new
>operations (more than the "check for empty list", "take the head", and
>"take the tail" provided by Haskell). What new operations would you
>suggest providing? How would they be imple
Manuel Chakravarty and Olaf Chitil debate the fixity of ($):
> > I think the idea behind $ is exactly the change of
> > associativity.
>
> Hmm, I thought, the idea behind it is a change of precedence...
>
> > I use $ a lot to save a lot of brackets. I very much prefer
> >
> > f $ g $ h $ i $
Keith Wansbrough wrote
>
> You want TclHaskell, available at
>
> http://www.dcs.gla.ac.uk/~nww/TkHaskell/TkHaskell.html
>
> (sic)
>
There's no sic about it -- TkHaskell and TclHaskell are two (related
but) different libraries. :) . I'd recommend TclHaskell as the more
versatile of the two.
Consider the following arithmetic expressions:
3 + -4
3 * -4
Both expressions should be syntactically wrong due to the
syntax described in the Haskell98 report (which is reasonable).
What surprises me is the fact that both expressions are
accepted by ghc and hugs (even in the Haskell98 mode
Hi Olaf,
Olaf Chitil <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
> >
> > Is there any good reason for the standard prelude defining
> >
> > infixr 0 $, $!, `seq`
> >
> > ie, making $ and $! right associative?
> ...
> > I'd rather prefer
> >
> > f $ x $ y = (f $ x) $
Here's yet another version:
> (//) :: [a] -> [b] -> [(a,b)]
> xs//ys = concat ([zip xs (reverse ys') | ys' <- inits ys] ++
> [zip xs' (reverse ys) | xs' <- tails (tail xs)])
(It only tries to reverse ys if the first comprehension comes to the end
of ys.)
This has reasonable beh
Hi all,
since I have gotten into the habit to relate proposed diagonalisation
function, I will not resist this time, either ;-)
Koen Claessen <[EMAIL PROTECTED]> writes:
>
> as // bs = diag [] [ [ (a,b) | a <- as] | b <- bs ]
>
> diag current [] = diag [] current
> di
On 19-Jul-1999, Jan Brosius <[EMAIL PROTECTED]> wrote:
> will Haskell compiled programs be faster by using more strictness
> annotations;
Strictness annotations on functions don't help much, since the compilers
generally do a fine job of inferring strictness of functions.
But the current crop of
Jan Brosius <[EMAIL PROTECTED]> wrote
> compared with Ocaml and SML , Haskell is a more sophisticated and more
> elegant language. Does anybody know how efficient the Haskell compiler is
> with regards to impure functional languages.
> will Haskell compiled programs be faster by using more str
At 20:16 -0700 1999/07/19, Carl R. Witty wrote:
>> However, using the definition using ordinals above, we can define l as
>>the map
>>a + b w |-> (a, b)
>> which is clearly well defined...
>Well, the problem is not just printing it out, but doing anything with
>the list. In your example
>
> A TkHaskell would be useful to me. I found the references leading to Chris
> Dornan's web page, but the preliminary version is no longer available
> there. Is it still possible to get TkHaskell?
You want TclHaskell, available at
http://www.dcs.gla.ac.uk/~nww/TkHaskell/TkHaskell.html
(sic)
Hi,
I am indeed working on an improved version of TclHaskell.
I'll be providing an initial release within a few weeks.
(Hopefully by the end of this month.)
It uses the event and behavior of Fran to allow a more
structured and declarative approach to composing GUIs.
I've also got a modified an
Hans Aberg <[EMAIL PROTECTED]> writes:
> This is in fact one of the more easy questions: One defines a list l on a
> set A to be a map l: [0, x) -> A on a semi-open interval [0, x), where x is
> an ordinal, and 0 is the first (smallest) ordinal. Then the set of all
> lists have type list ([A] in
>You want TclHaskell, available at
>
> http://www.dcs.gla.ac.uk/~nww/TkHaskell/TkHaskell.html
>but I believe Meurig Sage is working on a much improved version as we
>speak.
Unfortunately, the links from that web page to the distribution/release are
dead.
--
Scott Turner
[EMAIL PROTECTED]
14 matches
Mail list logo
