do-and-if-then-else modification

[isaac jones]

Iavor and I just made the trivial modification for DoAndIfThenElse
syntax as described here:
http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse

You can see the change here:
http://darcs.haskell.org/haskell-prime-report/report/haskell-report-html/exps.html

(Is there anything else that needs to change?)

As always, we provide a quick view of the status of Haskell' here:
http://hackage.haskell.org/trac/haskell-prime/wiki/Status%27

Any comments on this modification?  How do people feel about the
suggestion that we do it for case statements as well?

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

self moderation (or, what is Haskell' about)

[isaac jones]

Folks,

We all love to talk about fun and exciting new things, and I really
don't like to "change the subject", as it were, of a mailing list
conversation unless it's very necessary.

This list is unmoderated, and will stay unmoderated.  Anyone can post
whatever they want, and it's up to the community of the list to decide
what's appropriate and what's off topic.  If you see stuff that you
think is off topic, please invite that discussion to move over to
haskell-cafe or what-have-you.  If you start a discussion about
something core to Haskell', especially the "definitely in" topics, and
the conversation wanders into strange and unknown territory, please,
please re-focus your thread to get back to the important topics.  Start
a new thread if necessary with a summary of the discussion so far and
the open questions.

We've had a lot of people unsubscribing from the list in the last few
days, for what it's worth.

People get a mistaken impression about "What Haskell' is about" based on
the discussions of the list, and sometimes it scares people :)  So just
be aware that the unmoderated list is _not_ a good way to get a sense of
what's going on in Haskell'.  Watch for announcements from the committee
and requests for help from me and others for actually writing the
report.  Also, keep an eye on the status page of the wiki:

http://hackage.haskell.org/trac/haskell-prime

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

help from the community?

[isaac jones]

On Sun, 2007-01-21 at 14:25 -0800, Iavor Diatchki wrote:
> Hello,
> 
> I have written some notes about changes to Haskell 98 that are
> required to add the "polymorphic components" extension.   The purpose
> of the notes is to enumerate all the details that need to be specified
> in the Haskell report.  I don't have access to the haskell-prime wiki
> so I attached the notes to the ticke for polymorphic components:
> http://hackage.haskell.org/trac/haskell-prime/ticket/57
> 
> When there are different ways to do things I have tried to enumerate
> the alternatives and the PROPOSAL paragraph marks the choice that I
> favor.

Does anyone have any feedback on this work?  The critical path for
Haskell', at this point, is writing these bits of the report and having
them validated by the community.

But no one has read and commented on these topics:
- Plans for changes to the report relating to Polymorphic Components
- Draft changes to the report for pattern guards

I understand that taking the time to pour over the report is a bit hard,
but we desperately need people who are willing to do so if we're going
to make progress.

I think Iavor and I will start to make these changes tomorrow; does
anyone have feedback before then?

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

patch applied (haskell-prime-report): pattern_guard_list_comprehension_footnote

[Isaac Jones]

Fri Jan 19 15:23:01 PST 2007  'Ravi Nanavati <[EMAIL PROTECTED]>'
  * pattern_guard_list_comprehension_footnote

M ./report/exps.verb -1 +3
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

pattern guards: recent changes to draft haskell prime report

[isaac jones]

Greetings!

We've been working to add pattern guards to the Haskell' report, and
doing some cleanup work on the repository. Not all of the emails are
making it to the list, sadly, but here's a list of recent changes from
the report.

You can view the report itself here (I couldn't think of a good place to
put it):
http://hackage.haskell.org/~ijones/haskell-prime-report/report/haskell98-report-html/

peace,

  isaac

Fri Jan 12 16:32:28 PST 2007  [EMAIL PROTECTED]
  * moved rules for guards in a separate figure because the old
figure
didn't fit on a page

Fri Jan 12 16:21:46 PST 2007  [EMAIL PROTECTED]
  * fixed rule (g) of pattern semantics to avoid duplicating the
evaluation of e'

Fri Jan 12 16:13:50 PST 2007  [EMAIL PROTECTED]
  * added rules for pattern guards to the formal semantics of
case

Fri Jan 12 14:53:30 PST 2007  [EMAIL PROTECTED]
  * gneralized function bindings to support pattern guards, not
just
boolean guards

Thu Jan 11 16:59:30 PST 2007  [EMAIL PROTECTED]
  * reworking the informal explanation of pattern gaurds
  Modified the syntax again to talk about "guards" (which are
pattern
guards,
  boolean guards, and let expressions) .  Moved the "Pattern
guards"
section
  I created before into the Case Expressions section.

Thu Jan 11 15:51:14 PST 2007  [EMAIL PROTECTED]
  * update pattern binding translation for pattern guards (with
Iavor's
help!)

Mon Jan  8 10:21:14 PST 2007  Andres Loeh <[EMAIL PROTECTED]>
  * turn macro into function -- makes it work with newer flex
versions

Mon Jan  8 09:50:40 PST 2007  Andres Loeh <[EMAIL PROTECTED]>
  * don't include extension in \includegraphics (to make
compatible with
pdflatex)

Mon Jan  8 09:20:29 PST 2007  Andres Loeh <[EMAIL PROTECTED]>
  * typo: change \r to \tr





___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-report): some notes on how to build it.

[isaac jones]

On Mon, 2007-01-08 at 13:42 +, David House wrote:
> On 08/01/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > Mon Jan  8 03:11:48 PST 2007  Simon Marlow <[EMAIL PROTECTED]>
> >   * some notes on how to build it.
> >
> > M ./README -6 +26
> 
> Using the flex version 2.5.31, straight out of apt, I get the following error:
> 
> flex -t -8 verbatim.lex > verbatim.c || ( rm -f verbatim.c && exit 1 )
> verbatim.lex:75: warning, rule cannot be matched
> cc -c verbatim.c -o verbatim.o
> :561:25: error: macro "yywrap" passed 1 arguments, but takes just 0
> make: *** [verbatim] Error 1
> 
> Using the flex-old package, which is version 2.5.4a, it works. I guess
> this means our flex files are legacy. Could they be updated to work
> with the latest flex?

This has been fixed :)

It turns out that not all mods are posted to the mailing list, due to
subscription requirements.

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

patch applied (haskell-prime-report): update pattern binding translation for pattern guards (with Iavor' s help!)

[Isaac Jones]

Thu Jan 11 15:51:14 PST 2007  [EMAIL PROTECTED]
  * update pattern binding translation for pattern guards (with Iavor's help!)

M ./report/decls.verb -7 +9
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

patch applied (haskell-prime-report): reworking the informal explanation of pattern gaurds

[Isaac Jones]

Thu Jan 11 16:59:30 PST 2007  [EMAIL PROTECTED]
  * reworking the informal explanation of pattern gaurds
  Modified the syntax again to talk about "guards" (which are pattern guards,
  boolean guards, and let expressions) .  Moved the "Pattern guards" section
  I created before into the Case Expressions section.

M ./report/decls.verb -3 +4
M ./report/exps.verb -63 +71
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

very rough draft of informal pattern-guard (qualifiers) explanations

[isaac jones]

I just pushed a very rough draft of the plain, informal text for pattern
guards.  I'm also attaching the patch.

http://darcs.haskell.org/haskell-prime-report/report/exps.verb

I'd like some feedback about the approach I'm taking, which varies
slightly from the description in the 2000 HW paper.

Since "pattern guards" are defined basically as in list comprehensions,
I've pulled a bit of that text into its own section.  In the list
comprehensions section, pattern guards are referred to as "qualifiers",
so I've kept that name.  (From Simon's original memo, it seems that the
generators within the qualifiers are pattern guards.)

So now there's a section that explains qualifiers, including the nested
environment nature.

In many places, I've removed references to guards and replaced them with
references to qualifiers.  I've also consolidated text that explains
guards, which was previously found in various locations, into that
single section as above.

I haven't touched the more semantic bits yet; I'd like some feedback on
my overall approach first.

I've brashly pushed these changes into our darcs repository of the
report in the hopes that others on the committee (or indeed, within the
community) will begin to be a bit more brash.  Alas, I'm unable to
actually build the report at the moment.  If anyone knows how, please
add instructions to the repository, or send them to me and I'll add
them.

peace,

  isaac

p.s. the pattern guard wiki page is here:
http://hackage.haskell.org/trac/haskell-prime/wiki/PatternGuards

p.p.s. http://www.haskell.org/pipermail/cvs-ghc/2007-January/033592.html

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

patch applied (haskell-prime-report): very rough draft of informal pattern-guard (qualifiers) explanations

[Isaac Jones]

Sun Jan  7 19:26:27 PST 2007  [EMAIL PROTECTED]
  * very rough draft of informal pattern-guard (qualifiers) explanations
  This is a very rough draft in order to get some discussion going, and
  does not touch the semantic explanations, which will still need to be
  done.

M ./report/exps.verb -48 +63
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-report): fix line-comment syntax to not consider ' --:' as a comment

