Re: [Haskell] Views in Haskell
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) = ... f (prodSize ? = Big) = ... ...or maybe (Small = prodSize ?), etc., to be consistent with let bindings? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: limitations of newtype-derivings (fixed)
On 4/11/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > | > deriving (Show Foo) > > I'm all for that. A modest but useful gain. All we need is the syntax, > and that is something that Haskell Prime might usefully define. Speaking of which, how about simply qualifying a body-less instance with "deriving," like this: > deriving instance Show Foo -- Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: partial application syntax
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/FlexiblePartialApplication On 3/7/06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote: > Hello, > > there was some proposal for introducing a special syntax where f x _ z or > f x ? z means \y -> f x y z. Is there some information on the Haskell' trac > site about this? > > Best wishes, > Wolfgang > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://haskell.org/mailman/listinfo/haskell-prime > -- Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Labels and the tentative solution to the MPTC Dilemma
On 2/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: [...] > class EqL1 a c | a -> c > instance EqL1 L1 HTrue > instance EqL1 L2 HFalse > > class EqL2 a c | a -> c > instance EqL2 L1 HFalse > instance EqL2 L2 HTrue [...] Doesn't this spell quadratic blow-up on the number of labels in scope? It also seems tangled, considering the cost of adding a new label to the set. -- Cheers, Dinko ___ 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
I'll second that.
I'll just throw in that not all pragmas ({-# ... #-}) are really
annotations, because they do not necessarily pertain to one particular
entity each. Some could be attached -- e.g. DEPRECATED, INLINE /
NOINLINE, SPECIALIZE. Others, however, couldn't -- say, rewrite rules
-- and are bound to remain as pragmas, even if the rest are converted
to annotations.
Cheers,
DInko
On 2/2/06, Johannes Waldmann <[EMAIL PROTECTED]> 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.
> Also, they have a retention policy saying whether they should be visible
> at compile time or at run time. Compile time is for tools/preprocessors,
> and visibility at run time is helpful for reflection. see e. g. JLS 9.6f
> http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6
> some example text is here:
> http://dfa.imn.htwk-leipzig.de/~waldmann/draft/meta-haskell/
>
> Best regards,
> --
> -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
> http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: more flexible partial application
On 1/27/06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote: > Am Freitag, 27. Januar 2006 12:15 schrieb Dinko Tenev: > > [...] > > > About the whole extension, (f x _ z) is arguably clearer than \y -> f > > x y z, > > For me, it's really not clearer. (f x _ z) looks like an application of f to > three arguments since _ looks like a special expression (similar to _ in > patterns being a special pattern). I feel tempted to argue to the contrary, but at this point of the argument, I think it's already a matter of personal preference. Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: more flexible partial application
On 1/26/06, Aaron Denney <[EMAIL PROTECTED]> wrote: > On 2006-01-26, Dinko Tenev <[EMAIL PROTECTED]> wrote: > > On 1/26/06, Conor McBride <[EMAIL PROTECTED]> wrote: > > [...] > >> We'd do daft stuff like > >> > >> (200 * _ ^ 2) unitsquare > > > > Yes, I played with a concept like that at one point, and came to the > > conclusion that it was better done with lambdas. I am all > > specifically about function application, not arbitrary expressions. > > Arbitrary expressions are just function application. ...arbitrarily deeply nested. I meant looking at a single level of function application, with all the consequences for how high up the tree the underscore may "escape" as a lambda. You're probably going to tell me that f x y z represents 3 different levels, but many folks would see this as little more than a cute way of writing f(x, y, z), and they'll have a point, given how the concept of "partial" application is bandied every so often. It is quite reasonable to identify a minimal enclosing application, with all visible arguments consumed up to the innermost enclosing pair of parentheses. Sure, it's not a very elegant concept, but neither is the current mechanism for operator sections (which does exactly the same.) The only implication will be that you won't be able to use sections *and* emphasize the order of application at the same time, and I am yet to hear from anyone who prefer (((f x) y) z) to (f x y z) in their code. BTW, it just occurred to me that if this section syntax is extended to operators as well, it would cure the rather embarrassing case of the "-" operator :) > >> If you do want to pull a stunt like this, you need some other funny > >> brackets which specifically indicate this binding power, and then you > >> can do grouping inside them, to create larger linear abstractions. You > >> could have something like > >> > >> (| f (_ * 3) _ |) > > > > We already have lambdas for this, and they're shorter, clearer, and > > more powerful. > > The same hold (except for shorter) for this whole extension, and I don't > know that "shorter" holds here. I missed an underscore, so you have your point about "shorter." About the whole extension, (f x _ z) is arguably clearer than \y -> f x y z, and is also really unobtrusive syntactic sugar, very much unlike a new kind of brackets. > -- > Aaron Denney > -><- Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: more flexible partial application
On 1/26/06, Conor McBride <[EMAIL PROTECTED]> wrote: [...] > We'd do daft stuff like > > (200 * _ ^ 2) unitsquare Yes, I played with a concept like that at one point, and came to the conclusion that it was better done with lambdas. I am all specifically about function application, not arbitrary expressions. [...] > Giving parentheses this murky binding power interferes with their innocence. The parentheses won't bind, they'll only delimit the expression that will be subject to re-interpretation, and then simply in a by-the-way manner, very much like in the operator sections case. They'll still be innocent in the absense of relevant syntax :) > If you do want to pull a stunt like this, you need some other funny > brackets which specifically indicate this binding power, and then you > can do grouping inside them, to create larger linear abstractions. You > could have something like > > (| f (_ * 3) _ |) We already have lambdas for this, and they're shorter, clearer, and more powerful. > But in my wild and foolish adulthood, I'm not sure it's worth spending a > kind of bracket on. Definitely not. But an underscore can still be spent on the much simpler case :) > > All the best > > Conor Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: more flexible partial application
On 1/26/06, John Hughes <[EMAIL PROTECTED]> wrote: > I'd be against this--its semantics isn't clear enough to me. For example, > I usually assume id e = e, for any e, but > > id (f _ x) y = id (\y->f y x) y = f y x > /= > f _ x y = \z -> f z x y > > Or would (f _ x) y and f _ x y maybe be different? That would fix the > problem above, while introducing another. Please, no! They should be different for this to work. The reasonable thing to do would be to rewrite every (e _ a1 a2 ... an) as (\x -> (e x a1 a2 ... an)) and the parentheses should be mandatory. Note that this can be done recursively, so that e.g. (f _ y _ t) ==> (\x1 -> (f x1 y _ t)) ==> (\x1 -> (\x2 -> (f x1 y x2 t))) I see this as no worse than operator sections: we already have (- x) and (-) x meaning different things. Having in mind that (e _ ...) is just syntax, it should be easy to keep it separate from application, so f x y z will still be the same as ((f x) y) z. > > John Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: more flexible partial application
On 1/25/06, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > I think it's a neat feature, but: > > Using _ seems to conflict with a Jhc extension in which "Using > underscore in an expression expands to bottom with an error message > giving the current file and line number." > http://repetae.net/john/computer/jhc/jhc.html For one thing, JHC clearly goes beyond Haskell '98 here, and for another, it clearly has no point using syntax where a reserved word would do just fine. > Scheme has a similar feature called (cut) documented at > http://srfi.schemers.org/srfi-26/srfi-26.html. I haven't read the > SRFI, but it would make sense to incorporate their experience in any > new feature for Haskell. For what I understand from the document, their experience suggests that it is a useful feature, if anything :) > > Jeffrey Yasskin > Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: more flexible partial application
I created a feature request for this while GHC was still on SF, it has propagated to trac and can be seen here: http://hackage.haskell.org/trac/ghc/ticket/315 Cheers, Dinko On 1/23/06, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > Are there any subtle reasons for why something like the following > couldn't be allowed? > > > > foo x y z w = ... > > bar x w = foo x _ _ w > > I.e. a more flexible version of partial application. This would be > translated too > > > bar x w = \y z -> foo x y z w > > I.e a function which takes the "_" parameters in the same order they > were encountered in the function application. > > Some other languages allow this, such as Nemerle. Quite handy. > > /S > > -- > Sebastian Sylvan > +46(0)736-818655 > UIN: 44640862 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
