#681: non-terminating instances involving FDs
-+--
Reporter: ross |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler
On 03 February 2006 08:34, Bulat Ziganshin wrote:
moreover - we can implement locking as special converter type,
that can be applied to any mutable object - stream, collection,
counter. that allows to simplify implementations and add locking
only to those Streams where we really need it. like
Simon Marlow wrote:
-- | Takes an output stream and an input stream, and pipes all the
-- data from the former into the latter.
streamConnect :: (OutputStream o, InputStream i) = o - i - IO ()
That's the wrong way around, of course :-) It pipes everything from the
input stream to the output
Cyril Schmidt wrote:
I added this to the FAQ list; please feel free to elaborate and correct.
Linking to Visual Studio-generated code would be much easier if GHC were
able
to use Visual C++ as backend, instead of gcc (even Visual Haskell at the
moment
relies on gcc for C compilation).
I
I think that the C backend is heavily dependent on various GCC pragmas
but it should be relatively easy to do assembly backend that produces
MASM code.
Cheers,
Krasimir
2006/2/3, Geoffrey Alan Washburn [EMAIL PROTECTED]:
Cyril Schmidt wrote:
I added this to the FAQ list; please feel free
Simon Marlow wrote:
So - do you need Latin-1, or could you use UTF-8?
I'm not amused to change the encoding of many haskell source files
(particular of those that are not mine).
These files can then no longer be compiled by earlier ghcs (though I
don't understand, how ghc-6.4.1 recognises
Krasimir Angelov wrote:
I think that the C backend is heavily dependent on various GCC pragmas
but it should be relatively easy to do assembly backend that produces
MASM code.
That's something I'd like to do (or see somebody else do), if only to
make debugging Haskell DLLs a bit easier;
Hello Mads,
Thursday, February 02, 2006, 11:48:27 PM, you wrote:
ML instance (Foo LongAndUgleName) = class something ...
ML Here again LongAndUglyName cannot be replaced by ShortAndTellingName.
ML This can be annoying if you have a lot of these instance declarations.
are you enabled
Hello Haskellers,
There was a long discussion in October 2004, about the a FilePath
module which is currently used in Cabal. There was an idea to move it
to the standard libraries but since there were a lot of objections it
was removed.
= Original Message From Krasimir Angelov [EMAIL PROTECTED] =
Hello Haskellers,
There was a long discussion in October 2004, about the a FilePath
module which is currently used in Cabal. There was an idea to move it
to the standard libraries but since there were a lot of objections it
was
Hi,
* Have you used the existing FilePath module and what do you think
about it?
Do you found it useful? Have you made any significant bugfixes or
extensions to it?
I wrote a separate FilePath module for Yhc, which is available at:
On Fri, Feb 03, 2006 at 11:29:34AM +, Neil Mitchell wrote:
I wrote a separate FilePath module for Yhc, which is available at:
http://www.cs.york.ac.uk/fp/darcs/yhc-devel/src/compiler98/Util/FilePath.hs
The advantage of this one is that it doesn't use any #ifdef's, so is
entirely portable
[move to [EMAIL PROTECTED]
Yes. I agree here. There should be two modules say:
System.FilePath.Posix System.FilePath.Windows. There should be a
third module System.FilePath that have to use the native path. It
should switch between the Posix and Windows implementations either at
runtime (Hugs,
Am Freitag, 3. Februar 2006 12:03 schrieb Krasimir Angelov:
[...]
* Will you be happy with a library that represents the file path
as String? The opposite is to use ADT for it. The disadvantage is that
with the current IO library we should convert from ADT to String and
back again each
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
Am Freitag, 3. Februar 2006 12:03 schrieb Krasimir Angelov:
[...]
* Will you be happy with a library that represents the file path
as String? The opposite is to use ADT for it. The disadvantage is that
with the current IO library we should
Hi all,
I'm doing my undergraduate thesis on monads, comonads, and arrows and
their applications. I've been focusing part of my research on the Yale
Haskell group's work on Functional reactive programming, and specifically
on their move from a monadic to an arrow-based implemenation (as in
| Some experts (like Hans Boehm) argue, that concurrency can't be added
to
| the language as a library.
| http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
|
| This is true for many imperative programming languages. Haskell seems
| to be an exception:
|
On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
The interface can be a library, but (a) what libraries are available is
part of the language definition and (b) it's hard to build a good
implementation without runtime support. And the nature of the runtime
support depends
On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
| Some experts (like Hans Boehm) argue, that concurrency can't be added
to
| the language as a library.
| http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
|
| This is true for many imperative programming
Hello Wolfgang,
Friday, February 03, 2006, 2:22:17 AM, you wrote:
1) significantly simplifies declarations using typeclasses. i
was seriously bitten by those huge declarations, and think that
simplification in this area will lead to much wider use of type
classes by the ordibary users (like
Hello Benjamin,
Friday, February 03, 2006, 2:29:47 AM, you wrote:
(+ x) --- (? + x)
i like this idea! but i tink that it's too late for such incompatible change :(
really, unary operators can be added to language without any troubles.
we need only to prohibit using of the same symbol for unary
Hello Tomasz,
Friday, February 03, 2006, 10:52:22 AM, you wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural
numbers and parallel list comprehensions.
TZ The design of Haskell was so great, that we could add concurrency as
TZ a library without introducing
Hello John,
Friday, February 03, 2006, 3:39:38 AM, you wrote:
Got a unicode-compliant compiler?
JM sure do :)
JM but it currently doesn't recognize any unicode characters as possible
JM operators.
are you read this? :)
Log:
Add support for UTF-8 source files
GHC finally has
Hello Wolfgang,
Friday, February 03, 2006, 1:46:56 AM, you wrote:
i had one idea, what is somewhat corresponding to this discussion:
make a strict Haskell dialect. implement it by translating all
expressions of form f x into f $! x and then going to the standard
(lazy) haskell translator.
On Fri, 3 Feb 2006, Ross Paterson wrote:
As another example, Ben Rudiak-Gould recently pointed out that the
inclusion of stToIO breaks threaded state reasoning for ST, e.g.
readSTRef won't necessarily get what your last writeSTRef wrote (because
the region might be RealWorld, with other threads
We must find *something* to throw away though! :-)
Simon
Indeed. One of the things I had been hoping for in Haskell'
was the removal of the many conservative restrictions put
into earlier definitions: they complicate the language definition,
restrict expressiveness, and have prompted various
On Fri, Feb 03, 2006 at 12:43:24PM +0300, Bulat Ziganshin wrote:
Friday, February 03, 2006, 10:52:22 AM, you wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural
numbers and parallel list comprehensions.
TZ The design of Haskell was so great, that we could
http://hackage.haskell.org/trac/haskell-prime/wiki/Underscore
I think it is basically the wrong idea to encode (type and) usage
information in the name of an identifier. One should use the type system
for that, or, failing that, annotations. Something like
data Foo = Foo |
On 03 February 2006 00:40, John Meacham wrote:
On Thu, Feb 02, 2006 at 06:19:43PM -0600, Taral wrote:
Got a unicode-compliant compiler?
sure do :)
but it currently doesn't recognize any unicode characters as possible
operators. which it should, but I am just not sure how to specify that
On 03 February 2006 04:07, Taral wrote:
On 2/2/06, John Meacham [EMAIL PROTECTED] wrote:
but it currently doesn't recognize any unicode characters as possible
operators. which it should, but I am just not sure how to specify
that yet until some sort of standard develops. Once there are more
On Fri, Feb 03, 2006 at 01:00:32AM -0800, John Meacham wrote:
On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
The interface can be a library, but (a) what libraries are available is
part of the language definition and (b) it's hard to build a good
implementation without
On Fri, Feb 03, 2006 at 12:00:23PM +0100, Tomasz Zielonka wrote:
TZ The design of Haskell was so great, that we could add concurrency as
TZ a library without introducing any problems... but we have
TZ concurrency in the standard anyway...
concurrency should go into the
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
Maybe this is just me being dense, but how is poll or select
concurrency? There is no multiprocessing involved; it is simply a more
efficient way to find which file descriptors are ready for some I/O
action.
I know, of course,
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
On Fri, Feb 03, 2006 at 01:00:32AM -0800, John Meacham wrote:
On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
The interface can be a library, but (a) what libraries are available is
part of the language
On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
I know, of course, that Java green threads and Haskell forkIO threads
are called threads, but I personally believe its misleading to call it
concurrency -- they're
On 2006-02-03, John Goerzen [EMAIL PROTECTED] wrote:
On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
I know, of course, that Java green threads and Haskell forkIO threads
are called threads, but I personally
On Feb 3, 2006, at 9:34 AM, Bulat Ziganshin wrote:
Hello Benjamin,
Friday, February 03, 2006, 2:29:47 AM, you wrote:
(+ x) --- (? + x)
i like this idea! but i tink that it's too late for such
incompatible change :(
really, unary operators can be added to language without any troubles.
Hello Tomasz,
Friday, February 03, 2006, 2:00:23 PM, you wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural
numbers and parallel list comprehensions.
TZ The design of Haskell was so great, that we could add concurrency as
TZ a library without
Henrik Nilsson [EMAIL PROTECTED] writes:
Dear all,
John Mecham wrote:
Yeah, I have been coming to the same conclusion myself. it pains me a
lot. (monad transformers! I need thee!) but its not like fundeps will
go away, they will just still be experimental so it isn't the end of
the world.
Somewhat apropos. The following recent post on LtU links to some
slides by Tim Sweeney (Epic Games) wherein he discusses things he
does and doesn't like about Haskell.
Notable points:
== Positive on ST (implies need for rank 2 types)
== Positive on Concurrency and STM
== Positive on
On Fri, Feb 03, 2006 at 11:18:58AM -0600, John Goerzen wrote:
On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
I know, of course, that Java green threads and Haskell forkIO threads
are called threads, but I
I just added a ticket requesting that some definitions be added to the
wiki (so that other pages and tickets can link to them, helping to
demystify jargon for those who don't specialise in specific fields). I've
also included quick definitions for predicative and impredicative in
the ticket,
I would like to strive to find objective data on the use of
extensions. I started a table here which summarizes how popular
extensions are in real-life code. We need more data points, though.
http://hackage.haskell.org/trac/haskell-prime/wiki/ExtensionsExperiment
I have a short program which
On Fri, Feb 03, 2006 at 07:09:40PM +, Philippa Cowderoy wrote:
I just added a ticket requesting that some definitions be added to the
wiki (so that other pages and tickets can link to them, helping to
demystify jargon for those who don't specialise in specific fields). I've
also
Following the helpful call to attend to priorities, I reluctantly return to
the M-R discussion. I believe a point has been missed that should be a part
of this thread.
On 2006 January 30, Josef Svenningsson wrote:
But the most important argument against M-R hasn't been put forward yet.
On Fri, Feb 03, 2006 at 07:33:12PM -, Brian Hulley wrote:
One question is how to get some kind of do notation that would work well
in a strict setting.
The existing do notation makes use of lazyness in so far as the second
arg of is only evaluated when needed. Perhaps a new keyword
Bulat Ziganshin [EMAIL PROTECTED] writes:
if my idea was incorporated in Haskell, this change don't require
even changing signatures of most functions working with arrays -
just Array type become Array interface, what a much difference?
What would 'Eq - Eq - Ord - Bool' mean?
'(Eq a, Eq b,
Bulat Ziganshin writes:
Now i'm trying to generalize my functions parameters/results to type
classes instead of single types. for example, getFileSize function can
return any numeric value, be it Integer, Word or Int64. This,
naturally, results in those long and awkward signatures. Allowing
Hello Wolfgang,
Friday, February 03, 2006, 1:46:56 AM, you wrote:
i had one idea, what is somewhat corresponding to this discussion:
make a strict Haskell dialect. implement it by translating all
expressions of form f x into f $! x and then going to the standard
(lazy) haskell translator.
Matt Roberts [EMAIL PROTECTED] writes:
I am in love with HUnit and QuickCheck. However, I am missing one
important functionality
I'm rather fond of them also.
Check my prototype of test-driven-development for QuickCheck:
http://www.scannedinavian.com/~shae/qc-tdd.tgz
I want to call a
Kurt Hutchinson wrote:
On 2/2/06, Maurício [EMAIL PROTECTED] wrote:
I understand those examples, but I really would like to know how to
do that with monads. I would like to ask the same question, but now with
this code:
double a = 1000;
double b = 0;
while (a != b) {
a /= 2;
cout
On Feb 3, 2006, at 11:28 AM, Maurício wrote:
Kurt Hutchinson wrote:
On 2/2/06, Maurício [EMAIL PROTECTED] wrote:
I understand those examples, but I really would like to know
how to
do that with monads. I would like to ask the same question, but
now with
this code:
double a = 1000;
Constructing some code today in Python, using some functional-style coding
idioms, I found myself wondering if there would be any real benefit to using a
monad-based implementation (i.e. other than to demonstrate that it can be done).
The application that sparked this line of thought was a simple
Bulat Ziganshin wrote:
Hello Wolfgang,
Friday, February 03, 2006, 1:46:56 AM, you wrote:
i had one idea, what is somewhat corresponding to this discussion:
make a strict Haskell dialect. implement it by translating all
expressions of form f x into f $! x and then going to the
standard (lazy)
On Feb 3, 2006, at 2:33 PM, Brian Hulley wrote:
Bulat Ziganshin wrote:
Hello Wolfgang,
Friday, February 03, 2006, 1:46:56 AM, you wrote:
i had one idea, what is somewhat corresponding to this discussion:
make a strict Haskell dialect. implement it by translating all
expressions of form f x
On 2/3/06, Graham Klyne [EMAIL PROTECTED] wrote:
I have noticed that, while I like to use functional idioms in some of my
Python
code, and the Python language is easily able to support these (even some lazy
evaluation, courtesy of generators), that the code doesn't always look as
clean
as
Brian Hulley wrote:
...
[Apologies for replying to a reply of a reply but I don't seem to have
received the original post]
I've been thinking along these lines too, because it has always seemed
to me that laziness is just a real nuisance because it hides a lot of
inefficiency under the
Brian Hulley wrote:
Bulat Ziganshin wrote:
[Apologies for replying to a reply of a reply but I don't seem to have
received the original post]
I've been thinking along these lines too, because it has always seemed
to me that laziness is just a real nuisance because it hides a lot of
On Fri, 3 Feb 2006 19:33:12 -
Brian Hulley [EMAIL PROTECTED] wrote:
I've been thinking along these lines too, because it has always
seemed to me that laziness is just a real nuisance because it hides a
lot of inefficiency under the carpet as well as making the time/space
behaviour of
On Fri, Feb 03, 2006 at 07:33:12PM -, Brian Hulley wrote:
One question is how to get some kind of do notation that would work well
in a strict setting.
The existing do notation makes use of lazyness in so far as the second
arg of is only evaluated when needed. Perhaps a new keyword
Jan-Willem Maessen wrote:
I pointed out some problems with strict Haskell in a recent talk, but
I think it'd be worth underscoring them here in this forum.
Is the text of this talk or points raised in it available online anywhere?
snip There is one very difficult piece of syntax in a strict
Robin Green wrote:
On Fri, 3 Feb 2006 19:33:12 -
Brian Hulley [EMAIL PROTECTED] wrote:
I've been thinking along these lines too, because it has always
seemed to me that laziness is just a real nuisance because it hides a
lot of inefficiency under the carpet as well as making the time/space
John Meacham wrote:
On Fri, Feb 03, 2006 at 07:33:12PM -, Brian Hulley wrote:
One question is how to get some kind of do notation that would
work well in a strict setting.
The existing do notation makes use of lazyness in so far as the
second arg of is only evaluated when needed. Perhaps
Brian Hulley wrote:
if' :: ~a - ~b - Bool
Oooops :-)
if' :: Bool - ~a - ~a - a
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Brian Hulley wrote:
Robin Green wrote:
snip
So simply make strictness the default and have laziness annotations
(for arguments), instead of making laziness the default and having
strictness annotations.
Where would you put these laziness annotations?
If you put them in the function
65 matches
Mail list logo
