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. Allowin
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, E
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 ke
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.
>
> Has
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 incl
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 qu
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
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",
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 l
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
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 w
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.
On 2006-02-03, Ross Paterson <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 03, 2006 at 12:24:28PM +, Axel Simon wrote:
>> Yes, and I suppose not being opaque about a file name (i.e. FilePath =
>> [Word8]) is superior.
>
> Maybe. You might want [Word8] under Unix and [Word16] under Win32.
Right. I
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 pers
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 --
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 langu
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 cour
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 in
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 wi
On Fri, Feb 03, 2006 at 01:43:15PM -, Simon Marlow wrote:
> GHC treats the Unicode categories Sm, Sc, Sk and So as symbols, FWIW.
> These are the same characters for which Data.Char.isSymbol returns True.
cool. I will try to make jhc do the same thing.
> How do you implement the Data.Char pre
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 ar
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 specif
I'll second that.
I'll just throw in that not all pragmas ({-# ... #-}) are really
annotations, because they do not necessarily pertain to one particular
entity each. Some could be attached -- e.g. DEPRECATED, INLINE /
NOINLINE, SPECIALIZE. Others, however, couldn't -- say, rewrite rules
-- and
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 | @SuppressWarnings("unus
On Fri, Feb 03, 2006 at 12:24:28PM +, Axel Simon wrote:
> Yes, and I suppose not being opaque about a file name (i.e. FilePath =
> [Word8]) is superior.
Maybe. You might want [Word8] under Unix and [Word16] under Win32.
> So why is the whole Unicode proposal under "adopt: none"? Did nobody
>
On Fri, 2006-02-03 at 12:13 +, Ross Paterson wrote:
> On Fri, Feb 03, 2006 at 12:06:28PM +, Axel Simon wrote:
> > I think this is not yet discussed on the wiki:
> >
> > [FilePath as String or ADT]
>
> The issue (and the related one with program arguments and environment
> variables) is men
On Fri, Feb 03, 2006 at 12:06:28PM +, Axel Simon wrote:
> I think this is not yet discussed on the wiki:
>
> [FilePath as String or ADT]
The issue (and the related one with program arguments and environment
variables) is mentioned under CharAsUnicode.
_
I think this is not yet discussed on the wiki:
>From the recent post to the Haskell list:
Forwarded Message
From: Krasimir Angelov <[EMAIL PROTECTED]>
To: haskell
Subject: [Haskell] System.FilePath survey
[..]
* Will you be happy with a library that represents the file pat
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 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 ext
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
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 t
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 ha
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 introdu
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 unar
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
On Fri, Feb 03, 2006 at 10:20:01AM +0100, Tomasz Zielonka wrote:
> Even if concurrency is part of Haskell', it should still be clear
> that it doesn't affect the definition of non-concurrent Haskell' subset
> at all (is that true?). For example, all pure functions will be entirely
> thread-safe.
A
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 lan
Ian Lynagh wrote:
> Also, order is relevant in many situations with records, e.g.
>
> data Foo = Foo { x :: Char, y :: Bool }
>
> defines Foo :: Char -> Bool -> Foo as well as the corresponding pattern
> constructor
True. Of course the reason is, allowing both positional and named
notation
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 depend
| 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:
|
http://www.haskell.org//pipermail/
41 matches
Mail list logo