[isaac jones]

On Tue, 2006-11-07 at 08:23 -0800, Simon Marlow wrote:
> Tue Nov  7 08:22:46 PST 2006  Simon Marlow <[EMAIL PROTECTED]>
>   * fix line-comment syntax to not consider '--:' as a comment
>   See LineCommentSyntax on the wiki, ticket #42
>   
> 
> M ./report/syntax-lexical.verb -1 +1


Woohoo Simon!  Small though it is, this is the first "official" update
to the Haskell report from the Haskell' committee :)

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Trac Ticket "Component" Field?

[isaac jones]

On Wed, 2006-09-27 at 16:27 -0700, Ashley Yakeley wrote:
> What do the various values of the "Component" field mean? Most issues 
> have "Proposal", but some have "HaskellPrime".

If it is a proposal for something to go into/be removed from the
language, then it should be listed as "proposal".  If it's some task
that we have to perform (write a library API or something), then the
component might be something else.  Proposal is the main one, though.

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Haskell Standard: Please email me if you want to join the committee.

[Isaac Jones]

Greetings,

As announced at the Haskell Workshop, the Haskell Prime process is
running another committee selection round.  We are specifically
looking for people to write sections of the Haskell Report for the
"definitely in" and "probably in" proposals, as described in:

http://hackage.haskell.org/trac/haskell-prime/wiki/Status'

Please email me if you think you would like to write sections of the
report and be on the committee.  Please tell me which of the
"definitely in" or "probably in" sections you would like to help with
writing.

Also, anyone interested in the future of the language should sign up
for the Haskell Prime mailing list if you aren't already:

http://haskell.org/mailman/listinfo/haskell-prime

peace,

   isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Haskell' Status Report

[Isaac Jones]

Ravi Nanavati has very helpfully put together a status report for the
Haskell Prime process.  Please see this link, or read the pasted text
below:

http://hackage.haskell.org/trac/haskell-prime/wiki/Status'

peace,

  isaac


Summary:

Since the Haskell Workshop last year, the Haskell community has
documented (on this wiki) over 70 proposals for changes to Haskell
98. In March of this year, two subcommittees were established to focus
on concurrency and the class system - two difficult areas that are
important to the success of Haskell'. The committee has also used
StrawPolls to filter and discuss the universe of proposals that has
been gathered. Based on the most recent straw poll, 12 proposals
(listed in the table at the bottom of the page) have been identified
that are expected to get into Haskell' (over 2/3 of the committee in
favor). An additional 19 proposals seem likely to get into Haskell'
(based on slightly weaker criteria). Members of the committee conflict
on 9 of the remaining proposals, and their status will be determined
during the writing process. The remaining proposals are not expected
to be part of Haskell'.

Concurrency:

The concurrency support in Haskell' will be based on the
Control.Concurrent library, with minor modifications. There will be a
thread-safe interface for mutable state, suitable for use in library
code that does not otherwise use concurrency (though what it will be
based on is an open issue). There will also be independent FFI
annotations for specifying whether foreign calls are concurrent (with
other Haskell threads) and reentrant. Bound threads will not be
required by the concurrency standard, but they will be an allowed
extension with a specified meaning. Open issues include whether
standard will require preemptive concurrency, the syntax of the new
FFI annotations and the memory-model semantics of IORefs.

Class system:

The work on the class system has focused on resolving the
MultiParamTypeClassesDilemma. The core of the dilemma is that
multi-parameter typeclasses are a popular extension that is strongly
desired for Haskell'. However, many important uses of MPTCs (like the
monad transformer library) require additional extensions to resolve
ambiguities in their typechecking. Historically,
FunctionalDependencies have been used for this purpose, but they are
very tricky to implement and are also difficult to specify in a way
that guarantees the termination of typechecking. AssociatedTypes are a
possible replacement, but our current implementation experience with
them is very limited. The subcommittee has explored several ways to
resolve this dilemma (including restricted FDs, fast-tracked ATs and
FDs as a "blessed" extension), but, so far, no consensus has
emerged. Our current plan is to focus on writing other parts of the
Haskell' standard, in the hopes that additional implementation
experience with ATs will clarify the situation.

Libraries:

Thus far, libraries have been an underemphasized portion of the
Haskell' effort (only 7 of the 70+ proposals have significant library
content). However, there is a consensus that a revised standard
library is an important part of the Haskell' effort. The current plan
is to focus on starting to write the language portions of the standard
first, since we have a substantial amount of work to do there which
requires focused attention. After that effort is well underway, a
companion library effort will begin. Several members of the committee
have volunteered for this effort and additional volunteers will be
needed.


"definitely-in" Proposal Status:
Description (Those volunteering to write this section):
add some kind of Concurrency (IJ, SM)   
add ForeignFunctionInterface (MC, SM)   
add multi-parameter type classes (MS)   
add RankNTypes or Rank2Types (AL)
add PolymorphicComponents (AL)  
add ExistentialQuantification (existential components) (AL, MS, SJT)
add HierarchicalModules (IJ, BH, MW)
add EmptyDataDeclarations (BH, HN)  
DoAndIfThenElse (SM, HN)
fix comment syntax grammar (SM) 
add PatternGuards (RN, DS)  
add InfixTypeConstructors (BH, AL)
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

writing / status teams - call for volunteers

[isaac jones]

Greetings,

There are just a few days to go before the Haskell Workshop, and I'd
like to be able to present the community with a report on our progress.
With that in mind, I'm looking for some help during this busy time of
year.

The Haskell' committee has been voting on the wiki about the relative
strength of various proposals.  We're trying to find a group of
proposals that is "definitely in" so that we can start the hard work of
writing the report.  Here's the survey:

http://hackage.haskell.org/trac/haskell-prime/wiki/StrawPoll-2

The idea is that we want to make some tangible progress on actually
writing the report, so we have selected some pretty non-controversial
proposals.  This is also to get a better idea of where there is and is
not consensus.

Below is the list of so-called "definitely-in" proposals, which is
probably not quite correct.  For instance, I don't think it's clear that
MPTCs are definitely in, but the others look pretty good.

Beside the proposal name is the group of committee members who have
volunteered to write sections for so-called "definitely in" features.

I have several requests for volunteers, which can be within or not
within the committee:

Would anyone else like to volunteer to write a section of the report for
specific proposals below?

Can anyone volunteer to do a survey of the current status of each of
these proposals?  We should try to figure out how far from done we are
on all of them.  I imagine that some things like concurrency are far
from done, while other things like hierarchical modules and empty data
declarations are pretty much done.

Will anyone volunteer to write a status report for the community, with
the goal of finishing the status report by the time of Haskell Workshop.
This obviously isn't something fancy, just a summary of the items
discussed, the current status on them, etc.  This should all be on the
list archives and on the wiki.  A committee member is probably best
suited for this, but anyone following the process closely should be able
to do it :)

Also, everyone should please think about this list as a whole; apply
your right brain to consider whether it's a coherent and elegant set of
proposals.

> In
> ==
> 
> #74: add some kind of concurrency: SM, HN, IJ
> #35: add ForeignFunctionInterface: MC, SM
> #49: add multi parameter type classes: MS
> #60: add RankNTypes or Rank2Types: AL
> #57: add polymorphic components: AL
> #26: add ExistentialQuantification (existential components): AL, MS, SJT
> #24: add HierarchicalModules: BH, IJ
> #25: add EmptyDataDeclarations: BH, HN
> #23: fix common pitfall with the do-notation and if-then-else: SM, HN, 
> #42: fix comment syntax grammar: SM
> #56: add Pattern Guards: :(
> #78: Add infix type constructors: BH, AL
> Help w/ libraries (yay!): IJ, BH, SM, RP, DS

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Small note regarding the mailing list

[isaac jones]

On Tue, 2006-08-29 at 14:04 +0200, Christophe Poucet wrote:
> Hello,
> 
> Just a small request.  Would it be feasible to tag the Haskell-prime
> list in a similar manner as Haskell-cafe?

