more flexible partial application
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
I think this is doable, but you have to specify carefully where those lambdas are inserted. Where are they inserted in your suggestion? It has to be a syntactic transformation, because using type information would make it too complex in my opinion. In my opinion, it's a useful feature, but I'm not convinced it's useful enough to add to Haskell. -- Lennart Quoting Sebastian Sylvan <sebastian.sylvan@gmail.com>:
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
lennart@augustsson.net wrote:
In my opinion, it's a useful feature, but I'm not convinced it's useful enough to add to Haskell.
I agree. BTW, IIRC the language Hope+ had a similar feature. I think it was question marks that identified left out parameters in Hope+. Manuel
Quoting Sebastian Sylvan <sebastian.sylvan@gmail.com>:
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
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
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.
I just want to make sure I understand this. What would
foo x y z = \w -> ... bar x w = foo x _ _ w
mean?
bar x w = \y z -> foo x y z w
or
bar x w = (\y z -> foo x y z) w
Cheers, Andres
On 1/23/06, Andres Loeh <loeh@iai.uni-bonn.de> 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.
I just want to make sure I understand this.
What would
foo x y z = \w -> ... bar x w = foo x _ _ w
mean?
bar x w = \y z -> foo x y z w
or
bar x w = (\y z -> foo x y z) w
I'm not sure. :-) The first one seems to make more sense to me, but the second does make sense as well. So maybe the expansion should occur at the application site. I.e. walk along all the parameters to the function lifting each _ to an outer lambda expression (a la the first one). I'm not sure exactly the best way for this to behave. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
I don't think the second one makes sense. You would have to know something about foo to expand it into the second. But you might not, e.g., bar f x w = f x _ _ w -- Lennart Quoting Sebastian Sylvan <sebastian.sylvan@gmail.com>:
On 1/23/06, Andres Loeh <loeh@iai.uni-bonn.de> 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.
I just want to make sure I understand this.
What would
foo x y z = \w -> ... bar x w = foo x _ _ w
mean?
bar x w = \y z -> foo x y z w
or
bar x w = (\y z -> foo x y z) w
I'm not sure. :-) The first one seems to make more sense to me, but the second does make sense as well. So maybe the expansion should occur at the application site. I.e. walk along all the parameters to the function lifting each _ to an outer lambda expression (a la the first one).
I'm not sure exactly the best way for this to behave.
/S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
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 <sebastian.sylvan@gmail.com> 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
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 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. Jeffrey Yasskin On 1/24/06, Dinko Tenev <dinko.tenev@gmail.com> wrote:
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 <sebastian.sylvan@gmail.com> 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
On 1/25/06, Jeffrey Yasskin <jyasskin@google.com> 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
On 2006-01-25, Dinko Tenev wrote:
a huge base64 blob.
Which, sadly, makes it harder for me to read your messages. I don't suppose there's anyway to get gmail to only label messages as UTF-8 only if they contain non-ascii? -- Aaron Denney -><-
participants (7)
-
Aaron Denney -
Andres Loeh -
Dinko Tenev -
Jeffrey Yasskin -
lennart＠augustsson.net -
Manuel M T Chakravarty -
Sebastian Sylvan