Josef Svenningsson writes:
> On Dec 28, 2007 11:40 PM, Mitar <[EMAIL PROTECTED]> wrote:
> > Would not it be interesting and useful (but not really efficient) to
> > have patterns something like:
> >
> > foo :: Eq a => a -> ...
> > foo (_{4}'b') = ...
> >
> > which would match a list with fo
On Jan 1, 2008 3:43 PM, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
> The classical definition of "general recursive function"
> refers to functions in Integer -> Integer to begin
> with, so there can only be countably many values by
> construction.
Except that there are uncountably many (2^Aleph_0)
On Dec 28, 2007 11:40 PM, Mitar <[EMAIL PROTECTED]> wrote:
> Would not it be interesting and useful (but not really efficient) to
> have patterns something like:
>
> foo :: Eq a => a -> ...
> foo (_{4}'b') = ...
>
> which would match a list with four elements ending with an element 'b'. Or:
>
> foo
Peter Verswyvelen wrote:
> Well, I don't know about the licensing, but according to
> http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Front_ends, a new
> cleaner intermediate language was created in 2005 for GCC, which might be
> more "general"?
It's still very difficult to work with GCC fro
Neil Mitchell wrote:
> GCC is optimised for dealing with code that comes from C, and the back
> end language is much like C. GCC is also not really set up to be used
> by bolting different front ends on to different back ends - part of
> this is a license issue - if the front and back ends were wel
Peter Verswyvelen wrote:
...
I was wondering, why doesn't GHC use the GCC (or any other standard
compiler) backend intermediate code? The backend of GCC generates highly
optimized code no? Or is the intermediate code format of GCC (or other
compilers) not suitable for Haskell?
...
My guess is
Peter Verswyvelen <[EMAIL PROTECTED]> wrote:
> Another question regarding the backend: a cool feature of the
> Microsoft Visual C++ (MVC) compiler is its ability to perform "LTCG"
> (link-time-code-generation), performing whole program optimization.
> It something like this possible with Haskell
Andrew Bromage wrote:
>> [*] Theoretical nit: It's not technically a "set".
>>
>> Consider the data type:
>>
>> data Foo = Foo (Foo -> Bool)
>>
>> This declaration states that there's a bijection between the elements of
>> Foo and the elements of 2^Foo, which by Cantor's diagonal theorem canno
Andrew Bromage wrote:
> [*] Theoretical nit: It's not technically a "set".
>
> Consider the data type:
>
> data Foo = Foo (Foo -> Bool)
>
> This declaration states that there's a bijection between the elements of
> Foo and the elements of 2^Foo, which by Cantor's diagonal theorem cannot
> be t
On Dec 31, 2007 7:17 AM, <[EMAIL PROTECTED]> wrote:
> This declaration states that there's a bijection between the elements of
> Foo and the elements of 2^Foo, which by Cantor's diagonal theorem cannot
> be true for any set. That's because we only allow computable functions,
Nit the nit: Or (mor
Hi
> If I understand it correctly, the GHC compiler either directly generates
> machinecode, or it uses C as an intermediate language.
>
> I also read somewhere that C is not the most efficient intermediate
> representation for functional languages, and that one gets better
> performance when ge
If I understand it correctly, the GHC compiler either directly generates
machinecode, or it uses C as an intermediate language.
I also read somewhere that C is not the most efficient intermediate
representation for functional languages, and that one gets better
performance when generating nati
12 matches
Mail list logo