Hello J.,
Thursday, February 1, 2007, 1:36:33 AM, you wrote:
Yes - you've reiterated Wadler's original design, with an automatic
problems with equational reasoning raised by this approach.
ok, i can live without it. i mean reasoning :)
i guess that anything more complex than Turing machine
Bulat Ziganshin
[EMAIL PROTECTED]
writes:
Yes - you've reiterated Wadler's original design, with
an automatic problems with equational reasoning raised
by this approach.
ok, i can live without it. i mean reasoning :)
That's probably not good, but I don't follow that problem
yet. I'm
On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote:
Wednesday, January 31, 2007, 7:12:05 PM, you wrote:
data Coord = Coord Float Float
view of Coord = Polar Float Float where
Polar r d= Coord (r*d) (r+d)-- construction
Coord x y | x/=0 || y/=0
On Thu, Feb 01, 2007 at 09:12:02AM -0800, David Roundy wrote:
On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote:
Next, i don't think that ability to use any functions in view buy
something important. pattern guards can be used for arbitrary
functions, or such function can be
Hello Simon,
Monday, January 22, 2007, 5:57:27 PM, you wrote:
adding view patterns to Haskell.
many of us was attracted to Haskell because it has clear and simple
syntax. but many Hugs/GHC extensions done by independent developers
differ in the syntax they used, because these developers either
On Wed, Jan 31, 2007 at 05:53:08PM +0300, Bulat Ziganshin wrote:
something like this:
data Coord = Coord Float Float
view of Coord = Polar Float Float where
Polar r d= Coord (r*d) (r+d)-- construction
Coord x y | x/=0 || y/=0 = Polar (x*y) (x+y)--
Hello David,
Wednesday, January 31, 2007, 7:12:05 PM, you wrote:
data Coord = Coord Float Float
view of Coord = Polar Float Float where
Polar r d= Coord (r*d) (r+d)-- construction
Coord x y | x/=0 || y/=0 = Polar (x*y) (x+y)-- matching
This is
On 1/31/07, Bulat Ziganshin [EMAIL PROTECTED] wrote:
snip
i hope that now my idea is clear
Yes - you've reiterated Wadler's original design, with an automatic
creation of a type class. Erwig and Peyton-Jones, _Pattern Guards and
Transformational Patterns_
On Jan 26, 2007, at 6:22 PM, Claus Reinke wrote:
2) There are other reasons why I want to use Haskell-98 and
would like to be able to use other compilers. Thus, I'd want a
pattern-binder preprocessor (extending GHC is not as important to
me).
I see. though I'd hope that as long as we
mapA f (nilAP - ()) = nilA
mapA f (consAP - (h,t)) = consA (f h) (mapA f t)
foldA f n (nilAP - ())= n
foldA f n (consAP - (h,t)) = f h (foldA f n t)
yes, maps and folds are likely to be parts of the ADT interface, rather than
defined on top of it. I just used them as
the alternative I'm aiming for, as exhibited in the consP example, would be
to build patterns systematically from view patterns used as abstract
de-constructors, composed in the same way as one would compose the
abstract constructors to build the abstract data structure.
This would cause an
| In my opinion, views are going to make more Haskell more complicated, and
| from what I have seen so far, for little gain.
|
| We need some kind of pattern extension *now* for bytestring
| matching/views and bit parsing, though. Stuff that's used in large, real
| world Haskell programs :)
2) There are other reasons why I want to use Haskell-98 and would
like to be able to use other compilers. Thus, I'd want a pattern-binder
preprocessor (extending GHC is not as important to me).
I see. though I'd hope that as long as we keep our extensions simple and
general enough, the
| First, I'm not clear what Simon meant by first class abstractions
| in this comment
|
| Several proposals suggest first class abstractions rather that
| first-class patterns. Here are the ones I know of ...
Sorry to have been un-clear. By a first class abstraction I mean a value of
type
| is that clearer?
yes, thanks. I'm not quite sure whether it all means you think view patterns
are good; or that they would be good with a tweak; or that something else would
be better.
Do feel free to edit the wiki to articulate any design alternatives that you
think deserve consideration.
I'm not quite sure whether it all means you think view patterns are good; or that
they would be good with a tweak; or that something else would be better.
probably because my opinion has been changing;-) at first, I wasn't convinced,
now I think it depends on the details. as Mark said, such
Strangely, for other reasons, I'm planning, within a week or so, to
start implementing the pattern-binder syntax I discussed in the paper
(either in GHC or as a pre-processor).
I'm somewhat surprised to read this. Between view patterns, lambda-match,
and Control.Monad.Match, I thought we were
On Jan 25, 2007, at 3:49 AM, Claus Reinke wrote:
but as far as Haskell is concerned, I am perhaps less radical in my
approach than Mark is: Haskellers have invested an awful lot of
work in those conventional patterns, in readibility, in
optimisations, and in linking them with other
Rene_de_Visser:
In my opinion, views are going to make more Haskell more complicated, and
from what I have seen so far, for little gain.
We need some kind of pattern extension *now* for bytestring
matching/views and bit parsing, though. Stuff that's used in large, real
world Haskell programs
On 1/24/07, Brian Hulley [EMAIL PROTECTED] wrote:
A possible syntax could represent the
value being matched explicitly, say using ? to represent the value
currently
being matched, then the pattern could be written as an equation:
f (prodSize ? = Small) = ...
f (prodSize ? = Medium) =
-- abstract list deconstructors / list pattern constructors
-- (consP takes h/t sub-patterns as parameters)
consP h t l = do { guard $ not (null l); hr - h (head l); tr - t (tail l);
return (hr,tr) }
nilP l = do { guard $ null l; return () }
-- wildcard and variable patterns
In my opinion, views are going to make more Haskell more complicated, and
from what I have seen so far, for little gain.
Maybe a poll should be made to see what features the average Haskeller feels
the most in need of. Or what their greatest problems are.
Going by the traffic over the previous
| 1 I am a bit concerned about the use of non-linear patterns in your examples.
| There are good arguments for non-linear patterns, and Haskellers have
made good
| arguments against non-linear patterns. But you seem to suggest allowing
non-linear
| patterns in some cases (related to
On Wed, 24 Jan 2007, Claus Reinke wrote:
the alternative I'm aiming for, as exhibited in the consP example, would be
to build patterns systematically from view patterns used as abstract
de-constructors, composed in the same way as one would compose the
abstract constructors to build the
On Jan 22, 2007, at 6:57 AM, Simon Peyton-Jones wrote:
I'm thinking of implementing it in GHC, so I'd be interested in
feedback of the form
- how desirable is it to have a feature of this general form?
While it looks like a useful extension with a lot of bang for the buck,
I think
[Redirecting to haskell-prime]
| In the related work, the Active Patterns proposal by Palao et at is missing:
|
| http://portal.acm.org/citation.cfm?id=232641coll=portaldl=ACM
|
| I thought this work should be included in the list because, I believe,
| they were the first to point out that
http://hackage.haskell.org/trac/haskell-prime/wiki/ViewPatterns
I'm thinking of implementing it in GHC, so I'd be interested in feedback of the
form
- how desirable is it to have a feature of this general form?
- can this particular proposal be improved?
IMHO, getting a
Simon Peyton-Jones wrote:
http://hackage.haskell.org/trac/haskell-prime/wiki/ViewPatterns
I'm thinking of implementing it in GHC, so I'd be interested in
feedback of the form
- how desirable is it to have a feature of this general form?
- can this particular proposal be
28 matches
Mail list logo
