Re: Haskell mailing list

[Ralf Muschall]

Hamilton Richards Jr. wrote:

> Would it be possible to have both the current mailing list and a Haskell
> newsgroup? If postings to each were automatically replicated on the other,
> then each reader could take her choice of which one to follow.

Technically, this should be possible (IIRC comp.graphics.gnuplot (which
was
renamed later) did this - I don't know whether it still does).

Against spam, there is a recipe on
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
for users with appropriate machines.

Ralf

RE: GHugsC?

[trb]

Simon Peyton-Jones writes:
 > * We also have a plan for how to modularise STG Hugs so that it
 >   consists of a re-useable C library called the Haskell Execution 
 >   Platform (HEP), plus a number of "clients".  Examples of clients are:
 >  - the normal Hugs textual interface
 >  - an updated version of WinHugs (any volunteers?)
 >  - a "scripting engine", that can Haskell-enable a web browser
 >  - a "haskell server" that enables you to wrap up Haskell source
 >code as a COM object
 >  - and maybe more besides.
 > 
 >   The draft spec for the HEP is at
 >  http://www.haskell.org/ghc/docs/papers/hep.ps.gz

I've just read the paper.

It looks as if the HEP could form the seed of a functional operating system (one
can imagine the HEP staying up for long periods, with new modules and programs
run by it all the while). Knowing your crafty designs, you have probably had
this in mind already. In this sort of situation there are many things that could
be done, and not enough resources to do all of them. As you know well, a good
designer will implement the most important stuff first, and use foresight to
avoid ruling out other important developments later. In this vein I have a few
suggestions, in no particular order:

Reliability is not optional for an OS. There has been talk of how languages like
Haskell might not need memory-protection, since they can guarantee that illegal
accesses will not occur. In practice, people want to call C, and perhaps it is
necessary to have some form of memory protection. This would perhaps greatly
complicate matters. In the meantime, reliability might be considerably improved
by handling SIGSEGVs (presumably caused by calling C) and throwing an exception
that the HEP would handle at the top-level, rather than dying. Of course this
does not stop C from corrupting the HEP.

It would be very nice if the system could handle reflection. Clearly it is going
in this direction already, since a lot of the HEP operations are
meta-programming things. I don't understand very much about reflection, and
haven't understood how it would fit into the framework of pure strongly-typed
functional programming. Judging the many successes of FP, I speculate that FP
and reflection would go very nicely together. Have you come across the TUNES
project ( http://www.tunes.org/ ) ? Francois Rideau may get a little carried
away at times, but he makes the very telling point that much/most computer
programming activity occurs simply because of incompatibility between protocols
(e.g. data structures, APIs etc.). Reflective systems are supposed to overcome
this problem, I think by allowing different concrete representations and
supporting automatic conversion between them.

For a small example of the above incompatibilities, see the recent thread on the
Haskell list about reverse-composition. How the token appears to human readers
is not the most important point - what we really want is to for each function to
have (from birth) a name that is unique world-wide (this can be done by
exploiting the Domain Name System, as Java modules do). So long as the machines
understand the name, it can be presented to a programmer using whatever image he
feels comfortable with (e.g. using the Maverik GPL'ed virtual reality system -
http://aig.cs.man.ac.uk/systems/maverik/). But the representation should be
abstract. In order to do this well, we probably need reflection.

The way the STG machine uses info pointers seems very suitable for reflection
(the info pointer specifies how the data is to be interpreted). At least it
would be sensible to have some discussion with someone who really understands
reflection, and see what is possible.

The paper mentions that entries cannot be ejected from the HEP text table when a
module is deleted. This would be bad for a functional operating system - the
text table would expand relentlessly.

It would be nice if the new run-time system could support persistent data. This
might not be hard - I've thought about hacking up something like this from time
to time, and it seems a simple implementation would be little more than use of
mmap. Because the (memory-mapped) persistent store will be large, it may
be necessary to separate the persistent and transient heaps for GC purposes - we
only want to GC the persistent store occasionally. OTOH generational GC might do
the trick. For a quick hack, I thought of committing a persistent data structure
by means of a GC having the data structure(s) as its rootset, and using the
persistent store as the to-space so that (after this GC) the persistent store
will not contain any references to transient memory (this requires prohibiting
mutable variables in the persistent store, otherwise locations could be assigned
to point to transient memory). After such a commit it would be safe to unmap the
store. Closures would be okay if the GC also followed STG info pointers and
tables, so that the relevant code etc. was copied into the pe

Unique Types in haskell (was Re: OO in Haskell)

[Kevin Atkinson]

Lars Lundgren wrote:
> 
> On Mon, 11 Oct 1999, Adrian Hey wrote:
> 
> > On Mon 11 Oct, Lars Lundgren wrote:
> > > I'm sure a lot of poeple have gotten this wrong. I would be surprised if
> > > not all the experienced haskellers has this view though.
> >
> > Probably so, but this view seems in complete contradiction to
> > that of the Clean world. So I'm still confused :-)
> >
> 
> I just took a glance at Clean. (Glanced through "The Ins and Outs of Clean
> I/O" by Peter Achten and Rinus Plasmeijer.) I think their solution with
> unique types is really neat.
> 
> One downside may be that they have made the type system more complex
> since it has to handle all the uniqness tags.
> 
> They deal with side effects (IO) by tagging the values with * and calling
> them unique. Haskell deals with side effects (IO) by using an abstract
> data type IO a which denotes an action [with clean type *World ->
> (a,*World) ]. In both cases, the compiler is notified that it is not ok to
> change order of evaluation.
> 
> In the Related work section, they mention Monadic IO and writes "To our
> knowledge combining monads of different type is a rather tedious task..."
> 
> I'm reluctant to say that I agree. I have written a few programs using
> monad transformers and while everything works in principle, it is, well -
> tedious...
> 
> I also do not like the tendency to put more things in the IO monad (I'm
> thinking about the extensions with IORef). I like stToIO better, but
> somehow it still feels like a hack. Maybe some library support for monad
> transformers and maybe even some syntactig sugar would do the trick.
> 
> They also wrote "[The monadic IO approach] over determines order of
> evaluation". I'm a bit puzzled about that statement. Is it true? Comments
> anyone?

I have been meaning to bring this up for quite some time.  I think
Haskell could really benefit from a uniqueness typing system as it would
really simplify many things, such as fast array updates.  Also it opens
the door for TONES of optimization opportunities if the compiler can
also mark standard types of being unique, even if the user did not. 
Eventually the compiler could become so good at uniqueness identifying
that the user will never have to explicitly mark anything as unique
except in the case where its communication to the outside work.  Ie IO
etc. Thus one can write non-destructive array updating programs that
would without an uniqueness type system be horribly inefficient (but
easy to verify as being correct) but with a uniqueness type system will
fast and easy to verify.  Can you ask for more?

-- 
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/

RE: [haskell] list reorg

[Frank A. Christoph]

Simon Marlow wrote:
> Here's my proposal:
>
>   - haskell-announce (v. low volume)
>
>   - haskell-chat (high volume, anything vaguely related to
> Haskell is acceptable)
>
>   - haskell-questions (questions about the use of the language,
> maybe haskell-help or haskell-users)
>
>   - haskell-2 (discussions related to changes/extensions to
> the language)
>
>   - haskell (general discussion list, anything not covered above)

I like this setup except I don't see a need to distinguish between
"haskell-chat" and "haskell".

Also, I have been thinking about the comp.lang.haskell proposal and, spam
problems aside, I am not opposed to it, provided that people can participate
via email as well as Usenet; this must be possible, since the ML list is
doing it. (Indeed, I didn't realize that the ML list was identical to
comp.lang.ml until a few months after I joined it!)

--FAC

Re: Question on graphics

[Keith Wansbrough]

> > "Ronald" == Ronald J Legere <[EMAIL PROTECTED]> writes:
> 
> > I am wondering however if there is anykind of small package
> > to enable me to make simple plots (of functions for example)..
> > This is for windows (98) machine, so I cant use Gif Writer, which
> > seems sort of how to do it on unix machines
> 
> I don't know.  If there isn't I think there is a postscript driver
> of some kind described in The functional approach to programming by
> Cousineau and Mauny CUP 98.  (In Caml, but maybe it is cribbable.)

In a similar vein, although I haven't tried it, there's fun->pdf,
which writes Acrobat PDF files (compressed Postscript).  It's on the
Haskell libraries page, under "Various".

--KW 8-)

Barmy idea for the day: Type annotations in export lists

[George Russell]

It would be nice to be able to say
   module Shape(
  Shape,
  Square :: Int -> Shape,
  RotateDegrees :: Int -> Shape -> Shape,
  ...
  ) where . . .
Ideally one would want to be able to have instance declarations as well.
This would mean that someone using the Shape module would only have
to look at the top of the file.  Of course such information can be
added in comments, but then there is no way of checking it.

This is dangerously close to the SML syntax:
structure Shape :> 
sig
   BLAH
end =
...
but I think it is somewhat simpler.  (In my opinion the SML
module system is too complicated.

Re: O, O'Haskell, where are you?

[Alex Ferguson]

> Does anyone have a 'live' link to Johan Nordlander's O'Haskell?
> http://www.cs.chalmers.se/~nordland/ohaskell/ seems to be unwell.

You're all going to think I'm mad, but the above link has now
'recovered'...

Cheers,
Alex.

RE: Unicode, emacs, xterm, (Linux)

[Karlsson Kent - keka]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--_=_NextPart_001_01BF14BC.3D42C660
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> But it is hard to use some nonstandard (i.e. neither vi nor emacs)
> editor just for one special kind of source code

Well, you could use it for Java, C, Ada, COBOL, Omega/Lambda,
and XML too! ;-)  All of which in some (more or less fumbling)
way allow non-ASCII in identifiers.  (No, none of them have
got it quite right yet.)

I haven't followed all on what is done regarding Unicode in emacs,
but apparently Unicode gets into emacs too (see below). I never
use emacs myself, so I haven't tried the package ref. below in any
way whatsoever.  You probably need to install some more or less
Unicode enabled font too, suitable for your system.  Try starting
at http://www.cl.cam.ac.uk/~mgk25/unicode.html
  if you use Linux.
There is also a (partially) Unicode enabled xterm for Linux.
(No, I haven't tested it.)

Kind regards
/kent k

TEST:
Markus Kuhn [=CB=88ma=CA=B3k=CA=8As ku=CB=90n] <[EMAIL PROTECTED]> =
=E2=80=94 1999-08-20


The ASCII compatible UTF-8 encoding of ISO 10646 and Unicode
plain-text files is defined in RFC 2279 and in ISO 10646-1 Annex R.


Using Unicode/UTF-8, you can write in emails and source code things =
such as

Mathematics and Sciences:

  =E2=88=AE E=C2=B7da =3D Q,  n =E2=86=92 =E2=88=9E, =E2=88=91 f(i) =3D =
=E2=88=8F g(i), =E2=88=80x=E2=88=88=E2=84=9D: =E2=8C=88x=E2=8C=89 =3D =
=E2=88=92=E2=8C=8A=E2=88=92x=E2=8C=8B, =CE=B1 =E2=88=A7 =C3=9F =3D =
(=CE=B1 =E2=88=A8 =C3=9F),

  =E2=84=95 =E2=8A=86 =E2=84=95=E2=82=80 =E2=8A=82 =E2=84=A4 =E2=8A=82 =
=E2=84=9A =E2=8A=82 =E2=84=9D =E2=8A=82 =E2=84=82, =E2=8A=A5 < a =
=E2=89=A0 b =E2=89=A1 c =E2=89=A4 d =C2=AB =E2=8A=A4 =E2=87=92 (A =
=E2=87=94 B),

  2H=E2=82=82 + O=E2=82=82 =E2=87=8C 2H=E2=82=82O, R =3D 4.7 k=CE=A9, =
=E2=8C=80 200 mm

END TEST




> -Original Message-
> From: Otfried Cheong [ mailto:[EMAIL PROTECTED] =

]
> Sent: den 11 oktober 1999 07:05
> To: [EMAIL PROTECTED]
> Subject: Unicode in GNU Emacs update
>
>
>
>
> I announced my small package to use Unicode in GNU Emacs here a week
> ago.  I've made several changes to the package since then, and if you
> are using it you may want to upgrade.
>
> The newest version allows you to put the cursor on a character and =
hit
> a key to get the Unicode character information on it.  With the =
cursor
> on the Euro sign, you'd get:
>
> UCS: 20AC (EURO SIGN)
> General Category: Symbol, Currency
> Canonical Combining Classes: 0
> Bidirectional Category: ET
> Mirror-able: N
> Title-case =3D nil
>
> Also you can now insert characters using their Unicode number.
>
> The package is still at http://www.cs.ust.hk/~otfried/Mule
 .
>
> Otfried
>
>
> -
> Linux-UTF8:   i18n of Linux on all levels
> Archive:  http://mail.nl.linux.org/lists/
=20
>=20


--_=_NextPart_001_01BF14BC.3D42C660
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable








> But it is hard to =
use some=20
nonstandard (i.e. neither vi nor emacs)> editor just for one =
special kind=20
of source codeWell, you could use it for Java, C, Ada, COBOL,=20
Omega/Lambda,and XML too! ;-)  All of which in some (more or =
less=20
fumbling)way allow non-ASCII in identifiers.  (No, none of =
them=20
havegot it quite right yet.)I haven't followed all on what =
is done=20
regarding Unicode in emacs,but apparently Unicode gets into emacs =
too (see=20
below). I neveruse emacs myself, so I haven't tried the package =
ref. below=20
in anyway whatsoever.  You probably need to install some more =
or=20
lessUnicode enabled font too, suitable for your system.  Try=20
startingat http://www.cl.cam.ac.uk/~mgk25/unicode.html"=20
target=3D_blank>http://www.cl.cam.ac.uk/~mgk25/unicode.html if you =
use=20
Linux.There is also a (partially) Unicode enabled xterm for =
Linux.(No, I=20
haven't tested it.)   =20
    Kind=20
regards   =20
    /kent kTEST:Markus=20
Kuhn [=CB=88ma=CA=B3k=CA=8As ku=CB=90n] <[EMAIL PROTECTED]> =E2=80=94 =
1999-08-20The ASCII=20
compatible UTF-8 encoding of ISO 10646 and Unicodeplain-text files =
is=20
defined in RFC 2279 and in ISO 10646-1 Annex R.Using =
Unicode/UTF-8,=20
you can write in emails and source code things such =
asMathematics and=20
Sciences:  =E2=88=AE E=C2=B7da =3D Q,  n =E2=86=92 =
=E2=88=9E, =E2=88=91 f(i) =3D =E2=88=8F g(i), =
=E2=88=80x=E2=88=88=E2=84=9D: =E2=8C=88x=E2=8C=89 =3D=20
=E2=88=92=E2=8C=8A=E2=88=92x=E2=8C=8B, =CE=B1 =E2=88=A7 =C3=9F =3D =
(=CE=B1 =E2=88=A8 =C3=9F),  =E2=84=95 =E2=8A=86 =
=E2=84=95=E2=82=80 =E2=8A=82 =E2=84=A4 =E2=8A=82 =E2=84=9A =E2=8A=82 =
=E2=84=9D =E

Re: The Haskell mailing list

[Hannah Schroeter]

Hello!

On Fri, Oct 08, 1999 at 07:04:07AM -0400, Paul Hudak wrote:
> Perhaps we should create a comp.lang.haskell?  -Paul

Frankly, I think there's still enough room in c.l.functional for Haskell
related threads. However, if a discussion and vote comes up for a
Haskell newsgroup, I'll off course still vote in favor of the newsgroup.

To the mailing lists, I could imagine something like this:

haskell (or haskell-misc)   Misc discussion, may be high traffic
A place where new people are welcome, in addition
to a newsgroup if it comes to exist.
haskell-announceModerated announcements (new versions of
Haskell implementations, libraries, conferences etc)
haskell-langThe language itself (interpretation of the report,
extensions, Haskell-2). I'd NOT call it haskell-2,
even if it mostly covers that, as if we call it
haskell-2, haskell-3 will be off-topic there once
Haskell 2 is out.
haskell-research or haskell-moderated or something like this
Low traffic, high level discussion group for
anything not covered by haskell-lang and
haskell-announce

Perhaps haskell-lang and -research(-moderated, hence the suggestion)
could be moderated too, in a style like comp.compilers.

Globally interconnecting a mailing list and a newsgroup is prone to
problems in my eyes, so I'm against that. Nothing against locally
gating the mailing lists into no-posting or moderated (with the
submission address as moderation address) newsgroups, like
local.lists.haskell.misc
local.lists.haskell.announce
local.lists.haskell.lang
local.lists.haskell.research

Regards, Hannah.

O, O'Haskell, where are you?

[Alex Ferguson]

Does anyone have a 'live' link to Johan Nordlander's O'Haskell?
http://www.cs.chalmers.se/~nordland/ohaskell/ seems to be unwell.

Cheers,
Alex.