On Thu, Dec 09, 2004 at 02:34:09AM +0100, Sebastian Sylvan wrote:
> Anyway, I'm currently working on an article for a Swedish print
> magazine on Haskell (similar to the one linked above, but less
> argumentative) that's due out at the end of January 2005. Hopefully
> that will contribute to spark
On Wed, 8 Dec 2004 19:27:56 +0100, Gour
<[EMAIL PROTECTED]> wrote:
> > Three of us also have a very rough start on a hands-on, practical
> > introduction to Haskell aimed at the experienced imperative programmer.
>
> This is *very* important - bringing new people from the imperative (I do not
> me
John Goerzen ([EMAIL PROTECTED]) wrote:
> I think the two main things to do that would be:
>
> 1. Write Haskell code that has a wide appeal (example: darcs)
Agree. One individual wrote an application of the (very) general interest
'educating' programmers about Haskell's adequacy as a general pr
mattr wrote:
Haskell is still a very dynamic language - there is still much room for
it to grow and improve. In that sense, it is still young.
Perl and Python and Ruby have hit middle age - no more growing, just
more bulk accumulating around the middle.
Or in Perl's case, a seriously ambitious
Haskell is still a very dynamic language - there is still much room for
it to grow and improve. In that sense, it is still young.
Perl and Python and Ruby have hit middle age - no more growing, just
more bulk accumulating around the middle.
Matt
On Wednesday, December 8, 2004, at 08:06 AM, Gou
Paul Hudak ([EMAIL PROTECTED]) wrote:
> Does Python not have warts? Or Pearl, or Java, or C#? I don't think
> that a few warts prevent a language from becoming a "success".
I agree.
> But you may be right that it is too late... Haskell is getting old!
> Sometimes I think that for a language
On 2004-12-06, Gour <[EMAIL PROTECTED]> wrote:
> However, these projects are mostly done by few individuals working hard and
> there is also "A Bus Hits Simon Peyton Jones" problem referred during the
> CUFP workshop.
>
> Any idea how to make a (more organize) community effort to bring Haskell ou
On 2004-12-07, Graham Klyne <[EMAIL PROTECTED]> wrote:
> I'd say that any attempt to proselytize Haskell (or any new technology)
> needs to start from a clear view of one kind of application that it is
> particularly good for. Then, focus on building a "bridgehead" for that
> narrow application
On Tue, 7 Dec 2004, Paul Hudak wrote:
> But you may be right that it is too late... Haskell is getting old!
> Sometimes I think that for a language to "succeed" it must do so in its
> infancy.
This is also my impression.
> Perhaps the thing to do is create a new language with a new name, but
On Tue, Dec 07, 2004 at 01:58:59PM -0500, Paul Hudak wrote:
> Aaron Denney wrote:
> >I'd rather it didn't until a few warts were fixed. OTOH, it may be too
> >late already, barring a Haskell 2.
>
> Does Python not have warts? Or Pearl, or Java, or C#? I don't think
> that a few warts prevent a
Aaron Denney wrote:
On 2004-12-06, Gour <[EMAIL PROTECTED]> wrote:
Any idea how to make a (more organize) community effort to bring Haskell out?
I'd rather it didn't until a few warts were fixed. OTOH, it may be too
late already, barring a Haskell 2.
Does Python not have warts? Or Pearl, or Java,
On 2004-12-06, Gour <[EMAIL PROTECTED]> wrote:
> Applications like darcs are very important enabling newcomers to see some
> concrete & succesful non-academia-open-source project.
>
> Besides that, seeing the progress of projects working on the binding for
> gui-libraries (wxhaskell & gtk2hs) are
John Goerzen wrote:
>On Tue, Dec 07, 2004 at 12:43:27PM +0100, Lennart Augustsson wrote:
>>Yay! :) Dynamically linked libraries are slower than statically linked
>>ones in just about every implementation I know of. I don't care.
>
>My understanding was that this was mostly limited to x86 platform
John Goerzen wrote:
On Tue, Dec 07, 2004 at 12:43:27PM +0100, Lennart Augustsson wrote:
slightly slower than statically linked ones), but you still have the
versioning issue.
Yay! :) Dynamically linked libraries are slower than statically linked
ones in just about every implementation I know of.
On Tue, Dec 07, 2004 at 12:43:27PM +0100, Lennart Augustsson wrote:
> >slightly slower than statically linked ones), but you still have the
> >versioning issue.
> Yay! :) Dynamically linked libraries are slower than statically linked
> ones in just about every implementation I know of. I don't ca
Simon Marlow wrote:
Dynamic linking is (almost) a separate issue. GHC 6.4 will have some
support for dynamic linking in the native code generator thanks to
Wolfgang Thaller, but it needs someone to push it the final mile on
x86/Linux and Windows. Dynamically linked libraries will work (albeit
sli
On 06 December 2004 14:39, John Goerzen wrote:
> On 2004-12-06, Keith Wansbrough <[EMAIL PROTECTED]> wrote:
>> The static vs dynamic linking question has been discussed many times.
>> The summary is: GHC is a highly-optimising compiler, and the binary
>> interface _necessarily_ changes with every
On 06 December 2004 21:54, Sven Panne wrote:
> And just a remark: We don't need a new technique for a "no inline
> barrier": Just compile the library optimized and use a facade which
> re-exports your public API compiled without optimizations.
That probably won't work. GHC goes to the .hi file f
On 6 Dec 2004, at 21:56, Sven Panne wrote:
Jules Bean wrote:
I don't think it does, actually. You can imagine a compiler which has
access to not *only* the .so files, but also the haskell source.
Therefore it can still unroll (from the source), but it can choose to
link to an exported symbol if
Jules Bean wrote:
I don't think it does, actually. You can imagine a compiler which has
access to not *only* the .so files, but also the haskell source.
Therefore it can still unroll (from the source), but it can choose to
link to an exported symbol if unrolling isn't worth it.
But that's not dy
Robert Dockins wrote:
[...] In particular, if we
could segment closely related code with many interdependencies into
discrete units with well defined external interfaces (sound like
packages to anyone else?), then my intuition tells me that the cost of
setting up an inlining barrier should be f
Henning Thielemann wrote:
On Mon, 6 Dec 2004, Robert Dockins wrote:
The problem, of course, is that Haskell likes to tightly bind with the
libraries it uses (inlineing across modules and other optimizations).
So imaging if the "package" unit was a barrier to those kinds of
optimizations. Then
Philippa Cowderoy wrote:
On Mon, 6 Dec 2004, Jules Bean wrote:
[...] If that is the case, then it already is 'smart linking' and I stand
corrected. Unless the granularity of the .o files is too large, of
course...
It is - you get one .o per module.
That's not true with -split-objs, e.g. the base pa
Philippa Cowderoy <[EMAIL PROTECTED]> writes:
> The strip utility helps somewhat
You're right, of course. My executable (incidentally on Sparc) seems
to have an overhead of approximately one megabyte when just
considering the text segment (that is, subtracting the text sizes of
my own .o files).
On 6 Dec 2004, at 21:16, Henning Thielemann wrote:
On Mon, 6 Dec 2004, Robert Dockins wrote:
The problem, of course, is that Haskell likes to tightly bind with the
libraries it uses (inlineing across modules and other optimizations).
So imaging if the "package" unit was a barrier to those kinds of
On Mon, 6 Dec 2004, Robert Dockins wrote:
> The problem, of course, is that Haskell likes to tightly bind with the
> libraries it uses (inlineing across modules and other optimizations).
> So imaging if the "package" unit was a barrier to those kinds of
> optimizations. Then, no knowledge of
Philippa Cowderoy wrote:
>The strip utility helps somewhat, I just dropped a wxHaskell app from a 10
>meg .exe to about 3.6 megs under windows.
You can also compress the stripped executable with UPX. GHC-generated
executables seem to compress very well (about 4:1 in my experience), and
even a ver
On Mon, 6 Dec 2004, Jules Bean wrote:
>
> On 6 Dec 2004, at 18:48, John Goerzen wrote:
>
> > Presently, ghc will only link in a .o component of a .a file if symbols
> > from that .o file are actually used in the final executable. This is
> > the motiviation for the split-objs feature; to reduce t
On 6 Dec 2004, at 18:48, John Goerzen wrote:
Presently, ghc will only link in a .o component of a .a file if symbols
from that .o file are actually used in the final executable. This is
the motiviation for the split-objs feature; to reduce the size of
executables that use quite large .o files.
In
On 2004-12-06, Robert Dockins <[EMAIL PROTECTED]> wrote:
>
>> On 6 Dec 2004, at 17:29, John Goerzen wrote:
>>
>> This is presumably just because we don't have 'smart' linking, so the
>> whole library is bundled in. I imagine in principle smart linking would
>> be possible...
>
> Indeed, and it w
On Mon, 6 Dec 2004, Robert Dockins wrote:
>
> > On 6 Dec 2004, at 17:29, John Goerzen wrote:
> >
> >>
> >> That is an excellent point. Who would use an ls or cp that requires
> >> 10MB of RAM, especially on embedded devices?
> >>
> >
> > This is presumably just because we don't have 'smart' linki
On 6 Dec 2004, at 17:29, John Goerzen wrote:
That is an excellent point. Who would use an ls or cp that requires
10MB of RAM, especially on embedded devices?
This is presumably just because we don't have 'smart' linking, so the
whole library is bundled in. I imagine in principle smart linking wo
On 6 Dec 2004, at 17:29, John Goerzen wrote:
That is an excellent point. Who would use an ls or cp that requires
10MB of RAM, especially on embedded devices?
This is presumably just because we don't have 'smart' linking, so the
whole library is bundled in. I imagine in principle smart linking wou
Ketil Malde wrote:
John Goerzen <[EMAIL PROTECTED]> writes:
sensibly share libraries between apps. Anyway, disc is cheap.
Memory not so much, though. One advantage of having something in .so
form is that every instance of every application that uses it shares the
same in-memory image of the cod
On 2004-12-06, Robert Dockins <[EMAIL PROTECTED]> wrote:
>>
>> [1] On my Linux system, the overhead seems to be less than 2
>> Mbyte. 5 Mb is the figure used by the OP.
One other problem with that is that 5MB is a LOT on a device such as my
Zaurus. I have an OCaml development environment on this
Ketil Malde wrote:
John Goerzen <[EMAIL PROTECTED]> writes:
sensibly share libraries between apps. Anyway, disc is cheap.
Memory not so much, though. One advantage of having something in .so
form is that every instance of every application that uses it shares the
same in-memory image of the co
John Goerzen <[EMAIL PROTECTED]> writes:
>> sensibly share libraries between apps. Anyway, disc is cheap.
> Memory not so much, though. One advantage of having something in .so
> form is that every instance of every application that uses it shares the
> same in-memory image of the code.
Well,
John Goerzen <[EMAIL PROTECTED]> wrote:
> On 2004-12-06, Keith Wansbrough <[EMAIL PROTECTED]> wrote:
> > The static vs dynamic linking question has been discussed many times.
> > The summary is: GHC is a highly-optimising compiler, and the binary
> > interface _necessarily_ changes with every minor
On 2004-12-06, Keith Wansbrough <[EMAIL PROTECTED]> wrote:
> The static vs dynamic linking question has been discussed many times.
> The summary is: GHC is a highly-optimising compiler, and the binary
> interface _necessarily_ changes with every minor revision (even
> patchlevel revision) of the co
Simon Peyton-Jones wrote:
| I also have a very small start on a "haskell for hackers" ("hackers"
in
| the non-evil sense) sort of document. One this doesn't ignore I/O as
| "hard" or "unimportant". I/O in Haskell doesn't suck. It's just that
a
| lot of people in the community don't have it as a
| I also have a very small start on a "haskell for hackers" ("hackers"
in
| the non-evil sense) sort of document. One this doesn't ignore I/O as
| "hard" or "unimportant". I/O in Haskell doesn't suck. It's just that
a
| lot of people in the community don't have it as a high priority, I
| think.
On Wednesday 01 December 2004 21:18, John Goerzen wrote:
> I also have a very small start on a "haskell for hackers" ("hackers" in
> the non-evil sense) sort of document. One this doesn't ignore I/O as
> "hard" or "unimportant". I/O in Haskell doesn't suck.
I come from a similar area (large cont
On 2004-11-30, GoldPython <[EMAIL PROTECTED]> wrote:
> Has anyone tried presenting the language to the average rank and file
> programming community? If so, was it successful? If not, is there
> interest in doing so?
I am very interested in doing that.
I'm a relatively recent Haskeller. I come
43 matches
Mail list logo
