Hugs on the orbit

[Jan Skibinski]

Here is "How to convert Hugs into an Orbit server and supply it
with a GUI client"
www.numeric-quest.com/haskell/morehugs/index.html

Jan

Re: why software needs an explicit license

[Julian Assange]

George Russell <[EMAIL PROTECTED]> writes:

> I have no problem with software having an explicit license, I just don't see
> that it normally needs to be quoted at the top of EVERY module.   (There
> are probably exceptional jurisdictions where it does, but not many.)
> The GHC method, where the license file is in the distribution and easy
> to find if you want it, seems fair enough to me.

I take a compromise position and simply write (c) Copyright . See
"LICENSING" file for details.

-- 
Stefan Kahrs in [Kah96] discusses the
   notion of completeness--programs which never go wrong can be
   type-checked--which complements Milner's notion of
   soundness--type-checked programs never go wrong [Mil78].

Re: ghc-4.06-1.src.rpm (was: ghc to be dropped from potato (debian)

[Ganesh Sittampalam]

On Wed, 15 Mar 2000 10:27:56 + (GMT), you uttered:

>>> It would be great if at least one haskell system could get into the
>>> standard linux distributions.  ...
>
>> Sure - any idea how to get Red Hat to include the stuff?
>
>I've asked a (busy) friend who works for redhat.  I'll pass on any
>info if/when he replies.  I think ghc would probably be a "contrib"
>package.  For redhat, "We do not guarentee that they will work, fix
>anything etc. They are just a public service that we lend to users (ie
>a central repository)."

Just upload .src.rpm and binary rpms to ftp://incoming.redhat.com/ and
they'll make their way to contrib. I don't think it'd ever make it into the
distribution proper or powertools, as redhat themselves have to maintain
everything in that.

>Finally, in case I am giving the wrong impression, thanks _very_ much
>for taking the trouble to make a src.rpm.  

Seconded.

RE: Haskell 98: partition; and take,drop,splitAt

[Brian Boutel]

> 3.  Manuel points out
>
> I must say that I'm strongly tempted to disallow empty qualifiers
> and make n>=1.  I'm not sure how this change crept in in the first
> place.  Does anyone care?  Urgle.

The report is in a bit of a mess here.
The top of section 3 (the summary of exp syntax) also has n>=1. App B4 has
n>=0.
The translation box in 3.11 clearly defines [e | ] as e, but does not define
[e | ,Q] (which should presumably be [e|Q]), or  [e|q] where q is a single
qualifier.

This originates with H98. H1.4 (which was actually defining monad
comprehensions) had n>=1 and no empty qualifiers, as did earlier versions. I
would be happy to revert.

--brian

Re: STGHugs page

[Andy Gill]

"S.D.Mechveliani" wrote:
> 
> Mabye, STGHugs www page contains a bug?
> For I had the same problem as  Ronald J. Legere
> when tried to find and download STGHugs starting from
> http://haskell.org
> 
> > 15 Mar 2000
> > From: "Ronald J. Legere" <[EMAIL PROTECTED]>
> 
> > Actually I wanted to try STG hugs on my win 98 machine (I know thats
> > not supported, but I have ghc workign with cygwin, so maybe i can
> > get it working...) but if I go to:
> > http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/thrills.htm
> >
> > all the links to downloadable files dont lead anywhere but
> >
> > http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/
> >
> > where I cannot find any files except for Hugs98. Whats up 'dat?
> > Is there a better place to try and grab these goodies?

I've just fix this. The links must have got mistranslated in
the switch to frontpage.

Please do not use <[EMAIL PROTECTED]> for Hugs issues.
The correct e-mail addresses are:

[EMAIL PROTECTED]   <-- for Hugs bugs
[EMAIL PROTECTED]  <-- for other Hugs things

The web page with the problem also gives a strong hint
when it says "Report problems to <[EMAIL PROTECTED]>" :-)

Andy Gill

STGHugs page

[S.D.Mechveliani]

Mabye, STGHugs www page contains a bug?
For I had the same problem as  Ronald J. Legere 
when tried to find and download STGHugs starting from 
http://haskell.org

