Re: [Haskell] GHC Core & backend

[Donald Bruce Stewart]

afie:
> Hello all,
> 
> Is anybody using GHC's backend as a backend for their own compiler?

I know of one project at least, in development and undocumented, that
uses GHC's backend. However, it doesn't use the Core interface. Rather,
it uses an interface Mark Wotton and I wrote to the Stix layer of the
native code generator. This is around 3 abstraction layers further down
the compiler.

> In the paper "An external representation for the GHC Core Language" the
> introduction states that "there are many (undocumented) idiosyncracies in
> the way GHC produces Core from source Haskell". And that "it will be hard to
> produced Core that can be integrated with GHC-produced core, and we don't
> aim to support this". Has this changed since the time of writing this paper?

I'm pretty sure this hasn't changed. It is hard but not impossible. Lots
of magic though.

> It would be cool if, let's say, Helium (http://www.cs.uu.nl/helium) could
> use all of GHC's libraries...

-- Don
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Making a spreadsheet with Haskell

[Bjorn Lisper]

> Hi, I would like to know how can I make a spreadsheet using Haskell
> (something like Excel, a very-reduced version, of course) 
> Do I need any kind of special library? How can I make the interface so the
> user can introduce data, select data and so on?
 
> Thanks for your help.
> Miren Cob Isasi de Vírgala

We did something called "Haxcel". It is a spreadsheet-like interface to
Haskell, thus making it possible to use Haskell as a formula language. The
interface itself is implemented in Java.

See http://www.mrtc.mdh.se/projects/getProject.php3?id=0041.

Björn Lisper
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Website redesign

[John Peterson]

So there it was - another email message complaining about something on
haskell.org.  "Your site is so `last century'".  So I, as usual, said
"If you want it fixed, do it yourself".

And thus the new look on haskell.org.

Thanks much to Jon Lingard for giving us a facelift.  The new look
(same old content) is very professional.

 John


 
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] GHC 64bit?

[Simon Marlow]

 
> Dell's poweredge server with the max 12gb RAM costs $15k.
> Moore's law says that
> 1. you only need an extra bit/year.
> 2. processing that extra bit will cost 50% less next year
> 
> Though perhaps processing time is not linear with
> the number of bits for historical/architectural
> reasons?
> 
> I presume that, if we are conservative in the
> number of bits we use then we don't run into the
> ptr driven storage problem that Axel described.
> 
> In particular, if we need only 2 or 4 times as
> much memory, we should only grow pointers by 1 or
> 2 bits...rather than growing immediately all the
> way to 64...
> 
> Perhaps there could be a command line option to
> specify desired ptr size.  I assume it is
> impossible to adjust pointer size dynamically at
> runtime depending on memory consumption (I
> assume you would do it at garbage collection time
> if it were possible).

Using pointers of a size other than the machine's native word size
should be possible.  We experimented recently with adding tag bits to
pointers, and in the process discovered all the places where you would
need to convert between "abstract" pointers and real pointers, which are
the same places you would need to modify if you were to use some kind of
compressed representation for pointers.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] GHC 64bit?

[S. Alexander Jacobson]

Dell's poweredge server with the max 12gb RAM costs $15k.
Moore's law says that
1. you only need an extra bit/year.
2. processing that extra bit will cost 50% less next year

Though perhaps processing time is not linear with
the number of bits for historical/architectural
reasons?

I presume that, if we are conservative in the
number of bits we use then we don't run into the
ptr driven storage problem that Axel described.

In particular, if we need only 2 or 4 times as
much memory, we should only grow pointers by 1 or
2 bits...rather than growing immediately all the
way to 64...

Perhaps there could be a command line option to
specify desired ptr size.  I assume it is
impossible to adjust pointer size dynamically at
runtime depending on memory consumption (I
assume you would do it at garbage collection time
if it were possible).

-Alex-

_
S. Alexander Jacobson  mailto:[EMAIL PROTECTED]
tel:917-770-6565   http://alexjacobson.com





On Fri, 13 Feb 2004, Simon Marlow wrote:

>
> > alex:
> > > Is there a maximum memory GHC can use/reach?
> > > Specifically, can GHC address more than 4gb of
> > > memory?
> >
> > SimonM may want to comment, but at the moment I think GHC is
> > limited to
> > 4G, but only due to lack of 64bit machines/demand on the developers.
> >
> > If you look in ghc/rts/MBlock.h you'll see some references to this.
> >
> > I *think* it would be easy to overcome this limit.
> >
> > (this should really be on glasgow-haskell-users)
>
> In principle, there's no problem.  In practice, GHC's storage manager
> needs a (fast) function of type
>
>Ptr a -> Bool
>
> to indicate whether a particular address is part of the dynamic heap or
> not.  This is currently implemented as a bytemap, which is 4k long on a
> 32-bit machine.  To cover the whole of a 64-bit address space, this
> method isn't practical.  Nevertheless, we can extend the bytemap to
> cover a lot more real memory, as long as we have a way to map from
> virtual memory addresses to elements of the bytemap - this is the tricky
> bit.  So far we haven't tackled this problem in a general way.
>
> Cheers,
>   Simon
>

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] 3d or Nd geometry library?

[Abraham Egnor]

I was somewhat surprised to see that there's only one geometry library on
the haskell libraries page, and further dismayed to find that it for the
most part only does 2d.  It seems like haskell should be a natural fit for
higher-order geometric libraries - has anyone heard of such?

Abe

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] non-ASCII characters in Haddock documentation

[Wolfgang Jeltsch]

Am Freitag, 13. Februar 2004 01:23 schrieben Sie:
> wolfgang:
> > Hello,
> >
> > how do I insert non-ASCII and maybe even non-Latin-1 characters in
> > Haddock documentation?
> >
> > Wolfgang
>
> Looks like it might be difficult. The haddock lexer src has:
>
> $alphanum = [A-Za-z0-9]
>
> So, non-ascii might not be lexed.

Hello,

I meant non-ASCII characters in source code comments like this:
{-|
The execution time of this function is /n³/.
-}
Currently, Haddock seems to copy the bytes making up the non-ASCII character 
verbatim to the HTML file.  But since the HTML file doesn't contain a 
character set specification, it is illformed and it depends on the browser 
how this situation is handled.

> -- Don

Wolfgang

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Ann: Halipeto 1.1 (web page templates)

[andrew cooke]

Malcolm W - thanks for your comments.  I did reply (nothing important),
but your university has my address blacklisted (dynamic ip).  Sorry for
the on-list noise.  Andrew

andrew cooke said:
[...]
> Halipeto generates web pages from templates (much like JSP, Zope TAL etc).
>  It's written in Haskell (with a ghc extension) and is available from
> http://www.acooke.org/jara/halipeto
[...]

-- 
personal web site: http://www.acooke.org/andrew
personal mail list: http://www.acooke.org/andrew/compute.html
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] GHC 64bit?

[Simon Marlow]

 
> alex:
> > Is there a maximum memory GHC can use/reach?
> > Specifically, can GHC address more than 4gb of
> > memory?
> 
> SimonM may want to comment, but at the moment I think GHC is 
> limited to
> 4G, but only due to lack of 64bit machines/demand on the developers.
> 
> If you look in ghc/rts/MBlock.h you'll see some references to this.
> 
> I *think* it would be easy to overcome this limit.
> 
> (this should really be on glasgow-haskell-users)

In principle, there's no problem.  In practice, GHC's storage manager
needs a (fast) function of type

   Ptr a -> Bool

to indicate whether a particular address is part of the dynamic heap or
not.  This is currently implemented as a bytemap, which is 4k long on a
32-bit machine.  To cover the whole of a 64-bit address space, this
method isn't practical.  Nevertheless, we can extend the bytemap to
cover a lot more real memory, as long as we have a way to map from
virtual memory addresses to elements of the bytemap - this is the tricky
bit.  So far we haven't tackled this problem in a general way.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Ann: Halipeto 1.1 (web page templates)

[andrew cooke]

Hi,

Halipeto generates web pages from templates (much like JSP, Zope TAL etc).
 It's written in Haskell (with a ghc extension) and is available from
http://www.acooke.org/jara/halipeto

An example site generated using Halipeto, containing some Pancito images,
is at http://www.acooke.org/pancito - the code for that site is included
in the Halipeto download as an example.

Some details:

- The design makes it easy to call Haskell functions from the XHTML
template files.

- Only static pages are generated.  There is no integration with a web
server (maybe someone would like to do this? ;o)

- XML code is from HaXml (thanks very much!).

- Currently a simple text (file/directory) database is used, but care has
been taken (the IO monad is threaded through the code) to allow
intergration of an SQL backend.

Cheers,
Andrew

-- 
personal web site: http://www.acooke.org/andrew
personal mail list: http://www.acooke.org/andrew/compute.html
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] GHC Core & backend

