Local inline functions, defines, tuples

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Local inline functions, defines, tuples

Yanis Benson

Here are some ideas to discuss:

1. We already have local named functions. How about inlined ones?
As we all know, calling functions is costly at some targets, and when it comes to optimizing we frequently try to reduce function calls number. Sometimes it conflicts with code readability. For such cases creating a separate class with a number of inlined functions could work, and another opportunity is to create some utility functions in current class. I usually prefer the second choice, but there are some problems when using basic values (ints, strings), because we can't modify them and only can return one of them. The first option doesn't have this shortcoming, but has additional overhead for instantiating and field access.
So my proposal it's to add local inlined functions. Except the fact they should be inlined, they also shouldn't capture values, but be just inlined as they are and get the values out of the current scope(except arguments). It can probably be achieved by using macros, but not in a clean way.
Also, it can drastically improve lambda performance without any pains. (I'm working on doing that by macros, but it's not the same.)
Totally backwards compatible.

2. Defines.
Define space becomes polluted.
My proposal - define scope, going from global defines to package wide defines to source file wide defines. Examples:
-D DEBUG
-D mylib.DEVDEBUG
-d mylib.NoNeedToDebugThat.DEVDEBUG
-d mylib.NoNeedToDebugThat.DEBUG
where -d stands for undefined.
Not sure if macro API for defines is already deployed, in other cases backward compatible.

3. Tuples.
It was floating around for a long time. Why don't we have tuples in std lib plus sugar for creation and assign (from tuple to multiple variables)? Also, optimization of tuples for inlines will allow multiple value returns without overhead. (Sad, but targets won't allow us multiple value returns without tuple instantiation for normal functions.)
Backward compatible but requires syntactic changes, just wanted to bring it to the light.
Also, solves most of the problems which brought proposal number 1 to life.

P.M. I'm writing from the phone and my English is not so good, sip sorry for possible errors/typos.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

Nicolas Cannasse
Le 07/09/2011 23:21, Yanis Benson a écrit :
> Here are some ideas to discuss:
>
> 1. We already have local named functions. How about inlined ones?

Not very hard to implement, but there is a syntax issue : the "inline"
is a field modifier (same as public, static, etc.) so it's currently not
supported in the AST.

> Also, it can drastically improve lambda performance without any pains.
> (I'm working on doing that by macros, but it's not the same.)

Calls such as (function(a) return a * a)(5) will get optimized as 25 so
if you have a Lambda implementation with inlined methods this with
optimize cases such as LambdaInl.map(a,function(x) return x + 1)

> Totally backwards compatible.

It would break macros AST if we need to modify it.

> 2. Defines.
> Define space becomes polluted.
> My proposal - define scope, going from global defines to package wide
> defines to source file wide defines.

Why not.

> 3. Tuples.

haXe already has "named tuples" which are structures { x : 0, y : 0 }
for instance stands for two values.

Having real tuples in the language requires additional syntax if we want
to handle them nicely, and I'm not a big fan of adding more syntax.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

Yanis Benson
In reply to this post by Yanis Benson

I know that you aren't a big fan of changing syntax, Nicolass, neither am I.

Talking about tuples, I think benefits would be really great, so it costs the changes and efforts. Talking about syntax, it's obvious from my point of view, but I'll still write how I see it.
var a = (1, 'str', new Obj());
var b:(Int, String, Obj) = (1, 'str', null);
var (i, s, obj) = a;
var s2 = b.2; //not sure about this one
with converting to Tuple3<Int, String, Ink> on the inside(for tuple of length 3).

From my test, local functions don't get inlined. I will retest. If it really is so then changing AST is too big cost for now. Maybe for some major release...

Also, I forgot to say that I can supply the patches, but since i'm short on time and still not very comfortable with ocaml I guess it will be easier for you or some of the other core developers.

On 8 Sep 2011 12:06, "Nicolas Cannasse" <[hidden email]> wrote:

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

Yanis Benson

I don't see a lot of the interest from the community. I'm not forcing you, but why don't you guys give some comments on that? I'm especially interested in what so to say "core" users have to say about the ideas I posted.