> 15 Mar 2000 
> From: "Ronald J. Legere" <[EMAIL PROTECTED]>

> Actually I wanted to try STG hugs on my win 98 machine (I know thats
> not supported, but I have ghc workign with cygwin, so maybe i can
> get it working...) but if I go to:
> http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/thrills.htm
>
> all the links to downloadable files dont lead anywhere but
> 
> http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/
>
> where I cannot find any files except for Hugs98. Whats up 'dat?
> Is there a better place to try and grab these goodies?

--
Sergey Mechveliani
[EMAIL PROTECTED]

RE: Possible faq: ffi?

[Ronald J. Legere]

Actually I wanted to try STG hugs on my win 98 machine (I know thats
not supported, but I have ghc workign with cygwin, so maybe i can
get it working...) but if I go to:
http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/thrills.htm

all the links to downloadable files dont lead anywhere but

http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/

where I cannot find any files except for Hugs98. Whats up 'dat?
Is there a better place to try and grab these goodies?

Cheers and thanks!


On Wed, 15 Mar 2000, Julian Seward (Intl Vendor) wrote:

> 
> > There's the new unified FFI, using the "foreign" keyword. I believe,
> > there's a reference to the FFI paper from www.haskell.org.
> 
> Yes, the new STG Hugs, for which Linux and Win32 preview versions are
> already available, supports foreign import/foreign export, so you
> can not only call C from them, but also wrap up arbitrary 
> Haskell functions so they can be called from outside.  Quite handy!
> 
> J
> 

Re: FW: Haskell 98: partition; and take,drop,splitAt

[Fergus Henderson]

On 15-Mar-2000, George Russell <[EMAIL PROTECTED]> wrote:
> Fergus Henderson wrote:
> [snip]
> > For FLOOR_{F->I}(NaN), the result is defined as a NaN:
> [snip]
> > But in both cases this doesn't really make much sense to me,
> > since here the result type of the operation is an integer rather
> > than floating point type.  I guess the earlier part of 6.1 does
> > shed a little extra light:
> 
> The less elevated source of "man floor" tells me that although of
> course floor returns an integer, it returns it represented as a double.
> So perhaps that's the idea.  Or maybe I'm talking rubbish and it
> says explicitly in the standard that FLOOR_{F_I} returns something
> of integer type.

Yes, `FLOOR_{F->I}', which is my Latex-style ASCII-ization
of what appears in the standard as `FLOOR' with a subscript `F->I',
is a function from floating point to integer.  That is the one
which should correspond with Haskell's `floor' function, which
according to the Haskell 98 Report has type

floor :: (RealFrac a, Integral b) => a -> b

