Re: [Haskell] Views in Haskell

2007-01-24 Thread Dinko Tenev

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)

2006-04-12 Thread Dinko Tenev
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

2006-03-08 Thread Dinko Tenev
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: more flexible partial application

2006-01-27 Thread Dinko Tenev
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

2006-01-26 Thread Dinko Tenev
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