[Arjan van IJzendoorn]

Hello all,

Is anybody using GHC's backend as a backend for their own compiler?

In the paper "An external representation for the GHC Core Language" the
introduction states that "there are many (undocumented) idiosyncracies in
the way GHC produces Core from source Haskell". And that "it will be hard to
produced Core that can be integrated with GHC-produced core, and we don't
aim to support this". Has this changed since the time of writing this paper?

It would be cool if, let's say, Helium (http://www.cs.uu.nl/helium) could
use all of GHC's libraries...

Regards, Arjan van IJzendoorn

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Call for Workshop Proposal:GPCE'04 -- Generative ProgrammingandComponent Engineering

[Simon Marlow]

[ posted on behalf of Benaissa, Zino <[EMAIL PROTECTED]> ]

  CALL FOR WORKSHOP PROPOSALS 




-


  Third International Conference on 


   Generative Programming and Component Engineering (GPCE'04) 


 Vancouver, October 24-28, 2004 
 co-located with
 OOPSLA 2004 and
 ISMM 2004 


   
http://gpce04.gpce.org 


-

Important Dates

Submission date: March 19, 2004 




Overview Important Dates


GPCE workshops provide intensive collaborative environments where
generative and component technologists meet to surface, discuss, and
solve challenging problems facing the field. 


Workshops occur on the day before the conference. To ensure a
sufficiently small group for effective interaction, workshop organizers
manage attendance based on an objective criterion, typically, a short
position paper submitted by potential attendees. Other criteria are
permitted as long as they are clearly specified in the workshop's call
for participation. 


We encourage proposals for innovative, well-focused workshops on a broad
spectrum of component engineering and generative programming topics. All
topics related to generative programming and component engineering are
potential candidates for workshops. Workshops typically fall into the
following categories: 



*   A workshop may address a specific sub-area of generative and
component technology in depth. 

*   A workshop may cover areas that cross the borders of several sub
areas. Workshops that cross the borders of the formal and the applied
areas is one example. 

*   A workshop may focus on the applications and deployment of
generative and/or component technology in areas such as
telecommunications, mobile computing or real-time systems. Workshops
reporting on industrial experiences are particularly welcome. 

Workshop topics are by no means limited to the types mentioned above.
However, in each case, the proposed area is supposed to have enough
impetus to yield new results that can be considered important and worth
more detailed investigation. 




What should a proposal look like? 


Workshop proposals should be sent in ASCII or PDF format to the workshop
chair, and they should consist of four pages/parts: 



1.  Cover Page 


*   Name of the proposed workshop. 

*   Names and addresses of the organizers. 

*   Intended number of participants. 

*   Requested Audio/Video equipment. 

2.  Abstract 


*   Why it is relevant to GPCE and a short overview of the rationale
for the workshop and the major topics. In particular, statements about
the review process and ways to ensure creativity during the workshop
would be appreciated. 

*   The abstract should preferably not exceed 200 words. 

3.  Call for Participation 


*   A preliminary version of the Call for Participation that the
organizers must prepare if the workshop is accepted. 

*   Should provide a brief overview of the proposed workshop
including a description of the goals of the workshops and the work
practices. 

*   May repeat some of the statements made on the abstract page, but
should be targeted specifically to potential workshop participants. 

4.  Organizers 


*   Short biography of each organizer. 

*   References to similar workshops organized at previous
conferences, including the number of participants. 

*   If a workshop is accepted, the organizers will be requested to
prepare a WWW page that will contain the latest information about the
workshop. The web pages of each workshop will be linked to the GPCE
workshop web site. 

*   Each workshop must have at least two organizers, preferably from
different organizations. Preference will be shown to workshops that have
more organizers. Workshop organizers and participants have to register
for the conference. 



Recommendations 



*   Workshop organizers should in particular take care to foster the
creative potential that is tentatively present in a workshop. 

*   Remember that a workshop is NOT a conference! 

*   The success of a workshop depends greatly on the results
generated on-site. 

*   A number of interrelated issues should be taken into account in
order to provide a good framework for such on-site creativity. 


*   Time allocation 


*   During the workshop, enough time should be reserved for
collaborative work. 

*   Such creative sessions should have a precise topic and objective
and their results should be written down so that they can be reported
later. Reasonable expectations 

*   One should not count on peop

Re: [Haskell] GHC 64bit?

[Ben Rudiak-Gould]

On 13 Feb 2004, Ketil Malde wrote:

> Axel Simon <[EMAIL PROTECTED]> writes:
> 
> > I wonder if such an effort is worthwhile. If all pointers are suddenly
> > twice the size then the footprint of a program roughly doubles. 
> > [...]
> > It would be interesting if Haskell programs could run in the lower 4 GB 
> > while running in 64 bit mode. Then you could have large data structures 
> > (or memory mapped files) in C land.
> 
> That's an interesting possibility -- at least part of my program is a
> large UArray of Word8, which could probably be FFI'ed relatively
> easily. 

... but which doesn't need to be, because UArrays of Word8 will not grow
in size, no matter how large the pointers. :-)