LIA-2 also has a separate floor function named `FLOOR_{F->F}';
this one is a function from floating point to floating point,
and as such corresponds to C's floor() function.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: FW: Haskell 98: partition; and take,drop,splitAt

[George Russell]

Fergus Henderson wrote:
[snip]
> For FLOOR_{F->I}(NaN), the result is defined as a NaN:
[snip]
> But in both cases this doesn't really make much sense to me,
> since here the result type of the operation is an integer rather
> than floating point type.  I guess the earlier part of 6.1 does
> shed a little extra light:

The less elevated source of "man floor" tells me that although of
course floor returns an integer, it returns it represented as a double.
So perhaps that's the idea.  Or maybe I'm talking rubbish and it
says explicitly in the standard that FLOOR_{F_I} returns something
of integer type.

Re: Haskell 98: partition; and take,drop,splitAt

[Fergus Henderson]

On 15-Mar-2000, Malcolm Wallace <[EMAIL PROTECTED]> wrote:
> > 1.  Marcin Kowalczyk pointed out that scanl1 and 
> > scanr1 fail on empty args, whereas they could perfectly well 
> > return [] on such arguments.
> 
> Does the same apply for foldl1 and foldr1?

No, returning [] from foldl1 and foldr1 would be ill-typed.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: FW: Haskell 98: partition; and take,drop,splitAt

[Fergus Henderson]

On 15-Mar-2000, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> 2.  George Russell pointed out that floor(Inf) and floor(NaN) are not 
> defined in Standard Haskell; indeed GHC and Hugs have different behaviour.
> Alternatives
>   (A) Make it explicit that the behaviour in these circumstances
>   is undefined, so that impls may differ
>   (B) Specify that floor should fail (i.e. give rise to a call to
> error)
>   (would this have an performance penalty?)
>   This is what SML does
> 
> I'm inclined to do (A) because it binds impls less, and because it is
> in effect what the report currently says.  But I might yield to 
> a determined attack in favour of (B).

In the absence of any compelling arguments otherwise, I would on general
principles recommend doing whatever the LIA ("Language Independent
Arithmetic") standard says.

However, this is unfortunately easier said than done!

I have ISO/IEC 10967-1 (LIA Part 1 -- Integer and Floating Point Arithmetic)
in front of me, but the floor function is covered in ISO/IEC 10967-2 (LIA Part
2 -- Elementary numerical functions), of which I have only a five-year-old
working draft.  The 10967-2 WD says

 |  15.1  FLOOR_{F->I} - Convert to integer (round toward -infinity).
 |  ...
 |  FLOOR_{F->I}(+ infinity) = _undefined_
 |  FLOOR_{F->I}(- infinity) = _undefined_

But here _undefined_ does not simply mean that the behaviour
is undefined; it is an LIA-defined term set in bold font and has a
special meaning.  An _undefined_ result denotes an exceptional value
which when returned causes an _undefined_ notification.

One possible result for a notification is for the system
to raise an exception.  Another possibility is for it to
set some global flags and to then return a continuation value.

 |  6.1  Continuation values
 |  ...
 |  For an _undefined_ notification, the continuation value
 |  shall be a quiet NaN.

For FLOOR_{F->I}(NaN), the result is defined as a NaN:

 |  6 Notification
 ...
 |  If any operation specified in this part of ISO/IEC 10967 is passed
 |  a signalling NaN as an input, then an _undefined_ notification shall
 |  result.
 |
 |  If any operation specified in this part of ISO/IEC 10967 is passed
 |  a quiet NaN as an input, then no notification occurs and the result
 |  of the operation is a quiet NaN
 ...

But in both cases this doesn't really make much sense to me,
since here the result type of the operation is an integer rather
than floating point type.  I guess the earlier part of 6.1 does
shed a little extra light:

 |  6.1 Continuation values
 | 
 |  Continuation values of -0, +infinity, -infinity, and NaN
 |  are required only if the implementation can represent
 |  such non-numeric values in the result type.

Well, in this case the implementation clearly can't represent
such non-numeric values in the result type.  So I'm not sure
what, if any, requirements LIA-1 and LIA-2 impose in this case.
It appears that they do not impose any requirements.
But I'm not very sure about this, and my LIA-2 draft is very
out-of-date.  I think an LIA guru is needed ;-)

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: HaskellDoc?

[George Russell]

Volker Wysk wrote:
> 
> Hello.
> 
> The mentioned requirements point to using SGML for literate programming.
> This would lead to a systematic approach.
Can you summarise please the main ways in which (as an example) GHC development
would be helped if SGML was used?

Re: Haskell 98: partition; and take,drop,splitAt

[Malcolm Wallace]

> 1.  Marcin Kowalczyk pointed out that scanl1 and 
> scanr1 fail on empty args, whereas they could perfectly well 
> return [] on such arguments.

Does the same apply for foldl1 and foldr1?

Regards,
Malcolm

HaskellDoc?

[Volker Wysk]

Hello.

The mentioned requirements point to using SGML for literate programming.
This would lead to a systematic approach.

See

Literate Programming with SGML and XML
http://www.oasis-open.org/cover/xmlLitProg.html

SWEB: an SGML Tag Set for Literate Programming
http://www.uic.edu/~cmsmcq/tech/sweb/sweb.html


bye

Multiparameter type classes

[Viktor Kuncak]

I am writing (another) modular interpreter in Haskell (Hugs98 actually).

I keep having problems with multiparameter type classes.

Is there any sort of user's manual for this yet non-standard construct?

I understand the idea, and it is all fine when it works, but there are
many restrictions that
I do not understand. I am not sure I am ready to delve into all
implementation details to
undestand why e.g. some instance declarations are allowed and some not.

Viktor

FW: Haskell 98: partition; and take,drop,splitAt

[Simon Peyton-Jones]

Folks

Once the ICFP dust is subsided I want to get back to 
completing the Haskell 98 bug list, and then producing
a version of the report that includes all the fixes.

Re take and drop

> | * Opinion seems pretty evenly balanced between
> | (A) Accept negative arg (take yields [], drop yields xs)
> | (B) Fail on negative arg

I've decided on (A).


Three new things have come up:

1.  Marcin Kowalczyk pointed out that scanl1 and 
scanr1 fail on empty args, whereas they could perfectly well 
return [] on such arguments.  I asked the World Scan Expert, John
O'Donnell about this. He agrees.

| [This] makes them more consistent with the Haskell98 definitions of
| scanl and scanr, and I can't think of any situation where it would
| actually be better to produce the error message if the list argument
| is empty.
| 
| However, I continue to think that the definitions of scanl and scanr are
| badly broken in Haskell, and I always have to use my own definitions
| in all my work where scans are used.  I'm not proposing fixing the
| definitions of scanl and foldl, because this is far more than a typo.

So I propose to adopt this change, in the same spirit as that for take/drop.


2.  George Russell pointed out that floor(Inf) and floor(NaN) are not 
defined in Standard Haskell; indeed GHC and Hugs have different behaviour.
Alternatives
(A) Make it explicit that the behaviour in these circumstances
is undefined, so that impls may differ
(B) Specify that floor should fail (i.e. give rise to a call to
error)
(would this have an performance penalty?)
This is what SML does

I'm inclined to do (A) because it binds impls less, and because it is
in effect what the report currently says.  But I might yield to 
a determined attack in favour of (B).


3.  Manuel points out 

| There is a typo in the grammar for list comprehensions in
| Section 3.11 of the Haskell report.  It says,
| 
|   exp   -> [ exp | qual_1, ..., qual_n ]  (list comprehension, n >= 0)
| 
| but I think, it should read `n >= 1'.  At least, it says `n
| >= 1' five lines later and both GHC and Hugs raise an error
| when fed the expression `[1 |]'.
| 
| Furthermore, I am unsure about the intention of the
| 
|   qual  ->  (empty qualifier)
| 
| production, which would make `[1 | , ]' legal, or also `[1 | 
| True, ]' - both of which GHC and Hugs don't like.