I'd rather not.  If you want to be able to filter, you can use the
"Sender" field which will always be:
Sender: [EMAIL PROTECTED]


peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

[Fwd: Numeric Class reworking]

[isaac jones]

Forwarding a message that was sent to me.  Vivian, probably it bounced
because you're not subscribed to the list?  Thanks for sending it along.
Anyone replying, please keep Vivian in the CC.

peace,

  isaac

--- Begin Message ---
Hi,

One of the complaints I've seen with people trying to do various
mathematical tasks in haskell is the inflexibility of the numeric
prelude.  The biggest issue is having (*) and (+) in the same
typeclass, but other generalizations are certainly possible.
MPTC would allow such things as modules with (*) having type a -> b -> b
which covers everything from group actions to scalar multiplication
of vectors.

Actually, a -> b -> c would be nice.  See
http://haskell.org/hawiki/DimensionalizedNumbers
  
this would let me have multiplication of numbers with units, enforced at
the type level, while keeping the safety of (+) :: a -> a -> a.

Is there any chance of this sort of breakup happening?

-- 
Aaron Denney
-><-


Haskell is often cited as an elegant and 'mathematical' language in which to
program.  This post is to voice my support for a modified Numeric Prelude
that would be consistent with [1] and/or [2].  It would be an improvement if
the numeric classes were more structured along the lines of algebraic
properties (similar to the monad laws) of various entities.

I remember griping about this when I first learned Haskell.

While the typical user may not need to know about the underlying
mathematical structure of the objects that they are working with, it would
be good if the system were consistent for those that do.

[1] http://haskell.org/docon/
[2] http://cvs.haskell.org/darcs/numericprelude/

Cheers,

Vivian

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.1/389 - Release Date: 14/07/2006
 

--- End Message ---
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org//mailman/listinfo/haskell-prime

Haskell' status & summary

[Isaac Jones]

Greetings!

I'll try to update the Haskell community periodically on the status of
the Haskell' language standard.

As mentioned previously, we are currently focusing on two topics,
concurrency and the class system.  If you feel that you have anything
important to contribute to those topics, now is the time to review the
proposals, join in the Haskell' mailing list and let us know what you
know!

Stephanie Weirich has posted a summary of the class system discussion
here:

http://hackage.haskell.org/trac/haskell-prime/wiki/ClassSystem

Stephanie says:

 This page is important because it lists all of the proposals not
 related to MPTCs as well as trying to capture the big picture
 about where we stand with respect to MPTCs. I've been trying to
 not duplicate text that appears elsewhere in the wiki, but just
 provide a consistent picture of the state of the discussions on
 the mailing list.

 Please take a look at this page and help me fill it out. In
 particular, 've been trying to take a pulse of where we stand on
 some of these issues, and some of you may not agree! Tell me if
 I'm off the wall. Also, I've (mostly) concentrated on issues that
 have tickets, so I may have missed some issues that were only
 discussed in the mailing list.  Please let me know if there is
 anything I've forgotten.

Simon Marlow has posted a summary of the concurrency discussion here:

http://hackage.haskell.org/trac/haskell-prime/wiki/Concurrency

Simon says:

 I have tried to summarise the various points that have arisen
 during the discussion.  If anyone feels they have been
 mis-paraphrased, or I have forgotten something, please feel free
 to edit, or send me some text for inclusion.  I don't want to
 include long gobs of text in here, though: just summarise the
 main points, and if necessary link to relevant mailing list
 posts.

Thanks, Simon & Stephanie for keeping things moving forward!


peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: need help please[HOpenGL]

[isaac jones]

Greetings!  I'm sorry to say that you've contacted the wrong mailing
list for this question.  Please bring your haskell questions to the
haskell-cafe mailing list.

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

postponing discussion on exceptions and deepSeq

[isaac jones]

I'd like to ask the list to postpone discussion on exceptions and
deepSeq until a later iteration.  While these are two topics that are of
deep importance to me, I would prefer to focus on the other two topics
at hand until they are solved.  That is, concurrency, and the class
system.

I'm still postponing opening up another topic since I find that the
class system isn't being as enthusiastically discussed as I had hoped.
Let's all focus our energies on these topics, I promise that the others
won't be forgotten.

Ross has asked for use cases for functional dependencies and so far has
only two replies.  Surely there are those on this list who have use of
functional dependencies?

peace,

  isaac


-- 
isaac jones <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: FDs and confluence

[isaac jones]

On Mon, 2006-04-10 at 14:39 +0100, Claus Reinke wrote:
> > (see the FunctionalDependencies page for background omitted here)
> 
> which seems to ignore much of the discussion of confluence we had 
> here some weeks ago? I thought this list was for communication with 
> the committee, and since the ticket exists, I had been hoping that the
> type class subcommittee would ensure that the wiki would be updated.
> but it seems I have been talking to myself..

Each topic has a ticket that can be edited by anyone as described here:
http://haskell.galois.com/trac/haskell-prime/wiki/CreateProposal


Please take advantage of that to capture data (consensus, pros & cons)
about your topic.  It is not easy to boil down pages and pages of
discussion into a coherent document.  Please help to do that work!
Here's the ticket relating to functional dependencies.

http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/ticket/36

Here are some guidelines from the wiki:

The wiki and Tickets:
No Discussion on the Wiki! Keep discussion on the mailing list and use
the wiki to document consensus and pros & cons. It is just fine to have
conflicting points of view in a ticket or on the wiki, but no
back-and-forth discussion (use the mailing list for that). Create "pros"
and "cons" sections in the ticket/wik.

For Tickets:
For tickets, use EDIT rather than adding "comments". Link this ticket
with wiki pages or other tickets which are related, or for which this is
a counter-proposal.

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: bringing discussions to a close

[isaac jones]

On Tue, 2006-03-28 at 21:16 -0500, Jim Apple wrote:
> On 3/28/06, isaac jones <[EMAIL PROTECTED]> wrote:
> > The only topics that should remain open are concurrency and
> > the class system.
> 
> What happene to bullet 3, "perhaps standard libraries"?

We're still trying to figure out exactly what the 3rd topic should be.
I don't want to hold up discussion on the other topics, though.
Standard libraries is at the top of my list right now because it has
hardly been discussed.

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

bringing discussions to a close

[isaac jones]

Greetings,

As mentioned in my email from Tuesday March 21 [1], I'd like to bring
most threads to a close very soon, and to document your discussions on
the wiki.  The only topics that should remain open are concurrency and
the class system.  Instructions for modifying or creating proposals is
here [2].

peace,

  isaac


[1] http://www.haskell.org//pipermail/haskell-prime/2006-March/001008.html
[2] http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/CreateProposal
-- 
isaac jones <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: MPTCs and functional dependencies

[isaac jones]

On Tue, 2006-03-28 at 14:32 +0100, Simon Peyton-Jones wrote:
> My current take, FWIW.
> 
> * MPTCs are very useful.  They came along very rapidly (well before
> H98).  I think we must put them in H'
> 
> * But MPTCs are hamstrung without FDs or ATs
> 
> * FDs and ATs are of the same order of technical difficulty, as Martin
> says
> 
> * ATs are (I believe) a bit weaker from the expressiveness point of view
> (zip example), but are (I believe) nicer to program with.  
> 
> * BUT we have way more experience with actually programming with FDs.
> ATs fail the "well-established" test by a mile.
> 
> * Largely due to Martin's work, we now have a much better handle on just
> what restrictions on FDs make type inference tractable.  So I believe
> there is a solid MPTC+FD story that we could embody in H'.
> 
> * Medium term, I think ATs may *at the programming-language level*
> displace FDs, because they are nicer to program with.  But that's just
> my opinion, and we don't have enough experience to know one way or the
> other.

This analysis is similar to what I have here:
http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma

Could someone flesh out the wiki w/ Simon's data and links to the new
information from Martin?

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Concurrency (was: RE: Re[2]: important news: refocusing discussion)

[isaac jones]

On Mon, 2006-03-27 at 15:36 +0100, Simon Marlow wrote:
> On 26 March 2006 02:31, isaac jones wrote:
> 
> > Possible Interests:
> >  1. I can write tools like filesystems, web servers, and GUIs in
> > Haskell'
> >  2. Libraries that I use are thread-safe
> >  3. I can compile my code with any Haskell' compiler
> >  4. Tools such as debuggers and tracers that claim to support Haskell'
> > actually work on my code.
> >  5. That there not be "too many Haskell's"
> >  6. That there be a diversity of Haskell' implementations
> >  7. That concurrency be reasonable to implement for existing
> > compilers/interpreters.
> >  8. That it be reasonable to implement for new compilers/interpreters.
> >  9. Show off how effective Haskell can be in this area (possibly
> > attracting new users).

(snip)

> I'd count all of 1-9 as interests - they're all desirable.

Indeed they are all interests that I hold as well, some more than
others, and I think it would be helpful to know how different people
weigh different interests and why.

> But we haven't found a design that satisfies 1-9,
> and in the absence of that we have to compromise somewhere.

If a single standard were the only option, then we'd have to satisfy
some interests and not others, but if we are creative, we may find other
solutions.  Two such solutions have been proposed, one is that we use an
optional addendum and the other is that we work hard to implement
concurrency in Hugs.

So you see, it's possible that we may not have to "split the difference"
if we are creative.

Here's a story to illustrate the difference between discussing positions
(including pros & cons) and discussing interests:

> Two children are arguing over an orange. “It’s my orange!” screamed
> one of the children. “No, it’s my orange!” yelled the other. Dad
> enters the room and decides to help the children out by cutting the
> orange in half and giving a portion to each child. But, neither child
> is happy. One of the children wanted the orange peel to make
> marmalade, while the other wanted the pulp to make juice.

"It's my orange" is the position while the interests are explained by
the last sentence.

> But before we get carried away figuring out all the pros and cons of
> various options, let me point out once again that
>   
>   This is just a marketing decision

This assertion highlights a set of interests not outlined above:

10. compilers/interpreters may gain or lose popularity by declaring that
they are 100% pure haskell (of course, they will have to be Sun
certified ;)

11. Haskell itself may gain or lose popularity by "branding" itself as
being good at concurrency (well, maybe that's the same as 9).

What else are you talking abut when you say it's a marketing decision?

> Because
> 
>  (a) we're going to standardise concurrency anyway
> 
>  (b) it is unlikely that Hugs or JHC will implement concurrency
>  even if it goes into the standard
> 
>  (c) the question is just whether the "brand" Haskell' encompasses
>  concurrency or not (I thought I'd use that word because I
>  know JL likes it so much :-)
> 
> Yes there are several ramifications of this decision, but none of them
> are technical.  

Actually, interest number 5 above is somewhat technical and relates to
whether or not we make it an addendum.

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: concurrency (was Re: important news: refocusing discussion)

[isaac jones]

On Tue, 2006-03-28 at 11:05 +0100, Malcolm Wallace wrote:
(snip)
>   * IORef is inherently thread-unsafe, and so we should eliminate IORefs
> from the language.

That's not quite true, as you can have an IORef guarded by an MVar.  Why
would you want such a thing?  For instance, you might write a library
with two IORefs and one MVar instead of two MVars in order to reduce the
possibility of deadlock.

Is it the case that a library is thread-safe as long as it doesn't use
IORefs, though?  I trolled around base looking for libraries that might
not be thread-safe and found only that HashTable uses an IORef, and
indeed there's a FIXME that says it should use an MVar.  I didn't look
very hard, though.

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Re[2]: important news: refocusing discussion

[isaac jones]

On Sat, 2006-03-25 at 13:17 +0300, Bulat Ziganshin wrote:
> Hello Ross,
> 
> Saturday, March 25, 2006, 4:16:01 AM, you wrote:
> 
> > On Fri, Mar 24, 2006 at 02:47:09PM -, Simon Marlow wrote:
> >> I think it would be a mistake to relegate concurrency to an addendum; it
> >> is a central feature of the language, and in fact is one area where
> >> Haskell (strictly speaking GHC) is really beginning to demonstrate
> >> significant advantages over other languages.  We should make the most of
> >> it.
> 
> > Essential for many applications, certainly, but central?  How can you
> > say that?
> 
> it becomes central language feature just because it's much easier to
> write concurrent programs in Haskell than in other languages and
> because ghc's implementation of "user-level threads" is blazing fast,
> outperforming closest competitor in hundreds (!) times in the Language
> Shootout concurrency testing

I don't think "central to the language" is a particularly helpful
concept here.  Let's try to frame debates like this in terms of
"interests", not "positions".  That is, an interest is "we should be
able to write thread-safe libraries" and a position is "Haskell' should
have concurrency".  Once we understand each-others' interests, we can
look to find solutions that satisfy a compelling set of interests.

I'll try to frame some interests that various folks seem to have
expressed, and I admit that I may miss some and be wrong, so please add
to or correct the list below (maybe it should go on the wiki):

Possible Interests:
 1. I can write tools like filesystems, web servers, and GUIs in
Haskell'
 2. Libraries that I use are thread-safe
 3. I can compile my code with any Haskell' compiler
 4. Tools such as debuggers and tracers that claim to support Haskell'
actually work on my code.
 5. That there not be "too many Haskell's"
 6. That there be a diversity of Haskell' implementations
 7. That concurrency be reasonable to implement for existing
compilers/interpreters.
 8. That it be reasonable to implement for new compilers/interpreters.
 9. Show off how effective Haskell can be in this area (possibly
attracting new users).

By 5 I mean that it might be nice to have a "core" Haskell and a bunch
of addenda.  But this could cause no two Haskell' implementations to be
the same. (My Haskell' might have concurrency and FFI, but no class
system, or something.)  The more optional addenda we have, the more we
actually fracture the language.  We could be in the same situation we're
in today.

Isaac's Interests
 * 1-6, 9

Simon's Interests:
 * He's mentioned 9, I'm sure that there are others.

Ross and John Meacham I think have both expressed worry about 7 and 8.

I have no idea if it would work, but one solution that Simon didn't
mention in his enumeration (below) is that we could find a group of
people willing to work hard to implement concurrency in Hugs, for
example, under Ross's direction.  That might satisfy interest number 7.

Please help me to build this understanding of various folks' interests,
an solutions to satisfy them.

peace,

  isaac



Simon Marlow Wrote:
> It boils down to a choice between:
> 
>  (1) Haskell' does not include concurrency.  Concurrent programs 
>  are not Haskell'.
> 
>  (2) Haskell' includes concurrency.  Concurrent programs are
>  Haskell', but there are some compilers that do not implement
>  all of Haskell'.
> 
>  (3) There are two variants of Haskell', Haskell' and
>  Haskell'+Concurrency.  Compilers and programs choose which
>  variant of the language they implement/are implemented in.
> 
>  (4) The same as (3), but the two variants are Haskell' and
>  Haskell'-Concurrency  (where -Concurrency is a negative
>  addendum, an addendum that subtracts from the standard).

-- 
isaac jones <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: important news: refocusing discussion

[isaac jones]

On Tue, 2006-03-21 at 15:27 -0800, Ashley Yakeley wrote:
> isaac jones wrote:
> 
> > The topics that John and I feel are critical, and rather unsolved,
> > are:
> >  * The class system (MPTC Dilemma, etc)
> >  * Concurrency
> >  * (One more, perhaps standard libraries)
> 
> Could you summarise the current state of these?

AFAIK, the class system is summarized on this page:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/MultiParamTypeClassesDilemma

Although there are some proposals here that are not really covered by
that topic, they should probably be considered together:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/query?status=new&status=assigned&status=reopened&group=topic&component=Proposal&order=priority


Concurrency is summarized here:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency

and libraries have not really been discussed much at all.

peace,

  isaac

-- 
isaac jones <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

important news: refocusing discussion

[isaac jones]

Greetings,

While discussion on this mailing list has been coming fast & furious,
actual tangible progress, even as measured on the wiki, has not been as
fast. 

To remedy this, we propose to focus immediately and intently on a few of
the most critical topics, and to focus all of our energies on them until
they are done.  We'd like to go so far as to ask folks to drop
discussion on other items until these are solved.

The goal of this approach is that we will spend the most time on the
critical (and hard) stuff, instead of leaving it for last.  We know that
we can spend a _lot_ of time and energy discussing relatively small
things, and so we want to make sure that these relatively small things
don't take up all of our time.  We will tackle them later.

The topics that John and I feel are critical, and rather unsolved,
are:
 * The class system (MPTC Dilemma, etc)
 * Concurrency
 * (One more, perhaps standard libraries)

The logic here is that Haskell' will be accepted by the community  if we
solved these problems, and if we go with some of the most robust and
uncontroversial extensions already out there.

We will probably partition the committee into subcommittees to focus on
each topic.