On 8 Sep 2011 14:47, "Yanis Benson" <[hidden email]> wrote:
> I know that you aren't a big fan of changing syntax, Nicolass, neither am I.
>
> Talking about tuples, I think benefits would be really great, so it costs
> the changes and efforts. Talking about syntax, it's obvious from my point of
> view, but I'll still write how I see it.
> var a = (1, 'str', new Obj());
> var b:(Int, String, Obj) = (1, 'str', null);
> var (i, s, obj) = a;
> var s2 = b.2; //not sure about this one
> with converting to Tuple3<Int, String, Ink> on the inside(for tuple of
> length 3).
>
> From my test, local functions don't get inlined. I will retest. If it really
> is so then changing AST is too big cost for now. Maybe for some major
> release...
>
> Also, I forgot to say that I can supply the patches, but since i'm short on
> time and still not very comfortable with ocaml I guess it will be easier for
> you or some of the other core developers.
> On 8 Sep 2011 12:06, "Nicolas Cannasse" <[hidden email]> wrote:

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

jlm@justinfront.net

On 9 Sep 2011, at 22:21, Yanis Benson wrote:
> > Talking about tuples, I think benefits would be really great

Probably, I guess no one has commented as tuples were discussed  
before?  Would Tuples be something you could add to the Stax haxelib  
or something, maybe a rough implementation, and some instructions to  
get started, I would be keen to try them in flash and javascript  
targets as I have been reading about them in haskel and f#? and they  
look useful to more functional approaches.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

Yanis Benson
In reply to this post by Yanis Benson

I guess they are already there. But in my opinion, they are almost useless without proper sugar,  because they require long type descriptions and the operations like (a, b) = (1, 'str') are totally impossible without proper syntax constructs.
Talking about functional approach, tuples are really useful in any case, they allow write code in shorter and more intuitive way. Basically they are needed when you want to work with any set off values of constant length and it doesn't make sense to create a class or anonymous structure. Basic usage is when you want to return a couple of values. Like that:

var (success, value) = parse(something);
if(success) trace('parser output: '+value);
else trace('wrong format');

So, it's nothing we can't already do, but it's just a fast, clean and intuitive way to do many things.

By the way, if some function returns null, it usually means that the tuple should be used instead, because null is just like added boolean value, as in example above.

On 10 Sep 2011 15:36, <[hidden email]> wrote:

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

laurence taylor
In reply to this post by jlm@justinfront.net
Tuples are in Stax, but both their declaration and use are unnecessarily verbose. Tuples require a class for each number of parameters, and the declarations need to be changed accordingly. Tuple2 for a tuple of length 2, Tuple3, and so on. Tuple creation relies on Tuple2.create("first·,1), which somewhat obfuscates bread and butter tree relations. given that this can be done in an untyped, opaque way using Array<Dynamic>, I guess the (provocative) question is, are types important?

regards,
Laurence
On Sat, Sep 10, 2011 at 1:34 PM, <[hidden email]> wrote:

On 9 Sep 2011, at 22:21, Yanis Benson wrote:
> Talking about tuples, I think benefits would be really great

Probably, I guess no one has commented as tuples were discussed before?  Would Tuples be something you could add to the Stax haxelib or something, maybe a rough implementation, and some instructions to get started, I would be keen to try them in flash and javascript targets as I have been reading about them in haskel and f#? and they look useful to more functional approaches.



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

sledorze
Yes, types are importants :)

With Stax, one can also do: 5.entuple("toto") using 'using'.. (and chain them)

I've added some syntactic sugar for application that may be merged in the short term.
myTuple.apply(function (a, b) { ... })

But yes, destructuring assignment is lacking here.. and if Nicolas brings it on the table for enums, then we would have to reimplement tuples as they are implemented in the Stax library.

This prevent me to invest too much time into extending it coz I think that macros incresed the usefulness of destructuring assignment and know that it will be part of Haxe 3.0.

So.. stay tuned.. and wait :)
Reply | Threaded
Open this post in threaded view
|

Re: Local inline functions, defines, tuples

Viktor Hesselbom-2
When/if static import is implemented ( http://code.google.com/p/haxe/issues/detail?id=365 ) we could at least get something like t("one",1) so we're close ;)

2011/9/10 sledorze <[hidden email]>
Yes, types are importants :)

With Stax, one can also do: 5.entuple("toto") using 'using'.. (and chain
them)

I've added some syntactic sugar for application that may be merged in the
short term.
myTuple.apply(function (a, b) { ... })

But yes, destructuring assignment is lacking here.. and if Nicolas brings it
on the table for enums, then we would have to reimplement tuples as they are
implemented in the Stax library.

This prevent me to invest too much time into extending it coz I think that
macros incresed the usefulness of destructuring assignment and know that it
will be part of Haxe 3.0.

So.. stay tuned.. and wait :)


--
View this message in context: http://haxe.1354130.n2.nabble.com/Local-inline-functions-defines-tuples-tp6769525p6778911.html
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org