#704: change array interface to accomodate resizable arrays
---+
Reporter: simonmar|Owner:
Type: task| Status: new
Priority: normal
#637: Ctrl-Break handler doesn't work in forked threads in -threaded RTS
+---
Reporter: [EMAIL PROTECTED] | Owner: simonmar
Type: bug| Status: new
Priority: normal
#474: Debug.Trace.trace should work on Show
--+-
Reporter: jch | Owner: nobody
Type: feature request | Status: reopened
Priority: lowest | Milestone: 6.6
#402: internal error: startTask: Can't create new task
--+-
Reporter: nobody | Owner: simonmar
Type: bug | Status: closed
Priority: normal | Milestone: 6.4.2
The following link gives reasons for not generating via C
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
Naturally a number of these are common lisp specific, however I think that
Haskell and GCC are quite semantically different, so using GCC might
Hello Rene,
Thursday, February 23, 2006, 4:19:15 PM, you wrote:
RdV The following link gives reasons for not generating via C
RdV
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i read it now
RdV Naturally a number of these are common lisp specific,
seems that you don;t understand the situation. ghc compiles Haskell to
language called core, do almost all optimizations at level of this
language, then translates final result to the STG language from that
the C-- code is generated. changing the translation of STG can't
prevent ANY ghc
Bulat Ziganshin wrote:
i think that ocaml can't generate code better than gcc and especially
icc (intel C/C++ compiler), but may be i'm wrong? ;)
didn't try factorial, but exponential fib in ocaml is *FASTER* than both
gcc and intel c/c++ with highest optimization levels
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code usually written by the C programmers. but
code generated by ghc has
Hello kyra,
Thursday, February 23, 2006, 5:38:54 PM, you wrote:
k Bulat Ziganshin wrote:
i think that ocaml can't generate code better than gcc and especially
icc (intel C/C++ compiler), but may be i'm wrong? ;)
k didn't try factorial, but exponential fib in ocaml is *FASTER* than both
k
Hello Rene,
Thursday, February 23, 2006, 5:32:21 PM, you wrote:
seems that you don;t understand the situation. ghc compiles Haskell to
language called core, do almost all optimizations at level of this
language, then translates final result to the STG language from that
the C-- code is
Hello Rene,
Thursday, February 23, 2006, 4:19:15 PM, you wrote:
RdV The following link gives reasons for not generating via C
RdV
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i done reading. my question - is YOU read this? the lisp problems have
Claus Reinke writes:
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code usually written by the C programmers. but
Hello Claus,
Thursday, February 23, 2006, 8:56:57 PM, you wrote:
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code
Hello Kevin,
Thursday, February 23, 2006, 9:06:25 PM, you wrote:
KG On a related point, Mercury has two C backends a low level one at the
KG level of GHC's and a high level one. Bulat might want to read this for
KG a description of the high level C implementation:
KG
KG
Bulat Ziganshin writes:
Hello Kevin,
KG Also, ghc used to be faster than gcc for a naive, recursive factorial
KG function (once the cpr analysis and optimisation was added). From
KG what Bulat wrote it seems that gcc got better ...
i don't say that we must compile recursive
From: Bulat Ziganshin [EMAIL PROTECTED]
Hello Rene,
i done reading. my question - is YOU read this? the lisp problems have
almost
nothing in common with haskell
It is a long time since i read this, but some things come to mind. Listed
below.
Maybe GHC should generate better C. I am
Hello Rene,
Thursday, February 23, 2006, 10:17:40 PM, you wrote:
RdV Maybe GHC should generate better C. I am just not sure whether this will
RdV bring the best global (as opposed to micro-optimizations) performance.
i answered in the original letter (search for Cray :)
RdV Generating better C
From: Bulat Ziganshin [EMAIL PROTECTED]
i answered in the original letter (search for Cray :)
Re-reading this, I see that you have a well defined goals that cover most of
my points.
seems that you don't seen the attached files. tail calls are optimized
in gcc
No I don't see any
Bulat Ziganshin wrote:
i prefer to see the asm code. this may be because of better high-level
optimization strategies (reusing fib values). the scheme about i say
will combine advantages of both worlds
no strategies, plain exponential algorithm,
ocaml:
excerpt
_camlFibo__fib_57:
sub
[EMAIL PROTECTED] wrote:
* multiple results can be returned via C++ paira,b template, if this is
efficiently implemented in gcc
There's a -freg-struct-return option in 2.x, 3.x and 4.x. I think it's off
by default on many architectures.
* recursive definitions translated into the for/while
Hello Bulat,
From my (limited) knowledge of GHC backend, the difficult part of your
plan is that STG is not suited to compilation to native C at all. You
might need to do quite advanced translation from STG to another
intemediate language, (as GRIN for example), and then some more
advanced
Chris Kuklewicz:
Stefan Karrmann wrote:
Dear all,
can ghc compile huge tables into efficient code if they are constant at
compile time?
Two examples may clearify the question:
big1 :: UArray Int Char
big1 = array (0,1000) $! map (\i - (i,toEnum i)) [0..1000]
big2 = sum
Stefan Karrmann [EMAIL PROTECTED] wrote:
can ghc compile huge tables into efficient code if they are constant
at compile time?
I have a related but different question. If I have large, statically
defined tables of data e.g.
table = listArray (0,max) [ [1,2,3,4]
http://haskell.org/haskellwiki/GHC:FAQ
(search for cse)
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bjorn Lisper
| Sent: 23 February 2006 10:28
| To: [EMAIL PROTECTED]
| Cc: Haskell@haskell.org
| Subject: Re: [Haskell] Compilation of big, computed
Bjorn Lisper wrote:
Chris Kuklewicz:
Stefan Karrmann wrote:
Dear all,
can ghc compile huge tables into efficient code if they are constant at
compile time?
Two examples may clearify the question:
big1 :: UArray Int Char
big1 = array (0,1000) $! map (\i - (i,toEnum i)) [0..1000]
big2 =
Malcolm Wallace wrote:
Stefan Karrmann [EMAIL PROTECTED] wrote:
can ghc compile huge tables into efficient code if they are constant
at compile time?
I have a related but different question. If I have large, statically
defined tables of data e.g.
table = listArray (0,max) [ [1,2,3,4]
Hello Simon,
Thursday, February 23, 2006, 3:35:51 PM, you wrote:
What I would really like is a syntax to statically construct an array,
without having to compute it from a list. I'm not sure that even
Template Haskell can help here, since there is no normal form for it to
translate to.
SM
What I would really like is a syntax to statically construct an
array, without having to compute it from a list. I'm not sure that
even Template Haskell can help here, since there is no normal form
for it to translate to.
SM Happy Alex use the hack of encoding static arrays as strings
Malcolm Wallace wrote:
Hmm, that only works if the data being stored in the table is of regular
size? I need variable-length values. Using a two- or three-level
encoding into strings would start to get /really/ unpleasant.
And this is pretty ghc-specific stuff.
Perhaps I should propose a new
CALL FOR PAPERS
Workshop on
Mathematically Structured Functional Programming
MSFP 2006
Kuressaare, Estonia, 2 July 2006
http://cs.ioc.ee/mpc-amast06/msfp/
On Thu, Feb 23, 2006 at 10:40:31AM +, Malcolm Wallace wrote:
What I would really like is a syntax to statically construct an array,
without having to compute it from a list. I'm not sure that even
Template Haskell can help here, since there is no normal form for it to
translate to.
This
On 23 February 2006 01:48, John Meacham wrote:
On Wed, Feb 22, 2006 at 05:11:26PM -, Simon Marlow wrote:
Indeed, the distinction between data newtype should be a completely
private property, so we certainly shouldn't distinguish those in
exports/imports. It's less clear to me whether
On 22 February 2006 17:27, Malcolm Wallace wrote:
However, I would be
equally happy to combine type/newtype/data into a single keyword for
exports.
for the record, I am in favour of tagging export specifiers with 'class'
or 'type' (using 'type' for all type constructors, in light of yours and
Ketil Malde [EMAIL PROTECTED] wrote:
I would solve this problem by reducing the Prelude to just a core.
List function could go, for example, (mostly) into Data.List.
If this means that you must import Data.List almost everywhere, this
won't change anything - only add yet another import
On 23 February 2006 10:28, Jean-Philippe Bernardy wrote:
I lost track of what is the issue being tackled here. What's broken
with the current way of specifying exported entities? Imho it's the
best system that I've seen (across all languages I know).
A lot of language chose to separate
Simon Marlow [EMAIL PROTECTED] wrote:
However, I would be
equally happy to combine type/newtype/data into a single keyword for
exports.
for the record, I am in favour of tagging export specifiers with
'class' or 'type' (using 'type' for all type constructors, in light of
yours and
On 22 February 2006 13:09, David Roundy wrote:
On Tue, Feb 21, 2006 at 03:50:29PM +, Henrik Nilsson wrote:
I'm already somewhat unhappy about the way most present Haskell
tools map module names to path names (I'd generally prefer to have
the possibility to flatten my file hierarchies by,
On 23 February 2006 11:14, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
However, I would be
equally happy to combine type/newtype/data into a single keyword for
exports.
for the record, I am in favour of tagging export specifiers with
'class' or 'type' (using 'type' for
Malcolm Wallace [EMAIL PROTECTED] writes:
you would simply replace the implicit import Prelude with
an explicit import Prelude.Standard (or use a build flag like
-fimplicit-prelude, or +98).
Why not keep it implicit? If you want the alternative behavior, you
know where to get it (import
Hello Simon,
Thursday, February 23, 2006, 2:21:22 PM, you wrote:
SMghc --make My.Dotted.Module.hs Main.hs
SM works fine. Similarly with GHCi.
i don't known that. we should add this to faq
SM It's only when GHC has to actually *find* a source file for a module
SM that the hierarchical
On Wed, Feb 22, 2006 at 05:12:47PM +, Malcolm Wallace wrote:
Everything else that is currently in the Haskell'98 Prelude is
re-distributed across a variety of small modules. Where a syntactic
desugaring rule currently uses an entity from the Prelude, the new
interpretation is that it uses
Bulat Ziganshin [EMAIL PROTECTED] wrote:
MW With my proposal, you would simply replace the
MW implicit import Prelude with an explicit import
MW Prelude.Standard
import Prelude ($)
can't solve this problem?
One of the problems with the current mechanism for overriding Prelude
definitions,
modules M exports
class Eq a where
(==) :: a - a - Bool
data T :: * - *
f :: T - Int
mkT :: Int - T
where -- implementation below here
--
SM The main difference is that I'm doing away with parentheses, commas, and
SM export specifiers, and using layout
Simon Marlow [EMAIL PROTECTED] writes:
The main difference is that I'm doing away with parentheses, commas, and
export specifiers, and using layout and full declaration syntax instead.
(I don't really want to discuss this very rough idea any more though,
it's just a distraction, and I'm not
Malcolm Wallace wrote:
An explicit interface would be useful for many purposes besides
machine-checked documentation. For instance, it could be used to
eliminate the hs-boot or hi-boot files used by some compilers when
dealing with recursive modules.
Why *does* ghc require hs-boot files? What
I wrote:
What I don't like is that given a signature like
x :: a - a
there's no way to tell, looking at it in isolation, whether a is free or
bound in the type. [...]
Here's a completely different idea for solving this. It occurs to me that
there isn't all that much difference between
On 2/23/06, Ben Rudiak-Gould [EMAIL PROTECTED] wrote:
In fact, this suggests a compromise: how about implicitly importing the
Prelude only if the module header is omitted? That way there'll be no impact
on short (single-module) programs.
+1
--
Taral [EMAIL PROTECTED]
Computer science is no
let's go through 5.2 Export Lists to see what would be missing
if we tried to replace the export list with a separation of a module
into a public (exported) and a private (local) part:
---
module M
exports
body
where
body
--
1. value, field
On Thu, 2006-02-23 at 21:04 +0100, Marcin 'Qrczak' Kowalczyk wrote:
Simon Marlow [EMAIL PROTECTED] writes:
The main difference is that I'm doing away with parentheses, commas, and
export specifiers, and using layout and full declaration syntax instead.
(I don't really want to discuss this
On 2006-02-21, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Am Dienstag, 21. Februar 2006 04:41 schrieb John Meacham:
on this note, I thought it would be nice to do a 'mostly unqualified'
import.
import Foo qualified(foo,bar)
which will have the effect of
import Foo hiding(foo,bar)
import
[EMAIL PROTECTED] wrote:
Compare this notation:
f . g . h $ x
with the one you suggested:
f $ g $ h $ x
I suggested:
f . g $ h x
or
f $ g $ h x
Christian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
John Meacham wrote:
Identity y = Map.lookup x theMap
These are potential runtime errors, that may be not so obvious to see in
the source (ie. for user defined types) and even the compiler (ghc) does
not emit a warning.
Indeed, that is the entire point of the construct. ghc definitly
[EMAIL PROTECTED] wrote:
Hello Graham,
Wednesday, February 22, 2006, 12:57:39 PM, you wrote:
GK How to do this in a wiki, I'm not sure, though I don't take that to mean
we
GK shouldn't try. I think the mediawiki mechanism you mention is reasonable
if not
GK ideal, though this would
Simon Marlow [EMAIL PROTECTED] writes:
I think the reason we set O_NONBLOCK is so that we don't have to test
with select() before reading, we can just call read(). If you don't
use O_NONBLOCK, you need two system calls to read/write instead of
one. This probably isn't a big deal, given that
Simon Marlow [EMAIL PROTECTED] writes:
I agree that a generic select/poll interface would be nice.
We must be aware that epoll (and I think kqueue too) registers event
sources in advance, separately from waiting, which is its primary
advantage over poll.
The interface should use this model
On Thu, Feb 23, 2006 at 11:16:11AM +0100, Christian Maeder wrote:
John Meacham wrote:
Identity y = Map.lookup x theMap
These are potential runtime errors, that may be not so obvious to see in
the source (ie. for user defined types) and even the compiler (ghc) does
not emit a warning.
On Fri, 24 Feb 2006, Marcin 'Qrczak' Kowalczyk wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I think the reason we set O_NONBLOCK is so that we don't have to test
with select() before reading, we can just call read(). If you don't
use O_NONBLOCK, you need two system calls to read/write
Hello,
I am running ghc 6.4.1 on mac os X (10.4.5). Can anyone give me some
pointers for getting graphics functionality?
I have tried wxhaskell, but it gives me the error
HelloWorld.hs:4:0:
Failed to load interface for `Graphics.UI.WX':
Bad interface file:
Hi
I've been having a look at zippers over homogenous tree data types, and was
wondering how best to represent a heterogeneous graph for manipulation with a
zipper.
The main example of zippers I've been looking at is
http://okmij.org/ftp/Computation/Continuations.html#zipper-fs
and
60 matches
Mail list logo
