search

diku-dk / futhark

:boom::computer::boom: A data-parallel functional programming language
http://futhark-lang.org
ISC License
2.41k stars 166 forks source link

Better notation for currying operators #39

Closed athas closed 9 years ago

athas commented 9 years ago

The current operator currying syntax is derived from SML, and is therefore quite ugly. This should affect the external language only.

melsman commented 9 years ago

Maybe we should get together about this. A number of people here have some insights about language syntax, incl. Ken Friis Larsen (and my self, I think ;) I would be happy to provide input - the final decisions about syntax are, of course, up to you...

athas commented 9 years ago

Well, the external language is still fairly simple, so there's not really a lot of design space. Significantly, currying is only permitted in a few syntactic contexts. At some point, I would like to radically extend the language to permit a more classic/natural style of higher order functions, yet one that guarantees they can still in the end be "inlined", as is necessary for vectorised code. (So in essence, a glorified macro system with types.) I would very much like assistance with that, as it seems like an interesting problem quite amenable to a type system approach.

But today we are not at that point, so for now, I will do a simple thing that will make our test programs slightly more readable.

\ Troels /\ Henriksen

melsman commented 9 years ago

Ok - that makes sense. I will happily participate in discussions about a glorified macro-system with types. I think that the way we ended up designing the MLKit system using the "static-interpretation of modules" approach could be beneficial for Futhark - in particular in combination with an approach for delayed compilation of polymorphism...

On Wed, Mar 18, 2015 at 10:10 AM, Troels Henriksen <notifications@github.com

wrote:

Well, the external language is still fairly simple, so there's not really a lot of design space. Significantly, currying is only permitted in a few syntactic contexts. At some point, I would like to radically extend the language to permit a more classic/natural style of higher order functions, yet one that guarantees they can still in the end be "inlined", as is necessary for vectorised code. (So in essence, a glorified macro system with types.) I would very much like assistance with that, as it seems like an interesting problem quite amenable to a type system approach.

But today we are not at that point, so for now, I will do a simple thing that will make our test programs slightly more readable.

\ Troels /\ Henriksen

— Reply to this email directly or view it on GitHub https://github.com/HIPERFIT/futhark/issues/39#issuecomment-82833803.