[haXe] Functional programming constructs in Haxe

Jeffery Zhang jzhang at noria.com
Wed Aug 2 17:10:51 CEST 2006


Message: 3

Date: Tue, 01 Aug 2006 21:32:43 +0200

From: Nicolas Cannasse <ncannasse at motion-twin.com>

Subject: Re: [haXe] Functional programming constructs in Haxe

To: The haXe compiler list <haxe at lists.motion-twin.com>

Message-ID: <44CFAC5B.40201 at motion-twin.com>

Content-Type: text/plain; charset=windows-1252; format=flowed

 

> The reason why I chose haxe over AS for development is mostly because 

> of the support for functional programming constructs. I hope haxe 

> doesn't become yet another object oriented language. When I write 

> programs I tend to think in terms of dataflow rather than objects. 

> What I would really like to see in a programming language is some 

> dataflow constructs. Pretty much every programming language that 

> support function calls have dataflow syntax like this: f(in)->out. I 

> wish there were some construct like f(in)->(list of places to send the


> output). I guess what I'm asking for is to add continuations to the 

> language, except implement them in a more friendly way (syntax wise).

 

Continuations are not possible in haXe, or at least not in all languages
since neither JS or Flash have correct support for them. haXe should
have enough functional support, if you need some additional features
just ask.

 

Nicolas

 

So here's my wishlist (I don't know if any/all of them are
implementable)

1.	Be able to write array.sort(>) instead of having to write
wrapper code for standard operators
2.	Operator/function overloading (what's the legal identifier
names? The documentation didn't give a regex for it) Combined with 1,
this should reduce my typing.
3.	Lexical closures. Classes are really heavy weight. Sometimes I
just want a function that can maintain some internal state between
calls.
4.	Yield. I guess this kind of builds on top of closures. I want
this mostly to be able to write generators.
5.	ML like pattern matching. Basically allow me to write things
like var [x, y] = [1, 2] or var {x:a, y:b} = {x:1, y:2} assigning a to 1
and b to 2.
6.	Goes with #5 and #2, pattern matching on function parameters.
7.	Currying. (maybe with keyword parameters?) So if I have f(a, b)
and some value b', be able to curry the function into f'(a) and save
that as a value.
8.	A function composition operator. So I can write (f.g) or
something and save that as a value. So if f:a' * 'b -> 'c, g:'d * 'e ->
'a, composing f.g would get fn:'d * 'e * 'b -> 'c.
9.	An extension to typedef that allows me to associate types with
predicates. The reason why I want this feature is that I would like to
make use of the type checker more. For example, if I'm working with some
parameter that should only take the values from 10-15 for example, the
value range restriction is domain specific. Right now I would have to
use an Int and check that the value ranges are legal within every
function I pass it to. This should really be unnecessary. I want to be
able to define a type like Int(10-15) or Int(<60) or String(/ab*c/).
Basically the type checker knows that the new subtype is a subset of the
base type, but instead of creating a whole new class just for this, it
would be must more convenient to just define a predicate that checks any
value that is assigned to a variable of that type (at runtime), but the
compiler can statically check and warn when I or someone else using my
code tries to pass an Int into a function that takes an Int(10-15). Even
better is if for base types like Int, Float, String, the compiler is
smart enough to know that Int(10-15)<:Int(10-16)<:Int(<40), etc. I think
whether one regular expression define a subset of another is also
decidable. So if the type checker is smart enough to know these things,
and extend it to composite types, I can do things like define
Int(10-15), Int(16-20), etc and pass it to a function that takes
Int(10-50) and pattern match on the type rather than type out a whole
ton of if-else. 
10.	A couple of extra functions in the Lambda package wouldn't hurt
either, reduce, maplist (calls f on successive cdr), range (generates
list from 1 to n), reduce-tree

 

The thing with 3 and 9 is that I find myself using classes a lot for
just a single feature of OOP. It would improve the brevity and structure
of m programs (and reduce class proliferation) to allow more lightweight
alternatives. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20060802/e40a40c5/attachment-0001.htm


More information about the Haxe mailing list