I must say that I'm strongly tempted to disallow empty qualifiers
and make n>=1.  I'm not sure how this change crept in in the first
place.  Does anyone care?  Urgle.

Simon

Re: why software needs an explicit license

[George Russell]

I have no problem with software having an explicit license, I just don't see
that it normally needs to be quoted at the top of EVERY module.   (There
are probably exceptional jurisdictions where it does, but not many.)
The GHC method, where the license file is in the distribution and easy
to find if you want it, seems fair enough to me.

Re: ghc-4.06-1.src.rpm (was: ghc to be dropped from potato (debian)

[Sven Panne]

Reuben Thomas wrote:
> It was more that we wanted a package that was easy to install and
> use. [...]

As already pointed out, the SuSE distribution uses self-made db2foo
tools, which are slightly incompatible to the ones used in the rest
of the world. Perhaps some people on this list could complain to the
SuSE support, I wasn't very successful with my attempts...  :-(

Cheers,
   Sven
-- 
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen  Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne

Re: why software needs an explicit license

[Antti-Juhani Kaijanaho]

On Tue, Mar 14, 2000 at 01:57:23PM -0800, Richard Uhtenwoldt wrote:
> if you want to recoup the costs of your writing a program, then charge
> money for it.  if you decide not to try to recoup your costs, then
> please include an explicit license (like the GPL, the LGPL, or the BSD
> license) that gives your users permission to share with each other
> modified versions of the program.  (for more info, see opensource.org,
> gnu.org, news:gnu.misc.discuss.)

Or even better: do both.  There are several companies that make money
out of free software, and some of them do development (some are pure
support companies).  You will, of course, have to change your business
strategy for that to work: with free software, you don't have a monopoly
on the code.

-- 
Antti-Juhani Kaijanaho
http://www.iki.fi/gaia/

Re: ghc-4.06-1.src.rpm (was: ghc to be dropped from potato (debian)

[Reuben Thomas]

On Wed, 15 Mar 2000, Peter Hancock wrote:

> says that the project has been suspended.)  I suppose the problem here
> is that the ghc people (laudably, sensibly, etc, ..) want a doc package
> that makes rtf as well as the usual unix doc formats.

It was more that we wanted a package that was easy to install and
use. Personally, I've never managed to get jade to work by using it
directly. It's hard to compile, the catalog is hard to configure, and the
command line options are hard to work out as the whole thing is documented
in SGML-ese rather than UNIX-ese.

-- 
http://sc3d.org/rrt/ | certain, a.  insufficiently analysed

Re: HaskellDoc?

[George Russell]

"Manuel M. T. Chakravarty" wrote:
> IMHO it would be much more important to think about a
> mechanism for automatically extracting all the interface
> information (including the interface comments) from a
> Haskell module.  Something like an automatically generated
> Modula-2 definition module that defines and explains the
> interface without forcing the reader to wade through the
> implementation.
A less technological solution which has been suggested before would be an
extension to the Haskell language to allow type annotations in
module export lists.  This would allow a considerable part of the
interface to be documented and automatically checked in one central
place.  I could then write a typical Haskell module in the following order: 
(1) module export list, listing types and comments for all values; 
(2) import list; (3) interface and type declarations; (4) all non-trivial code.  
Then it is easy to get at the interface (sections (1) & (3)), but at the 
same time you don't have to duplicate the same stuff in different places.

RE: ghc-4.06-1.src.rpm (was: ghc to be dropped from potato (debian)

[Simon Marlow]

> After a _lot_ of ferreting round the net, I found db2dvi in
> stylesheets-0.10-2.i386.rpm.

Ah, cool.  Reuben: we should document this.  Manuel: if this RPM contains
all the tools we need, should it be added as a build dependency?

> (Actually, it's not in
> docbook-3.1-5.i386.rpm, or psgml-1.2.1-1.i386.rpm, or
> sgml-tools-1.0.9-5.i386.rpm, or jade-1.2.1-9.i386.rpm, or ...)  The
> adjective `exotic' seems apt.  (By the way, the docbook web page
> says that the project has been suspended.)

I presume you mean the SGML-Tools project.  Indeed this has been suspended,
which is one reason we went with the Cygnus DocBook tools suite (and dumped
SGML-Tools 1.x, which is what we used to use).

> I suppose the problem here
> is that the ghc people (laudably, sensibly, etc, ..) want a 
> doc package
> that makes rtf as well as the usual unix doc formats.

Actually we just wanted a packaged up suite of DocBook stuff, and the
DocBook tools seemed to be the only one being actively developed and
maintained.  Hopefully this stuff will become more mainstream; there are
quite a few projects using DocBook now.

Cheers,
Simon

Re: ghc-4.06-1.src.rpm (was: ghc to be dropped from potato (debian)

[Frank Atanassow]

Peter Hancock writes:
 > After a _lot_ of ferreting round the net, I found db2dvi in
 > stylesheets-0.10-2.i386.rpm.  (Actually, it's not in
 > docbook-3.1-5.i386.rpm, or psgml-1.2.1-1.i386.rpm, or
 > sgml-tools-1.0.9-5.i386.rpm, or jade-1.2.1-9.i386.rpm, or ...)  The
 > adjective `exotic' seems apt.  (By the way, the docbook web page
 > says that the project has been suspended.)  I suppose the problem here
 > is that the ghc people (laudably, sensibly, etc, ..) want a doc package
 > that makes rtf as well as the usual unix doc formats.

If db2dvi is so hard to find on a typical installation, you (the GHC docs
person, Reuben, I think?) might just want to duplicate its functionality. I
am pretty sure that all db2dvi (and db2{ps,rtf,..}) is is just glue that finds
the DocBook DTD, stylesheets, entities and other stuff and then just calls
jade with the right output type option to do the actual formatting, so it's
really a one-liner if you know the locations of the files (OK, big "if" on a
Unix system...).

-- 
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791

RE: Possible faq: ffi?

[Julian Seward (Intl Vendor)]

> There's the new unified FFI, using the "foreign" keyword. I believe,
> there's a reference to the FFI paper from www.haskell.org.

Yes, the new STG Hugs, for which Linux and Win32 preview versions are
already available, supports foreign import/foreign export, so you
can not only call C from them, but also wrap up arbitrary 
Haskell functions so they can be called from outside.  Quite handy!

J

Re: ghc-4.06-1.src.rpm (was: ghc to be dropped from potato (debian)

[Peter Hancock]

> "Manuel" == Manuel M T Chakravarty <[EMAIL PROTECTED]> writes:

> As already pointed out by some people, you need the DocBook
> tools to build the documentation.

After a _lot_ of ferreting round the net, I found db2dvi in
stylesheets-0.10-2.i386.rpm.  (Actually, it's not in
docbook-3.1-5.i386.rpm, or psgml-1.2.1-1.i386.rpm, or
sgml-tools-1.0.9-5.i386.rpm, or jade-1.2.1-9.i386.rpm, or ...)  The
adjective `exotic' seems apt.  (By the way, the docbook web page
says that the project has been suspended.)  I suppose the problem here
is that the ghc people (laudably, sensibly, etc, ..) want a doc package
that makes rtf as well as the usual unix doc formats.

> Maybe I can make the building of the documentation
> conditional (but then I can already imagine the ``I build
> from source and now can't find the documentation bug
> reports''). 

> Any ideas?

Check for the existence of db2dvi in the configure phase, and fail
then, rather than right at the end of a (long and machine-crucifying)
build?  (From
http://www.redhat.com/support/wpapers/rpm3.0/building.html,..) 
"RPM 3.0 supports build prerequisites.  A build prerequisite permits a
source package to check whether all the components necessary to build
a package are installed on the build system."

>> It would be great if at least one haskell system could get into the
>> standard linux distributions.  ...

> Sure - any idea how to get Red Hat to include the stuff?

I've asked a (busy) friend who works for redhat.  I'll pass on any
info if/when he replies.  I think ghc would probably be a "contrib"
package.  For redhat, "We do not guarentee that they will work, fix
anything etc. They are just a public service that we lend to users (ie
a central repository)."

Finally, in case I am giving the wrong impression, thanks _very_ much
for taking the trouble to make a src.rpm.  

Re: Possible faq: ffi?

[Hannah Schroeter]

Hello!

On Tue, Mar 14, 2000 at 06:00:36PM -0800, Ronald J. Legere wrote:

>   I know that GHC has _ccall_, but what way can I call 
> foreign functions in Hugs? Is there a way? I see the primitive
> keyword used in prelude.hs, but really there is no docs
> that I can find about how to use it, or if that is what I should use.
> I poked around in the library a bit... I could not find any
> function of type String -> a -> IO a 
> {Thats the type I imagine such a function having :) 

There's the new unified FFI, using the "foreign" keyword. I believe,
there's a reference to the FFI paper from www.haskell.org.

And there's c2hs and there's green-card in addition to H/Direct.

> [...]

Regards, Hannah.

Re: Haskell + Functional GUIs

[Hannah Schroeter]

Hello!

On Tue, Mar 14, 2000 at 03:07:38PM +0100, Thomas Hallgren wrote:
> [...]

> Today, I put sources for Fudgets [1] version h13t on our ftp site [2]. It
> compiles with HBC and GHC 4.06.

I have patches for h13o to make them compile on GHC without hbcmake/
similar things (i.e. ghc + gmake, no significant other tools).

They are a bit dirty, so I haven't released them yet. However,
given some time, I could try to port them to h13t and publish them,
so at least someone else could clean them up and integrate them.

> Fudgets is still maintained, although we haven't taken the time to make any
> thoroughly tested releases. But it still works well enough to be used in
> undergraduate teaching and in other reserch projects [3].

Is there a change list to describe what has happened to Fudgets
in the meantime?

Regards, Hannah.

PS: Executable sizes are quite large, however, as in significantly
more than one MB for a hello world (first example program),
and my patches use ghc's -split-obj feature for building the libraries.
Is that different with hbc?