Seriously, this seems like a good approach to supporting 64 bits cheaply:
put everything in the lower 4GB except for arrays. (They'd have an
indirection box with a 64-bit pointer in the lower 4GB.) Does anyone need
more than 4GB of non-array data?

> Hmm..how about 32 bit pointers, but with 8 byte boundary alignment?
> This should give an effective pointer size of 35 bits, adressing
> up to 32Gb.

This is also a good idea.

-- Ben

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] GHC 64bit?

[Ketil Malde]

Axel Simon <[EMAIL PROTECTED]> writes:

>> There is an IA64 port somewhere, and I suspect other 64-bit
>> architectures as well.  Presumably they support >4Gb?

> I wonder if such an effort is worthwhile. If all pointers are suddenly
> twice the size then the footprint of a program roughly doubles.

Hmm..how about 32 bit pointers, but with 8 byte boundary alignment?
This should give an effective pointer size of 35 bits, adressing
up to 32Gb. 

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] GHC 64bit?

[Ketil Malde]

Axel Simon <[EMAIL PROTECTED]> writes:

>> There is an IA64 port somewhere, and I suspect other 64-bit
>> architectures as well.  Presumably they support >4Gb?

> I wonder if such an effort is worthwhile. If all pointers are suddenly
> twice the size then the footprint of a program roughly doubles. 

Unless you do additional tricks.  Since we're still some way from 2^64
memory, perhaps part of the pointers could contain data (tags, say) as
well?  This means more than a straightforward port, though, and I've
no idea how feasible it would be to implement.

> Hence to run a program that that needs more than 4GB of RAM on a 32
> bit architecture you would need more than 8GB of RAM on a 64 bit
> machine (and e.g. Apples G5 machines only support 8GB of on-board
> memory).

Well - so be it.  There are 64bit machines out there that supports
more than 8Gb. It'll be expensive, but at least possible.

> It would be interesting if Haskell programs could run in the lower 4 GB 
> while running in 64 bit mode. Then you could have large data structures 
> (or memory mapped files) in C land.

That's an interesting possibility -- at least part of my program is a
large UArray of Word8, which could probably be FFI'ed relatively
easily. 

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] GHC 64bit?

[Axel Simon]

On Fri, Feb 13, 2004 at 10:20:43AM +0100, Ketil Malde wrote:
> [EMAIL PROTECTED] (Donald Bruce Stewart) writes:
> 
> > SimonM may want to comment, but at the moment I think GHC is limited to
> > 4G, but only due to lack of 64bit machines/demand on the developers.
> 
> There is an IA64 port somewhere, and I suspect other 64-bit
> architectures as well.  Presumably they support >4Gb?

I wonder if such an effort is worthwhile. If all pointers are suddenly
twice the size then the footprint of a program roughly doubles. Hence to
run a program that that needs more than 4GB of RAM on a 32 bit
architecture you would need more than 8GB of RAM on a 64 bit machine (and
e.g. Apples G5 machines only support 8GB of on-board memory).

It would be interesting if Haskell programs could run in the lower 4 GB 
while running in 64 bit mode. Then you could have large data structures 
(or memory mapped files) in C land.

Axel.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] GHC 64bit?

[Ketil Malde]

[EMAIL PROTECTED] (Donald Bruce Stewart) writes:

> SimonM may want to comment, but at the moment I think GHC is limited to
> 4G, but only due to lack of 64bit machines/demand on the developers.

There is an IA64 port somewhere, and I suspect other 64-bit
architectures as well.  Presumably they support >4Gb?

(I am possibly "lack of demand"; my application could really use lots
of memory, and I had access to an SGI Altix. Never got around to trying
to port GHC, and when somebody else had done it, I no longer had
access to the machine.  Oh well.) 

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell