Those on the Haskell' mailing list may have seen recent signs of
activity on the Haskell' front. I thought I should clarify the current
status, and update the community on our plans for Haskell'.
The main sticking point in the design of Haskell' has been the type
system: namely whether Haskell'
Simon Marlow wrote:
Subject: DRAFT: Haskell' status update
of course, that shouldn't have said "DRAFT".
Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Folks,
Please comment on the following proposed change to qualified operator
syntax:
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.h
Mon Apr 21 11:30:40 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* add wiki link for ArrayIndexing
M ./status.hs -1 +1
View patch online:
http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080421183040-8214f-02ff20c870f45e474bf91dc581b45e3a20e6bea7.gz
_
John Meacham wrote:
On Fri, Apr 18, 2008 at 08:36:42AM +0100, Simon Peyton-Jones wrote:
Not allowing infix functions on the LHS would be a notable
simplification. Constructors in patterns should still be infix of
course: f (a :=: b) = ...
I don't know, I think this will confuse things, especi
I tried to see the discussion that led to class aliases being rejected
as a proposal, but could not find links on the Wiki. In fact, in Trac
(#101) that proposal is still a 'maybe', but with no updates. Is there
a competing proposal that got accepted?
[Without a mechanism like class aliases,
Would it not be cleaner just to disallow infix notation of qualified
operators altogether? It is clear enough to use "import qualified" or
let or where clauses containing prefix notation to identify a qualified
operator with an unqualified one:
UGLY:
m `Prelude.(>>=)` a
`Prelude.(>>=)` b
> Please comment on the following proposed change to qualified operator
> syntax:
>
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
I like this change. It'll break a bit of my code, but I think it's worth
it. The point of having infix operators is to write natural looking
co
I would guess that the reason is that it hasn't been implemented yet...
...still it does seem to be a real shame if nothing in this area can
make it into Haskell' (and it's not just Num Monad
inheriting from Functor etc)
...it's a lot less sexy than something like TF, but I think
> Incedentally I think we should use a different operator for array
> indexing, because ! is almost universally used to mean "strict"
> now: in bang patterns, strict datatype fields, and $!. See
> http://hackage.haskell.org/trac/haskell-prime/wiki/ArrayIndexing
A lot of the discussion on that
Sittampalam, Ganesh wrote:
Incedentally I think we should use a different operator for array
indexing, because ! is almost universally used to mean "strict"
now: in bang patterns, strict datatype fields, and $!. See
http://hackage.haskell.org/trac/haskell-prime/wiki/ArrayIndexing
A lot of
Jacques Carette wrote:
I tried to see the discussion that led to class aliases being rejected
as a proposal, but could not find links on the Wiki. In fact, in Trac
(#101) that proposal is still a 'maybe', but with no updates. Is there
a competing proposal that got accepted?
[Without a mecha
Dan Weston wrote:
Would it not be cleaner just to disallow infix notation of qualified
operators altogether? It is clear enough to use "import qualified" or
let or where clauses containing prefix notation to identify a qualified
operator with an unqualified one:
UGLY:
m `Prelude.(>>=)` a
`
On Mon, Apr 21, 2008 at 01:36:33PM -0700, Simon Marlow wrote:
> 0. do nothing
> 1. use a Unicode operator for composition
> 2. require spaces around . as an operator
> 3. require spaces around all operators
> 4. use another ASCII operator for composition, e.g. <<<
>
> Nothing has been decided yet,
14 matches
Mail list logo