Our goal will be to bring these topics to "beta" quality by mid April.
That is, something that we could be happy with, but that perhaps needs
some polishing.  After that, we may try to pick the next most critical
topics with the goal of having everything at "beta" quality by the
face-to-face we're hoping to have at PLDI in June.

With an eye toward considering related proposals together, we've added a
"topic" field to the wiki, and a new query to the front page which
groups the proposals by topic:

http://hackage.haskell.org/trac/haskell-prime/query?status=new&status=assigned&status=reopened&group=topic&component=Proposal&order=priority

I'd like to ask folks to please bring currently open threads to a close
and to document the consensus in tickets.  Anyone can edit tickets, so
please don't be shy.


your chairs,

  Isaac Jones
  John Launchbury

-- 
isaac jones <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

If you really care, make sure it gets on the wiki (how to create a proposal)

[isaac jones]

I'm sure you've noticed that there is a lot of traffic on this list.  I
want to emphasize that if you really care about an idea, you should make
sure it gets on the wiki in one way or another, or it may get lost in
the mass of traffic on the mailing list:
http://hackage.haskell.org/trac/haskell-prime/wiki/CreateProposal

How to create a proposal
If you have an idea:

 1. Post it to the MailingList. Use the MailingList for discussion
and to reach a consensus.
 2. If you don't have a wiki account, Log in with username guest and
password haskell' to create and edit tickets.
 3. after some discussion, create a new ticket (or modify an
existing one) to document the consensus as a proposal. See
WikiGuidelines.
 4. You may want to post the wiki page you create back to the thread
so that the thread participants can review and edit it. If you
get no support on the mailing list for an idea, please think
twice about whether or not to create a ticket for it.
 5. Watch for threads that outlive their usefulness as a discussion.
Document the disagreements on the wiki.
How to modify an existing proposal
 1. if the proposal is in a ticket, modify it directly
 2. otherwise, if you don't have write access to the wiki, discuss
your change request on the mailing list
 3. or just modify the ticket that references that wiki page,
requesting the change be made there.

peace,

  isaac
-- 
isaac jones <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: Export lists in modules

[isaac jones]

On Fri, 2006-02-24 at 12:13 +, Simon Peyton-Jones wrote:
> These days, hs-boot files are pretty close to source files, with masses
> of stuff omitted.
(snip)
> You could imagine
> a) compiling recursive groups "all at once"
> b) somehow magically filtering the source file to omit anything
> undefined, leaving only defined stuff. which ought to be enough to
> tie the knot.

FWIW, I would be thrilled to see automatic resolution of mutually
recursive modules.  When programs start to get large, this always ends
up biting me, and I have to either write & maintain the hi-boot files,
or stuff everything into one module.

Remembering how to do .hi-boot or .hs-boot files is a bit of a mental
barrier for me when I'm trying to refactor and clean up code.

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: the MPTC Dilemma (please solve)

[Isaac Jones]

I'm forwarding an email that Martin Sulzmann asked me to post on his
behalf.


From: Martin Sulzmann <[EMAIL PROTECTED]>
Subject: MPTC/FD dilemma 

Here's my take on the MPTC/FD dilemma.

There has been lots of discussion about MPTC/FDs. They are very useful
no doubt. But they also show inconsistent behavior across different
Haskell platforms (e.g. see Claus Reinke's last email).

Claus Reinke's example is "interesting" because he mixes some advanced form
of FDs with overlapping instances. Something which has never been
studied before (besides a few email exchanges between Oleg and myself
on Haskell a few months ago). So, I propose to ignore overlapping
instances for the moment.

What follows is rather lengthy. The main points of this email are:

- There's a class of MPTC/FD programs which enjoy sound, complete
  and decidable type inference. See Result 1 below. I believe that
  hugs and ghc faithfully implement this class.
  Unfortunately, for advanced type class acrobats this class of
  programs is too restrictive.

- There's a more expressive class of MPTC/FD programs which enjoy
  sound and complete type inference if we can guarantee termination
  by for example imposing a dynamic check.  See Result 2 below. Again,
  I believe that  hugs and ghc faithfully implement this class if they
  additionally implement a dynamic termination check.
  Most type class acrobats should be happy with this class I believe.

- ATs (associated types) will pose the same challenges.
  That is, type inference relies on dynamic termination checks.

Here are the details.

Let's take a look at the combination of FDs and "well-behaved" instances.
By well-behaved instances I mean instances which are non-overlapping and
terminating. From now on I will assume that instances must be well-behaved.
The (maybe) surprising observation is that the combination
of FDs and well-behaved instances easily breaks completeness and
decidability of type inference. Well, all this is well-studied.
Check out
[February 2006] Understanding Functional Dependencies via Constraint
Handling Rules by Martin Sulzmann, Gregory J. Duck, Simon Peyton-Jones
and Peter J. Stuckey
which is available via my home-page.

Here's a short summary of the results in the paper:

Result 1:
To obtain sound (we always have that), complete and decidable type inference
we need to impose
- the Basic Conditions (see Sect4)
  (we can replace the Basic Conditions by any conditions which guarantees
   that instances are well-behaved. I'm ignoring here
   super classes for simplicity)
- Jones's FD restrictions and the Bound Variable Condition (see Sect4.1)

The trouble is that these restrictions are quite "severe". In fact,
there's not much hope to improve on these results. See the discussion
in Sect5.1-5.3.

Let's take a look at a simple example to understand the gist of the problem.

Ex: Consider

class F a b | a->b
instance F a b => F [a] [b] -- (F)

Assume some program text generates the constraint F [a] a.
Type inference will improve a to [b] (because of the 
functional dependency in connection with the instance).
Though, then we'll find the constraint F [[b]] [b]
which can be resolved by the instance to F [b] b.
But this is a renamed copy of the original constraint
hence, type inference will not terminate here.

If we translate the instance and improvement conditions of
the above program to CHRs the problem becomes obvious.

rule F a b, F a c  ==> b=c-- the FD rule
rule F [a] [a]<==> F a b  -- the instance rule
rule F [a] c   ==> c=[b]  -- the improvement rule

The rules should be read from left to right where
"==>" stands for propagation and "<==>" for simplification.

My point: The above improvement rule is (potentially) dangerous
cause we introduce a fresh variable b. And that's why type inference
may not terminate. Using the terminology from the paper.
The instance (F) violates one of Jones' FD restriction (the Coverage
Condition).

So, is all lost? Not quite. A second major result in the paper says
that if we can guarantee termination then we can guarantee completeness.
Of course, we need to find some appropriate replacement for 
Jones' FD restrictions.

Result2:
Assuming we can guarantee termination, then type inference
is complete if we can satisfy
   - the Bound Variable Condition,
   - the Weak Coverage Condition, 
   - the Consistency Condition, and
   - and FDs are full.
Effectively, the above says that type inference is sound,
complete but semi-decidable. That is, we're complete
if each each inference goal terminates.

Here's a short explanation of the conditions.
The Bound Variable Condition says that all variables which appear
in the instance head must appear in the instance body.
Weak Coverage says that any of the "unbound" variables (see b
in the above example) must be captured by a FD in the instance context.
This sounds complicated but is fairly simple. Please see the p

Re: proposal for moving forward

[Isaac Jones]

Ravi Nanavati <[EMAIL PROTECTED]> writes:

(snip)
> Given the amount of excitement and interest in new extensions (and in
> doing more than a conservative standard), I see a fifth goal: come up
> with some way of helping users and implementers cope with the
> complexity of lots of different (and sometimes conflicting) extensions.

Along those lines, this ticket might be interesting:

Unify various annotation proposals:
http://hackage.haskell.org/trac/haskell-prime/ticket/91

peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Haskell' Status

[Isaac Jones]

I'll try to occasionally post an announcement of the the status of
Haskell'[1], the next Haskell standard, so that you can all be aware of
my thinking, and our current place in the timeline.

There is a list of proposals and a "strawman" categorization of them
on the wiki[2].  The categorization reflects someone's current
thinking about what's in and out, but it's really just for discussion
at this phase.

The timeline for this effort is also on the wiki[4].  You'll notice
that it's very aggressive; we plan to announce something at the next
Haskell Workshop in September.

Our current spot in the timeline is that we're meant to be
brainstorming, discussing, and refining proposals.  I've just posted
some leading questions [3] in order to focus the discussion a bit.

I can't help but notice that there is a lot of excitement (and
support?)  for a larger standard; one that would have a bigger impact.
I think that part of the Haskell' effort should be to make a plan for
moving forward.  At the very least we should have a set of
recommendations for what the community needs to work on between this
and the next standard; what are the most promising proposals and what
needs to happen to make them a reality.  I think that the wiki will be
a great resource for any future standard, and we should work to make
it as nice as possible.

Please reply to the Haskell' mailing list, and email me if you have
any questions.

peace,

  isaac


[1] Haskell' Wiki: http://hackage.haskell.org/trac/haskell-prime

[2] list of proposals and strawman categorization:
http://hackage.haskell.org/trac/haskell-prime/report/9

[3] plan for moving discussion forward
http://www.haskell.org//pipermail/haskell-prime/2006-February/000582.html

[4] The TimeLine is here.  Ascii text of the timeline follows (might
not make sense unless you use a proportional font:
http://hackage.haskell.org/trac/haskell-prime/wiki/TimeLine

 Write ReportReview
 |  | Edit|
   Discuss / Refine--|--| |
   | | || |
   brainstorm--- | || |
   |   |   | | || |
setup  |   | | || |
 | |   | | || |
---
10 | 11 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11
2005   2006
---
 |   |  |   |
 |   |  Face-To-Face?   |
 StrawmanTrial Decision Announce
@HW
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

proposal for moving forward

[Isaac Jones]

We have a fairly large list of proposals on the wiki, but in my
opinion, we need to start to discuss how they interact with
each-other, and what the "big ideas" of this standard are.  I've
identified two sets of proposals that need clarification or fixing.
These are a sort of "meta proposal" that reference a handful of other
proposals.

solve the MultiParamTypeClassDilemma:
http://hackage.haskell.org/trac/haskell-prime/ticket/90

bring together various class-related tickets into something coherent:
http://hackage.haskell.org/trac/haskell-prime/ticket/93

Can we identify more?  Here are all of the proposals:
http://hackage.haskell.org/trac/haskell-prime/report/9

The categorization of proposals at that link is a first-pass at what
might be in or out, and is just for discussion.

My intuition (and a proposal) is that our job will be to:

 1. conservatively standardize some of the most robust extensions,
 2. clean up the class hierarchies and some libraries,
 3. solve the MPTC dilemma (see above), and
 4. pick one other "big idea" such as records or bang patterns.

Thoughts?


peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Wanted: unified annotation syntax, was: Re: strict Haskell dialect

[isaac jones]

On Thu, 2006-02-02 at 09:29 +0100, Johannes Waldmann wrote:
> John Meacham wrote:
> 
> > module $hat.Foo(..) where ...
> 
> Before we invent more ad-hoc notation for annotations
> (we already have deriving, {-# .. #-}, {-! .. -!} (DrIFT) )
> can we replace all (or most) of this with a unified annotation syntax,
> e. g. Java uses "@" notation which is basically allowed
> at any declaration, and (important points) programmers can
> define their own annotations, and annotations can also have values.

The ticket for Johannes's proposal is here:
http://hackage.haskell.org/trac/haskell-prime/ticket/88

This looks to me like it's related to "specifying language extensions"
here:
http://www.haskell.org//pipermail/haskell-prime/2006-February/000335.html

Patryk, have you created a ticket for your proposal?  Could it be
implemented w/ annotations as described by Johannes?  Could the two of
you put together a specific proposal?

I've put a meta-proposal here for this question:
http://hackage.haskell.org/trac/haskell-prime/ticket/91

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

the MPTC Dilemma (please solve)

[isaac jones]

I've created a wiki page and a ticket to record solutions to what I'm
calling the "Multi Parameter Type Class Dilemma".  It's summarized
thusly:

MultiParamTypeClasses are very useful, but mostly in the context of
FunctionalDependencies. They are particularly used in the monad
transformer library found in fptools. The dilemma is that functional
dependencies are "very, very tricky" (spj). AssociatedTypes are
promising but unproven. Without a solution, Haskell' will be somewhat
obsolete before it gets off the ground.

I've proposed a few solutions.  Please help to discover more solutions
and/or put them on the ticket/wiki.  

Wiki page:
http://hackage.haskell.org/trac/haskell-prime/ticket/90

Ticket:
http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma


peace,

  isaac



-- 
isaac jones <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: objective data on use of extensions

[Isaac Jones]

Ian Lynagh <[EMAIL PROTECTED]> writes:

> On Fri, Feb 03, 2006 at 11:38:09AM -0800, Isaac Jones wrote:
>> I would like to strive to find objective data on the use of
>> extensions.  I started a table here which summarizes how popular
>> extensions are in real-life code.  We need more data points, though.
>> 
>> http://hackage.haskell.org/trac/haskell-prime/wiki/ExtensionsExperiment
>> 
>> I have a short program which queries the hackage database, gets some
>> details about all of the packages there, and summarizes them into a
>> table.
>
> I'm not sure how useful this info is, as:

There are definitely imperfections in the data, but surely the actual
data about which extensions are being used in real code is relevant.

> * You won't get, for example, FunctionalDependencies from any libraries
>   or applications that make use of Control.Monad.State.

I suppose we could try to chase down those dependencies.  If Package A
depends on Package B, and Package B uses extension X, then perhaps we
could count package A as half a point for extension X.  All the data
is there, this would be pretty easy to add.

> * Many extensions turn into -fglasgow-exts/-98, so if I use
>   functional dependencies and rank 2 types but only declare
>   FunctionalDependencies and not Rank2Types then nothing is going to
>   tell me I've made a mistake.

True enough, but I think people know when they are using extensions.
One solution would be to make sure that all extensions have their own
flag instead of so many going to -fglasgow-exts.

(snip)
> * People will sometimes be willing to jump through hoops to avoid using
>   an unportable extension.
>
>
> That said, FWIW, I have the following in my cabalised libraries (none in
> hackage AFAIK):

If you give me links, I'll upload them, or you could upload them as
per the instructions on the wiki.

peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

objective data on use of extensions

[Isaac Jones]

I would like to strive to find objective data on the use of
extensions.  I started a table here which summarizes how popular
extensions are in real-life code.  We need more data points, though.

http://hackage.haskell.org/trac/haskell-prime/wiki/ExtensionsExperiment

I have a short program which queries the hackage database, gets some
details about all of the packages there, and summarizes them into a
table.  Right now, there really aren't that many packages on
HackageDB, but hopefully more will appear.

HackageDB is here:
http://hackage.haskell.org/ModHackage/Hackage.hs?action=home

You can upload packages with Cabal-Put, but it's pretty hackish right
now.  I put detailed installation instructions on the wiki:
http://hackage.haskell.org/trac/hackage/wiki/CabalPut

A list of cabal packages that might be good for uploading is here:
http://hackage.haskell.org/trac/hackage/wiki/CabalPackages

The more packages we get into HackageDB, the more accurate objective
data we can build.  Let me know if you want to help!


peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: MPTCs and functional dependencies

[Isaac Jones]

Henrik Nilsson <[EMAIL PROTECTED]> writes:

> Dear all,
>
> John Mecham wrote:
>
>> Yeah, I have been coming to the same conclusion myself. it pains me a
>> lot. (monad transformers! I need thee!) but its not like fundeps will
>> go away, they will just still be experimental so it isn't the end of
>> the world.
>
> But isn't the whole point of Haskell' to standardise those features
> that are agreed to be necessary for writing real-world
> applications and libraries in a reasonable way?
>
> My concern is not that I fear not being able to compile my programs
> after Haskell' is done. I'm worried about too much code not being
> Haskell' compliant in the end, and, worse, too many people deciding
> that they still have to rely on extensions beyond Haskell' for writing
> "real" applications and libraries.

I am very concerned about this as well.  In most of my production
code, I avoid extensions, but MPTC and functional dependencies are two
that I have not been able to avoid.  Any time I use the class system,
I use MPTC, anytime I use MPTC, I use fundeps.

The trouble with "blessing" fundeps is that they might not pan out in
the end, and it would be a shame to add them to Haskell' and then
remove them again for Haskell'' (if there were such a thing) in favor
of associated types, for instance.

How do we solve this dilemma?  Some proposals that have come up:

 - Simon has proposed that we examine a limited version of functional
   dependencies.

 - Another option, though a scary one at this point, is to look
   closely at associated types.

 - Another option is to punt; we declare them as an extension and
   figure out a way to "bless" extensions (beyond Cabal, I guess).

 - Any others?

Can someone put together a wiki page these choices with trade-offs?
Ravi, Manuel?

peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Priorities

[isaac jones]

On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote:
> For the last few days, my mail-box has been full of mail about the M-R, 
> lazy pattern
> matching, n+k patterns, comment syntax--it's just like the good old 
> days! And that
> worries me.
> 
> Each of these topics is a snake pit--a tricky area of language design, 
> with many
> alternative possibilities and no clear winner. As such, they make great 
> discussion
> topics--if you want to start a heated argument, just propose a change to 
> one of
> these (mea culpa)! We've also been discussing most of them for sixteen 
> years.
(snip)

I hope that we can avoid rehashing discussion where possible.  That
means going out and looking for objective information and putting it on
the wiki for everyone to see.  That means making ourselves aware (if we
aren't already) of past discussions.

I hope that those who were around "in the good old days" will
consistently interrupt threads with "we had this discussion on march
10th 1994 and here's what we came up with. I put the summary up on the
wiki along with links to two papers".

That's everyone's job, but especially the committee :)

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

end of this thread? (was: Comment Syntax)

[isaac jones]

I think this thread has outlived its usefulness.  I ask the participants
to please take the time to summarize the pros & cons on the wiki, or in
this ticket if you don't have access to the wiki:

http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/ticket/42

Most of the discussion lately has just been back-and-forth reiterating
positions.  I don't think that further discussion is going to generate
more objective facts.  Let's get the objective facts on the table
(ticket) and look at it with everything else. 

peace,

  isaac


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: ~ patterns

[isaac jones]

On Tue, 2006-01-31 at 16:47 -0800, John Meacham wrote:
> On Wed, Feb 01, 2006 at 11:32:28AM +1100, Patryk Zadarnowski wrote:
> > On 31/01/2006, at 9:31 PM, Simon Marlow wrote:
> > 
> > >We must find *something* to throw away though! :-)
> > 
> > One small issue that I'd love to see thrown away is the special  
> > handling the the unary "-"
> > operator in Haskell 98. It's been described as "embarrassing",  
> > "ugly", and even "inconvenient"
> > I, for one, find myself creating sections of the form `+ (-x)` all  
> > the time, and it feels wrong.
> > What do people think?
> 
> yeah, I really want to see this change too. I think it would be a whole
> lot nicer. plus, a syntax highlighting editor would be able to determine
> the difference between - used as an operator and - used as part of a
> number.

Would one of you make sure that these pros & cons are reflected in this
ticket or the linked wiki page:
http://hackage.haskell.org/trac/haskell-prime/ticket/50

peace,

  isaac

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: what's the goal of haskell-prime?

[Isaac Jones]

"Claus Reinke" <[EMAIL PROTECTED]> writes:

>> No language can serve all of the people all of the time, but I think
>> we should just do our best with a single standard.  I think that the
>> complexity of multiple languages / layers / standards would not be
>> worth the payoff.
>
> My original understanding of the Haskell' effort was that it was *not*
> intended as going for "Haskell 2", but rather as an update of Haskell 98.

I agree with what Simon PJ said on this subject in his followup.  We
will "flirt with" some largeish changes, though it's unclear whether
or not we will adopt any.  There's some chance we might adopt one or
two; we just want to take it on a case-by-case basis.

Perhaps some would like the discussion itself narrowed to
tried-and-true features, but I'm hesitant to make such a mandate.  I
think it's healthy to put up with wide-ranging discussion, especially
now.  It would be a shame if we missed some opportunities here because
we came in with too many preconceived notions.

Hopefully we can bring threads to a close with some consensus on the
wiki, and we can look at all of the proposals together objectively.

> In other words, the target is Haskell 2005:

I like calling it Haskell' for now because the other names have too
much baggage.  Maybe when it's done, or when we make the first
proposal, it'll be called Haskell06 or what-have-you.

> - anything that was tried and tested by the end of 2005 is a potential
>candidate for inclusion in Haskell 2005. nothing else is.
>
> this would necessarily exclude much of the discussion here, for which
> I'd see only three ways out:

I don't see anything wrong with discussion.  The only downside is that
there's a lot of email, but I'm used to it.  Hopefully if there are
any nuggets of gold in those big threads, someone will find them and
put them on the wiki.  The committee should _actively_ be mining for
such nuggets.

I'm going to try to close down big threads after a while with a
summary on the wiki.

>- make an exception to rule one (bad, but occasionally needed)
>- ignore and leave for Haskell 2, whenever that might be (impractical)
>- standardise as an optional addendum to Haskell 2005, to lay the
>groundwork for Haskell 2010, and to narrow down on the more
>successful experiments (good, avoid adhoc Haskell 2 in favour
> of incremental approximations)

Another advantage to putting things on the wiki is that they'll be
documented for any Haskell-prime-prime to choose from.

(snip)
> btw, I'd find it hard to track discussion on a wiki/ticket system alone.

Yeah, the wiki is definitely not for discussion.

> Could a member of the committee arrange for a Haskell'-weekly
> message, please (similar to Haskell weekly, but collecting news
> headers and links from haskell', wiki, track, and internal committee
> discussions)?

It would be _great_ if someone on the committee, or anyone for that
matter, would summarize the discussion weekly.  Perhaps Donald will do
that as part of Haskell Weekly News, but I'm sure he'd be glad to have
some help.

Any volunteers?


peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: what's the goal of haskell-prime?

[Isaac Jones]

jur <[EMAIL PROTECTED]> writes:

> On Jan 25, 2006, at 9:37 AM, Johannes Waldmann wrote:
>
>> Dear all, in the "mission statement" I read
>>
>>>   We will strive to only include tried-and-true language features,
>>
>> but the current discussion seems to have a wider focus,
>> i. e. it is more of a wish list. Indeed I think that this is a good
>> idea (ask (future) Haskell users what they want)
>> but it might not be the original goal of the Haskell-Prime effort.
>
> Hello,
>
> I have been on this mailing list since yesterday, so maybe this
> has been addressed before.
>
> My first question is: who are the future users of Haskell?
>
> For instance: is this group homogenuous enough to define a single
> standard, or would it be advisable to define various layers in the
> language.

No language can serve all of the people all of the time, but I think
we should just do our best with a single standard.  I think that the
complexity of multiple languages / layers / standards would not be
worth the payoff.

> A compiler may then choose to support up to and including a number
> of layers.  I can imagine a compiler for students to learn
> functional programming with to have seriously different demands from
> the compiler used by researchers to do programming language
> research. I am usually not happy with the fact that novice
> programmers pay in clarity (of type error messages and diagnostics
> in general) for features they won't be using for a number of years.
> This choice can be left up the compiler builder, but I think it
> might have a place here too.

Have you looked at the Helium language / compiler?  It's a
stripped-down version of Haskell for teaching.  Maybe that's what
you're actually suggesting?  I think this is a great idea :)

peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Polymorphic record update

[Isaac Jones]

Henrik, can you please be sure this is captured on the wiki somewhere?
(Sorry, I haven't checked to see if you already did that).  Make
yourself the owner :)

peace,

  isaac


Niklas Broberg <[EMAIL PROTECTED]> writes:

> On 1/23/06, Henrik Nilsson <[EMAIL PROTECTED]> wrote:
>
> [snip lots of good stuff]
>
> This suggestion would go a long way to alleviate the burden of
> boiler-plate coding. It is a conservative extension, and it is
> intuitive at that. Indeed I believe I have written code with the
> suggested update mechanism many times without thinking on the type
> mismatch (and been beaten on my fingers by the compiler of course).
> :-)
>
>> But we'd rather not have to write such functions by hand, just as
>> we'd rather not write update functions by hand. Maybe the record
>> update syntax could be extended so that the function that gets
>> generated behind the scenes only includes constructors that
>> does NOT mention a particular field. For example, the field
>> name(s) that must not occur could be prefixed by "~" which suggests
>> negation in some settings. It does not have this connotation in Haskell,
>> but at least "~" is already a special symbol. We could then write:
>>
>> foo :: T a -> T Int
>> foo x@(C1 {}) = x {f1 = 1}
>> foo x@(C2 {}) = x {f1 = 2}
>> foo x = x {~f1}
>>
>> Now the code for "foo" only has to be changed if new constructors
>> having a field "f1" are added.
>>
>> Of course, it should be possible to combine this with the normal
>> record update syntax. E.g.
>>
>> foo :: T a -> T Int
>> foo x@(C1 {}) = x {f1 = 1}
>> foo x@(C2 {}) = x {f1 = 2}
>> foo x = x {~f1, f2 = f2 x + 1}
>
> Is this really necessary? Adding '~' seems less intuitive to me than
> just writing
>
>  foo :: T a -> T Int
>  foo x@(C1 {}) = x {f1 = 1}
>  foo x@(C2 {}) = x {f1 = 2}
>  foo x = x
>
> or
>  foo x = x {f2 = f2 x + 1}
>
> for the last example. From an implementor's point of view, if we
> expect the proper coercions to be inferred by the type checker it
> would still have to check that there are indeed no more fields than
> other than 'f1' that mention the parameter 'a', and also that there
> are no more constructors that mention 'f1'. Wouldn't it be just as
> simple to assert that for all the fields that mention 'a', none of
> these appear in any of the remaining constructors?
>
> On the other hand pattern matching would certainly be more expressive
> if '~' is added, so perhaps adding it has merit of its own. If we
> write
>
>  foo :: T a -> T Int
>  foo x@(C1 {}) = x {f1 = 1}
>  foo x@(C2 {}) = x {f1 = 2}
>  foo x = x {~f1}
>
> there could still be more constructors in T a that do mention the 'f1'
> field, but there is no matching clause for them in the definition of
> 'foo'. But I would see that as a second separate proposal, e.g. a
> Proposal for Negation in Record Pattern Matching. Sure it would fit
> very well with the Polymorphic record update discussed here, but I
> would think they should be treated separately.
>
> /Niklas
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: ~ patterns

[Isaac Jones]

Can someone be sure to capture the pros, cons, and relationship to the
!-patterns proposal as a ticket / wiki page?



peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

how to create proposals and document consensus

[Isaac Jones]

Greetings!

I've just opened up the ticket tracking system to "guest" users so
that you can all create and edit proposals and make formal requests
via the ticket tracking system.  The ticket tracking system is
attached to the wiki.

Important notes: The purpose of this is for the community at large to
be able to make requests / proposals that the committee promises to
respond to.  Stuff on the mailing list can too easily taper off
without any consensus.  Please use the ticket tracking system to
create proposals based on mailing list discussion.  The committee may
move such proposals to the wiki itself.

-= Some Guidelines =-

Use the mailing list for _discussion_ and to reach a consensus.  Use
the tickets to _document_ the consensus as a proposal.  You may want
to post the wiki page you create back to the thread so that the thread
participants can review and edit it.  If you get no support on the
mailing list for an idea, please think twice about whether or not to
create a ticket for it.

It is just fine to have conflicting points of view in a ticket, but no
back-and-forth discussion (use the mailing list for that).  Create
"pros" and "cons" sections in the ticket.  Edit the ticket rather than
adding "comments".  Link this ticket with wiki pages or other tickets
which are related, or for which this is a counter-proposal.

Be sure to set the "component" field as "Proposal" and leave the Adopt
field alone.

-= Example =-

So for instance, there's a proposal that we modify the comment syntax.
After some time for discussion on the list, Thomas (cc'd) should
create a new ticket if he still believes in his suggestion.  The
ticket should have component:proposal. The pros are that it's going to
be simpler for students, more consistent with the block comment
syntax, and easier to implement in editors.  The cons are that we lose
a group of possible operators, --> for instance, and this in turn may
cause some code to break.

Put your email address on the tickets so we know who to ask if we have
any questions.

To create a ticket, go to the wiki and log in.  The user name is guest
and the password is haskell'.  If you think you'll be doing a lot of
ticket work, email me for a guest account so that your name will
automatically appear on the changes.

Email me if you have any questions.

peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: module system/namespaces: separate with/use, allow local "use"

[Isaac Jones]

"Simon Marlow" <[EMAIL PROTECTED]> writes:

> On 30 January 2006 09:03, Simon Peyton-Jones wrote:
>
 With the module system, we should make a distinction between
 declaring 
 
 (1) that we want to use a module
 (2) how to bring the module's names into scope
>>> 
>>> Perhaps 'import' should be allowed anywhere among definitions.
>> 
>> Indeed.  Requiring the import clauses to be at the top, and the fixity
>> declarations, makes them easy to find -- but we don't require that for
>> type signatures or class declarations etc.  It'd be more consistent to
>> allow imports and fixity declarations anywhere.
>> 
>> This'd be a backward compatible change, but it's an utterly un-forced
>> one.  It's not something that people complain about much.
>
> I vaguely remember suggesting this for Haskell 98 or Haskell 1.4 (can't
> remember which) but nobody saw the need for it back then.
(snip pros & cons summary)

Can one of you add a ticket / wiki page with this summary?  I'd like
to track things like this in case they come up again.

Johannes, if you have any more specific proposals you'd like to make,
please do so on the mailing list, then add a ticket once some
consensus emerges.

peace,

  isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

an example of why users should be able to edit tickets

[Isaac Jones]

Not to beat a horse...

Here's an example of why users should be able to edit tickets.  If
Duncan could do anything with the wiki, I could ask him to bring
together the various semi-formal proposals into a ticket or three
tickets.  Then we can reasonably weigh it in with the other proposals
later on, and perhaps move it to the wiki if we're strongly
considering it.

No one has replied to Duncan in 2 days, but is it actually the case
that no one believes these ideas should be considered further?  Since
I am committed to taking input from the community, I want to be able
to watch whether or not these threads get to a conclusion.  I don't
want to use my email reader for this; they're open loops that I want
to track in a ticket system.

peace,

  isaac


--- Begin Message ---
On Mon, 2006-01-23 at 19:54 +0100, Sebastian Sylvan wrote:
> On 1/23/06, Duncan Coutts <[EMAIL PROTECTED]> wrote:

> > Basically what I want is an extension which allows me to write:
> >
> > > import Graphics.UI.Gtk
> > and then use
> > > ... Button.label ...
> >
> 
> There seems to be a suggestion already which would solve this:
> http://hackage.haskell.org/trac/haskell-prime/wiki/ModuleSystem
> 
> Basically put:
> qualified module GTK.Button as Button
> 
> In the export list.

Yes this was one of the semi-formal proposals that got suggested. I'm
not sure we came to a final conclusion about what the extension exactly
meant. It would definitely be a good place to start the discussion in
the context of the Haskell' process.

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

--- End Message ---
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

forwarded message on the importance of libraries

[Isaac Jones]

Garry Hodgson writes:

"Isaac Jones" <[EMAIL PROTECTED]> wrote:

> Haskell' will be a conservative refinement of Haskell 98. It will
> be the work of this committee to adopt a set of language
> extensions and modifications and to standardize *a new set of
> libraries.* [emphasis mine]

excellent.  just please please please don't give short shrift to the libraries,
as this is what will make or break any effort to make haskell more
useful to the development community at large.

have a look at the set of libraries that come with python to get
an idea of a useful starting point.  i recognize that libs are not
academically sexy, and that this would require a great amount
of resources.  but starting with the notion that haskell should have
an equivalent set, and then giving ground where necessary, would
be far better than assuming a minimal set that users will augment.
because they won't.  they'll just use python.

> This standard will reflect the realities of developing
> practical applications in the Haskell language.

excellent.  play close attention to the "out of the box" experience.
if i can install it, run the examples, maybe have some useful
command among them, i'm far more likely to invest the effort
to go further.  make sure it plays well with others.  if i can write
code that i can use alongside my other code in other languages,
integrate into my build system, and distribute in running form
without requiring handstands from my users, i'm far more likely
to use it for actual work.

there's a threshold of effort required to adopt any new language.
the lower you can make that threshold, the more people will take
that first step.

note:  please don't anyone take this as a python flame, or an
invitation to start one.  i love python.  i love haskell.  i use python
on a daily basis because i can get stuff done with it.


Garry Hodgson, Technical Consultant, AT&T Labs
___
Haskell-prime mailing list
[EMAIL PROTECTED]
http://haskell.org/mailman/listinfo/haskell-prime

Re: Numeric class lattice reworking?

[isaac jones]

Sorry your mail didn't get through right away.  Don't worry, the list
isn't moderated; I had to tweak a setting for new subscribers.  No more
messages should get held up.

Thanks for your post.  John Launchbury is interested in reworking the
Num hierarchy, so you might ping him.  There's a vague mention of it
here:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Prelude

and here:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/ticket/58

The above is a proposal for a proposal.  We don't even have an informal
proposal as of yet.

Does anyone want to make an informal proposal?

peace,

  isaac


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