2013/5/15 7stud 7s...@excite.com
The first solution works for infinite lists and the second one does not.
I don't see how that's possible. Both traversals seem to be limited by
n, and therefore they do not have to touch the end of the list. In any
case, it would seem to me that the *first*
Well, my question does not meet the standards for a question at stackoverflow:
(I am a haskell beginner)
This example is from LYAH:
import System.Random
finiteRandoms :: (RandomGen g, Random a, Num n) = n - g - ([a], g)
finiteRandoms 0 gen = ([], gen)
finiteRandoms n gen =
On Wed, 15 May 2013, 7stud wrote:
Well, my question does not meet the standards for a question at stackoverflow:
(I am a haskell beginner)
Then you might want to post your question to haskell-beginners mailing
list.
Is one solution more efficient than the other? I believe my solution is
Is one solution more efficient than the other? I believe my solution is
tail recursive, but it's my understanding that compilers can now
optimize just about anything into tail recursion.
The first solution works for infinite lists and the second one does not.
I don't see how that's
At Fri, 1 Jul 2011 09:39:32 +0400,
Eugene Kirpichov wrote:
Hi,
I'm rewriting timeplot to avoid holding the whole input in memory, and
naturally a problem arises:
How to represent large but finite streams and functions that process
them, returning other streams or some kinds of aggregate
Eugene Kirpichov wrote:
I'm rewriting timeplot to avoid holding the whole input in memory, and
naturally a problem arises:
How to represent large but finite streams and functions that process
them, returning other streams or some kinds of aggregate values?
Examples:
* Adjacent differences of
Plain old lazy lists do not allow me to combine multiple concurrent
computations, e.g. I cannot define average from sum and length.
2011/7/1 Heinrich Apfelmus apfel...@quantentunnel.de:
Eugene Kirpichov wrote:
I'm rewriting timeplot to avoid holding the whole input in memory, and
naturally a
Sure you can.
runningAverage :: Int - [Double] - [Double]
runningAverage n xs = let chunk = take n xs
in (sum chunk / length chunk) : runningAverage (tail xs)
Lazy lists are absolutely ideal for this purpose.
Regards,
Malcolm
On 1 Jul 2011, at 07:33, Eugene Kirpichov
I meant the average of the whole list - given a sumS and lengthS (S
for Stream), write meanS as something like liftS2 (/) sumS lengthS.
Or is that possible with lazy lists too?
(looks like arrows actually - which arrow is appropriate here?)
2011/7/1 Malcolm Wallace malcolm.wall...@me.com:
Sure
On Fri, Jul 1, 2011 at 12:21 PM, Eugene Kirpichov ekirpic...@gmail.com wrote:
I meant the average of the whole list - given a sumS and lengthS (S
for Stream), write meanS as something like liftS2 (/) sumS lengthS.
Or is that possible with lazy lists too?
Sure you can. Sum, length and mean
Alexey, your definition of mean does not look like liftS2 (/) sum
length - you have to manually fuse these computations.
I'm asking for a formalism that does this fusion automatically (and
guaranteedly).
2011/7/1 Alexey Khudyakov alexey.sklad...@gmail.com:
On Fri, Jul 1, 2011 at 12:21 PM,
On Fri, Jul 1, 2011 at 12:54 PM, Eugene Kirpichov ekirpic...@gmail.com wrote:
Alexey, your definition of mean does not look like liftS2 (/) sum
length - you have to manually fuse these computations.
Well it was fused for numerical stability
I'm asking for a formalism that does this fusion
Eugene Kirpichov wrote:
Plain old lazy lists do not allow me to combine multiple concurrent
computations, e.g. I cannot define average from sum and length.
I meant the average of the whole list - given a sumS and lengthS (S
for Stream), write meanS as something like liftS2 (/) sumS lengthS.
Thanks but I'm afraid that's still not quite what I'm looking for;
guess I'll have to define my desire by my implementation - so once
it's ready I'll show the result to cafe :)
2011/7/1 Alexey Khudyakov alexey.sklad...@gmail.com:
On Fri, Jul 1, 2011 at 12:54 PM, Eugene Kirpichov
From: Eugene Kirpichov ekirpic...@gmail.com
Subject: [Haskell-cafe] Patterns for processing large but finite
streams
To: Haskell Cafe haskell-cafe@haskell.org
Message-ID: banlktikdsvq2wv4wjr+qmuvksoav0kt...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I'm
After the list discussion, I'm surprised nobody mentioned Max Rabkin/Conal
Elliott's blog posts on folds and zips.
http://squing.blogspot.com/2008/11/beautiful-folding.html
http://conal.net/blog/posts/enhancing-a-zip/
They develop a formalism for zipping functions on lists.
Iteratee's `zip` set
Hi,
You're right, reifying stream processing functions seems indeed the
way to go - and that looks even more like arrows :)
I thought of something like this:
data SP i o = Yield [o] (Maybe (Maybe i - SP i o))
Scalar functions like sum and length are just SP's that return a
single item in the
Eugene Kirpichov ekirpic...@gmail.com writes:
2011/7/1 Heinrich Apfelmus apfel...@quantentunnel.de:
Eugene Kirpichov wrote:
I'm rewriting timeplot to avoid holding the whole input in memory, and
naturally a problem arises:
Plain old lazy lists?
Heretic! :-)
I generally have written a
This sound exactly like what attribute grammars, like the system
developed at Utrecht University [1], are useful for.
Erik
[1] http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem
On Fri, Jul 1, 2011 at 10:54, Eugene Kirpichov ekirpic...@gmail.com wrote:
Alexey, your definition of mean does not
Hi,
I'm rewriting timeplot to avoid holding the whole input in memory, and
naturally a problem arises:
How to represent large but finite streams and functions that process
them, returning other streams or some kinds of aggregate values?
Examples:
* Adjacent differences of a stream of numbers
*
Hi,
When I compile this code, ghc complains about some overlapped patterns in
function depth. What on Earth is ghc talking about? O:-)
data BinTree a = EmptyTree
| NodeBT a (BinTree a) (BinTree a)
deriving Show
emptyBT = EmptyTree
depth emptyBT = 0
On Jan 13, 2008, at 13:59 , Fernando Rodriguez wrote:
When I compile this code, ghc complains about some overlapped
patterns in function depth. What on Earth is ghc talking about? O:-)
emptyBT = EmptyTree
depth emptyBT = 0
depth (NodeBT _ left right) = max (1 + depth left) (1 + depth
Fernando Rodriguez writes:
What on Earth is ghc talking about? O:-) (overlapping paterns)
emptyBT = EmptyTree
depth emptyBT = 0
depth (NodeBT _ left right) = max (1 + depth left) (1 + depth right)
GHC is always right...
Your first clause is GENERIC,
: 18 November 2007 22:47
To: Derek Elkins
Cc: Haskell users
Subject: Re: [Haskell] Bang patterns and declaration order
I totally agree with Derek. Which exception you get can vary with compiler
version, compiler flags, time of day, phase of the moon, ...
It will be one in a set of exceptions
Hello,
I was playing around with bang patterns and I noticed that
when combined with asynchronous exceptions they can lead to
programs where the order of the declarations in a binding
group is important! Here is an example:
import Control.Exception
import Prelude hiding (catch)
main =
On Nov 18, 2007 6:11 PM, Iavor Diatchki [EMAIL PROTECTED] wrote:
I was playing around with bang patterns and I noticed that
when combined with asynchronous exceptions they can lead to
programs where the order of the declarations in a binding
group is important!
I think that's why they may be
On Sun, 2007-11-18 at 12:11 -0800, Iavor Diatchki wrote:
Hello,
I was playing around with bang patterns and I noticed that
when combined with asynchronous exceptions they can lead to
programs where the order of the declarations in a binding
group is important! Here is an example:
I totally agree with Derek. Which exception you get can vary with compiler
version, compiler flags, time of day, phase of the moon, ...
It will be one in a set of exceptions, but you don't know which one.
-- Lennart
On Nov 18, 2007 8:34 PM, Derek Elkins [EMAIL PROTECTED] wrote:
On Sun,
Discussion continues below quoted text...
Stefan O'Rear wrote:
On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy wrote:
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
ChrisK [EMAIL PROTECTED] writes:
And the readability is destroyed because you cannot do any type
David Roundy [EMAIL PROTECTED] writes:
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
[snippage] This is all very horrid, but as far as I can tell
what I was proposing wouldn't lead to such a mess, except
possibly via defaulting, which, as the least important
aspect of
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
ChrisK [EMAIL PROTECTED] writes:
And the readability is destroyed because you cannot do any type inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little
On Tue, Jul 31, 2007 at 04:04:17PM -0700, Stefan O'Rear wrote:
On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy wrote:
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
ChrisK [EMAIL PROTECTED] writes:
And the readability is destroyed because you cannot do any type
With the functional dependency, you can't work with the view datatypes
at all. Once you write
type Typ
data TypView = Unit | Arrow Typ Typ
instance View Typ TypView where
view = ...
you're no longer allowed to take apart a TypView at all!
E.g. you can't write
outUnit :: TypView - Bool
On Jul30, Claus Reinke wrote:
one could turn that promise into a type-checked guarantee by using
explicit sum types (and thus structural rather than name-based typing),
but that gets awkward in plain haskell.
I don't think the choice of whether you label your variants with names
or with
ChrisK [EMAIL PROTECTED] writes:
And the readability is destroyed because you cannot do any type inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little about the possible types of y
since can only conclude that:
[snippage] This
On Mon, Jul 30, 2007 at 05:31:40AM -0400, Dan Licata wrote:
With the functional dependency, you can't work with the view datatypes
at all. Once you write
type Typ
data TypView = Unit | Arrow Typ Typ
instance View Typ TypView where
view = ...
you're no longer allowed to take apart a
And the readability is destroyed because you cannot do any type inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little about the possible types of y since can only conclude
that:
Matrix can be multiplied by one or more types 'sometype'
Some time ago I wrote to this list linking to a regular expression
engine I was writing in order to learn the Haskell programming
language. I had noted the ability to send a single functions output
into it as the its input and had tried using this property of the
language in a rather winding way
ChrisK [EMAIL PROTECTED] writes:
Jon Fairbairn wrote:
I currently only get f :: [t] - something, so if I later
discover that I need to change the input representation to
be more efficient than lists, I have to rewrite f. Wouldn't
it be so much nicer if I could simply add a declaration
On Jul26, Stefan O'Rear wrote:
So, this syntax affects a lot of code, existing or otherwise, that
doesn't use view patterns, which is something we're trying to avoid.
Eh? I *think* the typing rules are the same for the no-view case. If
the auto-deriving hack isn't implemented, you only
On Jul26, apfelmus wrote:
Yes, the types of the patterns don't unify. But each one is a
specialization of the argument type. Note that the type signature is
bar :: (forall a . ViewInt a = a) - String
which is very different from
bar :: forall a . ViewInt a = a - String
Without
Me:
In the dependently typed setting, it's often the case that the
with-scrutinee is an expression of interest precisely because it
occurs
in the *type* of the function being defined. Correspondingly, an
Epigram implementation should (and the Agda 2 implementation now
does)
On Friday 27 July 2007, Jon Fairbairn wrote:
ChrisK [EMAIL PROTECTED] writes:
Jon Fairbairn wrote:
I currently only get f :: [t] - something, so if I later
discover that I need to change the input representation to
be more efficient than lists, I have to rewrite f. Wouldn't
it be so
Others have already pointed this out, but it is worth saying again:
Maybe is not the only monadic effect which makes sense during
pattern-matching. Wolfram Kahl and I have explored some of these things
as part of the Pattern Matching Calculus,
http://sqrl.mcmaster.ca/~kahl/PMC/
[If you want
On Fri, Jul 27, 2007 at 09:02:42AM -0500, Jonathan Cast wrote:
On Friday 27 July 2007, Jon Fairbairn wrote:
ChrisK [EMAIL PROTECTED] writes:
Because this is starting to sound like one of the
maddening things about C++.
Namely, the automatic implicit casting conversions of
classes
On 2007-07-27, David Roundy [EMAIL PROTECTED] wrote:
The solution is to add explicit to the constructor for all single-argument
constructors (except perhaps occasionally when you actually want explicit
construction of objects).
The reasoning behind this, of course, is to allow nice
I think you should add the form:
(function - pattern) @ pattern
as well. The reason you don't need general 'pattern @ pattern' with
normal patterns is that, if anything is going to match, the two
patterns must have the same outermost constructor, so you can push
the @ inside. This doesn't
Jon Fairbairn wrote:
I currently only get f :: [t] - something, so if I later
discover that I need to change the input representation to
be more efficient than lists, I have to rewrite f. Wouldn't
it be so much nicer if I could simply add a declaration
f:: Stream s = s t - something
and get
that none of these options supports the value input feature; we
need new syntax to support non-binding identifiers in patterns!
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dan Licata wrote:
apfelmus wrote:
The idea is to introduce a new language extension, namely the ability to
pattern match a polymorphic type. For demonstration, let
class ViewInt a where
view :: Integer - a
instance ViewInt [Bool] where
view n = ... -- binary representation
Hi Dan
On 25 Jul 2007, at 15:18, Dan Licata wrote:
Hi Conor,
[..]
Why are you so fatalistic about with in Haskell?
I guess I'm just fatalistic, generally. Plausibility is not something
I'm especially talented at.
Is it harder to
implement than it looks?
For Haskell, it ought to be
Hi everyone,
Thanks for all the helpful feedback! It's great to see what people
think.
Let me just respond to one point at the moment:
I think that the signature
type Typ
unit :: Typ - Maybe ()
arrow :: Type - Maybe (Typ,Typ)
is *wrong* if what you really mean is
type Typ
I think that the signature
type Typ
unit :: Typ - Maybe ()
arrow :: Type - Maybe (Typ,Typ)
is *wrong* if what you really mean is
type Typ
data TypView = Unit | Arrow Typ Typ
view :: Typ - TypView
different =/= wrong !-)
That is, if what you mean is that every Typ is
G'day all.
Quoting Claus Reinke [EMAIL PROTECTED]:
different =/= wrong !-)
[...]
but that is not what you're saying there at all! you're saying that -within
view 'view' of Typ- Typ is mapped to either Unit or Arrow, if the mapping
is successfull. there can be other views of Typ, and the
The problem, and we've been through this before, is that it's very
tempting to use types like Maybe because it's there, when it's better
replaced with a custom algebraic data type.
i'm sure we have, and others before us. i was just arguing that one
is not necessarily better than the other. i'm
Jules Bean wrote:
Have you tried using pattern guards for views?
f s | y : ys - viewl s =
| EmptyL - viewl s =
Hm, I'd simply use a plain old case-expression here
f s = case viewl s of
y : ys - ...
EmptyL - ...
In other words, case-expressions are as powerful as
apfelmus wrote:
IMHO, the long-time debate about views is not whether they're useful (I
think they are!) but which concrete form to choose. Unfortunately, all
of the proposals so far are somehow like Dr. Jekyll and Mr. Hyde: one
side is nice but the other is rather ugly.
In the end, I might end
Hi
Ok, I'm not quite under my rock yet,,,
On 25 Jul 2007, at 10:28, apfelmus wrote:
Jules Bean wrote:
Have you tried using pattern guards for views?
f s | y : ys - viewl s =
| EmptyL - viewl s =
This is annoying because the intermediate computation gets repeated. I
don't
apfelmus wrote:
Jules Bean wrote:
Have you tried using pattern guards for views?
f s | y : ys - viewl s =
| EmptyL - viewl s =
Hm, I'd simply use a plain old case-expression here
f s = case viewl s of
y : ys - ...
EmptyL - ...
In other words,
[I think we should move the rest of this thread to haskell-cafe, since
it's getting long. Note that there have already been some responses on
both lists.]
Hi Claus,
On Jul25, Claus Reinke wrote:
I think that the signature
type Typ
unit :: Typ - Maybe ()
arrow :: Type - Maybe
Hi Dan,
No, of course not. All I meant to say is that sometimes you want a
total view, and that a total view should be given a type that says as
much. The latter says this better than the former. On the other hand,
there are lots of circumstances in which you want a partial view, and I
think
Hi Conor,
This is a really good point, especially in the presence of GADTs and
type-level functions and so on, which introduce aspects of dependency.
Why are you so fatalistic about with in Haskell? Is it harder to
implement than it looks? It seems to be roughly in the same category as
our view
Benjamin Franksen wrote:
apfelmus wrote:
In other words, case-expressions are as powerful as any view pattern may
be in the single-parameter + no-nesting case.
This is how I do it, no pattern guards, no view patterns:
zip :: Seq a - Seq b - Seq (a,b)
zip xs ys = case (viewl xs,viewl ys)
Simon Marlow [EMAIL PROTECTED] writes:
Dan Licata wrote:
Simon PJ and I are implementing view patterns, a way of
pattern matching against abstract datatypes, in GHC.
At the risk of being a spoil-sport, I have a somewhat
negative take on view patterns. Not because I think they're
On Jul25, apfelmus wrote:
The point is to be
able to define both zip and pairs with one and the same operator : .
There's actually a quite simple way of doing this. You make the view
type polymorphic, but not in the way you did:
type Queue elt
empty :: Queue elt
cons :: elt -
On Wednesday 25 July 2007, Jon Fairbairn wrote:
Simon Marlow [EMAIL PROTECTED] writes:
Dan Licata wrote:
Simon PJ and I are implementing view patterns, a way of
pattern matching against abstract datatypes, in GHC.
At the risk of being a spoil-sport, I have a somewhat
negative take
On Wed, 2007-07-25 at 14:12 +0200, Benjamin Franksen wrote:
Cheers
Ben, member of the we-want-real-views-or-nothing-at-all movement ;-)
Derek, member of the counter-culture,
we-don't-want-real-views-but-nothing-at-all-may-suffice movement.
___
Dan Licata wrote:
On Jul25, apfelmus wrote:
The point is to be
able to define both zip and pairs with one and the same operator : .
There's actually a quite simple way of doing this. You make the view
type polymorphic, but not in the way you did:
type Queue elt
empty :: Queue
On Wed, Jul 25, 2007 at 09:35:32PM +0200, apfelmus wrote:
Integer
= (forall a . ViewInt a = a)
can even be done implicitly and for all types. Together with the magic
class View, this would give real views.
Jón Fairbairn wrote:
It's essential to this idea that it doesn't involve
Dan Licata wrote:
There's actually a quite simple way of doing this. You make the view
type polymorphic, but not in the way you did:
myzip :: Queue a - Queue b - Queue (a,b)
myzip a b = case (view a, view b) of
(EmptyL, _) - empty
(_, EmptyL) - empty
On Jul25, Benjamin Franksen wrote:
Dan Licata wrote:
On Jul25, apfelmus wrote:
The point is to be
able to define both zip and pairs with one and the same operator : .
There's actually a quite simple way of doing this. You make the view
type polymorphic, but not in the way you
though I'm extremely dubious about the utility of the Maybe patterns.
actually, they are the main thing that interests me about view patterns!-)
it connects them to the existing work on first-class patterns (where
combinators over Maybe patterns do the matching work, and view
patterns
Dear Haskellers,
why is so difficult to define a function to compute the average of a
list of
numbers??
Warm regards!!!
Man
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
didn't read the other proposals.
Kind regards
Andreas
- Original Message -
From: Dan Licata [EMAIL PROTECTED]
To: haskell@haskell.org
Sent: Monday, July 23, 2007 11:09 AM
Subject: [Haskell] View patterns in GHC: Request for feedback
Hi everyone,
Simon PJ and I are implementing view
| At the risk of being a spoil-sport, I have a somewhat negative take on
| view patterns. Not because I think they're particularly bad, but
| because I don't think they're significantly useful enough to warrant
| adding to the language, at least if we also have pattern guards.
Syntactic sugar is
Simon Peyton-Jones wrote:
Views have been the subject of rather inconclusive debate for a long time,
certainly since the inception of Haskell. I'm thinking of pattern
views as a way
to break the logjam by implementing something that is a reasonable stab,
and seeing whether it sticks. I thought
Hi everyone,
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any comments or suggestions about this design, we'd love to
hear them. You
On Mon, Jul 23, 2007 at 05:09:01AM -0400, Dan Licata wrote:
Hi everyone,
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any
G'day all.
On Mon, Jul 23, 2007 at 05:09:01AM -0400, Dan Licata wrote:
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
I have to agree. Great
Dan Licata wrote:
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any comments or suggestions about this design, we'd love to
hear
On Monday 23 July 2007 16:57:08 Simon Marlow wrote:
Dan Licata wrote:
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any
to have ByteStrings or Data.Sequence pattern matched
like ordinary lists and I think that Data.Graph will blossom with proper
view patterns.
Regards,
apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any comments or suggestions about this design, we'd love to
hear them. You can
On Monday 23 July 2007, Rene de Visser wrote:
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any comments or suggestions about
Is f(~p(x))=e(x) semantically equivalent to: f(z)=e(x) where p(x)=z?
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Greetings,
I am pleased to broadcast the launch of a new blog called the
software pattern blog http://pattern.ijop.org
http://pattern.ijop.org/
. This blog belongs to the editors of IJOP, columnists, staff,
advisory, editorial and domain expert boards, external reviewers, and
to those who have
Whatever happened to the idea of Or-Patterns?
http://www.haskell.org/pipermail/glasgow-haskell-users/2000-December/001535.html
I find them more than occasionally useful :) Is there some
theoretical difficulty
or is it just that nobody had the time/will to implement it?
Regards,
Lajos Nagy
We have released a new version of HaRP.
Major updates are:
* A revised syntax.
* Regular patterns are now non-greedy by default.
More information and downloads can be found at
http://www.dtek.chalmers.se/~d00nibro/harp/
/Niklas Broberg
isn't very good after all since it seems to confuse a lot of
people. Perhaps variables bound inside regular patterns should always be
non-linear... of course that would still be context dependent when
compared
to normal Haskell patterns, but perhaps still less confusing?
Dylan Thurston wrote
Dylan Thurston said:
By the way, are nested regular expression matches allowed? Something
like:
foo :: [[Int]] - Int
foo [/ _* [/ 5* a 6* /] _* /] = a
Yep.
? If so, what is the type of a in
foo [/ _* [/ 5* a* /]* _* /]
It would be [[Int]] because of the fact that [/ 5* a* /] alone
A wise man once said, release early and release often. We're obviously not
very wise... ;)
===
Announcing HaRP 0.1
===
HaRP is a Haskell extension that extends the normal pattern matching
facility with the power of regular expressions. This
This looks very interesting! I sometimes wish Haskell had more powerful
binding facilities, so that things like this don't need to be extensions
to the language. (But I'm not sure exactly what I'm wishing for...)
On Sat, May 15, 2004 at 12:08:53PM +, Niklas Broberg wrote:
Introducing
all since it seems to confuse a lot of
people. Perhaps variables bound inside regular patterns should always be
non-linear... of course that would still be context dependent when compared
to normal Haskell patterns, but perhaps still less confusing?
Anyway, thanks for the interest
patterns should always be
non-linear... of course that would still be context dependent when compared
to normal Haskell patterns, but perhaps still less confusing?
Alternatively, you could forbid the use of simple variables nonlinearly,
since there's an alternative way to write it. Or, you could
94 matches
Mail list logo
