Future Language Features

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

Future Language Features

Nicolas Cannasse
Hi,

Talking with Franco this morning, we have setup the following page which
list some ideas about future haXe Language and Compiler Features :

http://haxe.org/com/features

It's open for comments, but please don't edit it with your features
wishlist until they have been confirmed OK for inclusion on the mailing
list first.

BEst,
Nicolas

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

Re: Future Language Features

edA-qa mort-ora-y
Nicolas Cannasse wrote:
> Talking with Franco this morning, we have setup the following page which
> list some ideas about future haXe Language and Compiler Features :

This feature "Removal of temporary stack objects" is one that I'd really
like to see.  It would give an extreme speed improvement to most of my
code -- since I'm doing operations on Points just as in the example.

Would this be an automatic detection, or would the class/functions need
to be marked somehow?

How far could the logic go? For example with code like this:

var a = new Point( 4, 5 );
var b = new Point( 3, 6 );
var c = a.subtract(b).multiply( 0.3 ).plus( a );
var d = new Point( 10, 5 );
var e = c.sub( d );
return e.length();

Could all the Point objects disappear?

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Future Language Features

Cauê W.
In reply to this post by Nicolas Cannasse
Great, great features, Nicolas!

Have you reachead a conclusion on accessing dynamic field properties with the brackets? This would be specially useful for classes that implement Dynamic<Something> and that have a resolve function within.

2009/8/19 Nicolas Cannasse <[hidden email]>
Hi,

Talking with Franco this morning, we have setup the following page which list some ideas about future haXe Language and Compiler Features :

http://haxe.org/com/features

It's open for comments, but please don't edit it with your features wishlist until they have been confirmed OK for inclusion on the mailing list first.

BEst,
Nicolas

--
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: Future Language Features

Martijn Loots
In reply to this post by Nicolas Cannasse
On Wed, 19 Aug 2009, Nicolas Cannasse wrote:

> http://haxe.org/com/features
>

Would be nice if a logged in user could checkmark a maximum
of say, 3 "ME TOOs" on selected features, so you have a way of
finding out about features that are in great demand... ?

It is probably too big a change on the wiki software to
implement quickly, but still, it would be nice... :)

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

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

Re: Future Language Features

Gamehaxe
In reply to this post by Nicolas Cannasse
Hi,
I would like to propose a preprocessing/transforming option,
where a process is somehow specified to create a "virtual file system"
for finding and transforming classes. (eg: c-preprocess or as3->hx)

Hugh


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

Re: Future Language Features

edA-qa mort-ora-y
Hugh Sanderson wrote:
> I would like to propose a preprocessing/transforming option,
> where a process is somehow specified to create a "virtual file system"
> for finding and transforming classes. (eg: c-preprocess or as3->hx)

I'm not sure how well that would work out in the end.  I mean, I love
the idea, but the specifics would be difficult.

I'll take my m4-haxe as an example. The files end with .mhx rather than
.hx.  It would be great if haXe could simply find classes ending with
.mhx and pass them off to the "m4haxe" preprocessor first.

Some problems come up however:

1. How would it know when the file is out-dated? It doesn't know about
includes or anything. If it simply always recompiles it'll be too slow
to use (though m4 and haxe are fast, the whole setup around it takes a
while)

2. How would I pass additional options to the preprocessor?  Using a
makefile I setup additional rules for the mhx => hx translation. This is
project dependent.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Future Language Features

Ron Wheeler
In reply to this post by Nicolas Cannasse
I did a bit of editing to clarify the English.

Question on   haXe XML format

 In the paragraph
"The ability to output an XML representation of a fully typed haXe
program (after typing but before code generation), and the ability to
also load such XML representation, in order to enable 3rd party tools to
perform additional tasks before final compilation.", the expression
"fully typed" is subject to confusion.

Does it mean that the program has been completely entered into the
computer through the action of typing on a keyboard or does it refer to
strictly typed variables.

Assuming the former, it could be simplified to read
"The ability to output a haXe program to an XML file and to reconstruct
a haXe program from such an XML file. This will facilitate the creation
of 3rd party tools to perform code generation and other manipulation on
haXe programs. The original haXe program must be properly structured
with no syntax errors"

If this is better, either change it on the feature list or let me know
and I will edit the feature list.

My comment on the feature.
I would think that this should be combined with some syntax definitions
that facilitate weaving of code so that the  3rd party tools have a
reliable way of specifying the points where code should be woven and a
way to specify what should be woven that is flexible but protected from
future changes to the haXe syntax.
The tool maker should be able to say "If you embed this code in a
"extension" syntax element, my processor will do this for you and the
haXe compiler will not complain about a syntax error if you try to
compile your code without processing it first and you will not have to
worry about future haXe versions trying to use this save syntax.
 
Ron

 

Nicolas Cannasse wrote:

> Hi,
>
> Talking with Franco this morning, we have setup the following page
> which list some ideas about future haXe Language and Compiler Features :
>
> http://haxe.org/com/features
>
> It's open for comments, but please don't edit it with your features
> wishlist until they have been confirmed OK for inclusion on the
> mailing list first.
>
> BEst,
> Nicolas
>


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

Re: Future Language Features

Nicolas Cannasse
In reply to this post by edA-qa mort-ora-y
edA-qa mort-ora-y a écrit :
> Would this be an automatic detection, or would the class/functions need
> to be marked somehow?

Automatic detection, as soon as :

- no method is called on the object
- the object is not passed to another method or returned
- the constructor code is not big

So it will work well with classes that are fully inlined.

> How far could the logic go? For example with code like this:
>
> var a = new Point( 4, 5 );
> var b = new Point( 3, 6 );
> var c = a.subtract(b).multiply( 0.3 ).plus( a );
> var d = new Point( 10, 5 );
> var e = c.sub( d );
> return e.length();
>
> Could all the Point objects disappear?

If all the methods are inlined then yes.

Nicolas


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

Re: Future Language Features

Nicolas Cannasse
In reply to this post by Cauê W.
Cauê Waneck a écrit :
> Great, great features, Nicolas!
>
> Have you reachead a conclusion on accessing dynamic field properties
> with the brackets? This would be specially useful for classes that
> implement Dynamic<Something> and that have a resolve function within.

I think that's abusing the syntax. Brackets in haXe are for Array
accesses : some platforms made the choice to also enable field access
that way but it's not something that works in general.

So better to explicitly call .resolve for such cases

Nicolas

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

Re: Future Language Features

Nicolas Cannasse
In reply to this post by Ron Wheeler
Ron Wheeler a écrit :

> Does it mean that the program has been completely entered into the
> computer through the action of typing on a keyboard or does it refer to
> strictly typed variables.

It means that the compiler has fully parsed the program and typed it. So
every expression has a type associated with it.

> My comment on the feature.
> I would think that this should be combined with some syntax definitions
> that facilitate weaving of code so that the  3rd party tools have a
> reliable way of specifying the points where code should be woven and a
> way to specify what should be woven that is flexible but protected from
> future changes to the haXe syntax.
> The tool maker should be able to say "If you embed this code in a
> "extension" syntax element, my processor will do this for you and the
> haXe compiler will not complain about a syntax error if you try to
> compile your code without processing it first and you will not have to
> worry about future haXe versions trying to use this save syntax.

That's something very different : preprocessors and syntax extensions
operate directly before the code source get parsed by the compiler.
That's also something that you can already do by fully generating HX
sources before compiling with haXe.

Nicolas

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

Re: Future Language Features

Gamehaxe
In reply to this post by edA-qa mort-ora-y
Hi,
My basic thinking was something like this:

haxe --translate:"some_transform.exe" -Main SomeMain -neko Out.n

Currently, haxe goes something like:

for(path in class_path)
{
    stream = open_file(path + "SomeMain" + ".hx");
    ... if all is good, read tokens from stream ...
}

So now the is an extra step:

stream = "some_transform.exe" "SomeMain" "standard_defines"
    ... if all is good, read tokens from stream ...
    else
       for(path in class_path)
          ...

It would be up to "some_transform.exe" to add the ".mhx" or whatever.

haxe can pass the standard defines (which are "bool" flags) to
the exe - eg, neko generates a "-D neko" etc (hxcpp uses something like  
this)
So you can pass arbitrary bools to the transform using existing syntax.
Also, haxe could pass the standard class path to the exe.

It is up to the transform.exe to create a "virtual" file system -
the are no intermediate files to get out of date.

As for speed, the time to process should be in the order of the
time to parse the file for haxe - so would not expect it to more
that double the compile time.

If process creation-destruction is significant, then some protocol
could be used to create the exe once, and pass requests for files.
(With a single exe, you could always use a lightweight client/server
if you really wanted for much the same effect).  eg:

proc = CreateProcess("some_transform.exe");

...

write_stdin(proc,"SomeMain\n");
stream = read_stdout(proc)
    ... if all is good, read tokens from stream ...
    else


A virtual file system would also allow you to write an imperfect
as3->hx converter, and then supplement the conversion with "hints".
The idea here, if say you need to annotate an as3 array with a
specific haxe type, you could store this information "on the side"
(say somewhere special in the class-path),
thus leaving the thirdparty as3 library unchanged, while also
using it in haxe with improved typing/speed.

I'm sure there are some more specifics to work out here, but
that is the general idea.

Hugh





> Hugh Sanderson wrote:
>> I would like to propose a preprocessing/transforming option,
>> where a process is somehow specified to create a "virtual file system"
>> for finding and transforming classes. (eg: c-preprocess or as3->hx)
>
> I'm not sure how well that would work out in the end.  I mean, I love
> the idea, but the specifics would be difficult.
>
> I'll take my m4-haxe as an example. The files end with .mhx rather than
> .hx.  It would be great if haXe could simply find classes ending with
> .mhx and pass them off to the "m4haxe" preprocessor first.
>
> Some problems come up however:
>
> 1. How would it know when the file is out-dated? It doesn't know about
> includes or anything. If it simply always recompiles it'll be too slow
> to use (though m4 and haxe are fast, the whole setup around it takes a
> while)
>
> 2. How would I pass additional options to the preprocessor?  Using a
> makefile I setup additional rules for the mhx => hx translation. This is
> project dependent.
>



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

Re: Future Language Features

Gamehaxe
In reply to this post by Nicolas Cannasse
I second the request - I think dynamic languages should have a bit
of syntax sugar.  I'm thinking

var xy = { x:1, y:2 };

// Good if you know the name of "x":
trace(xy.x);

// But I think most languages support something like this:
var field = "y";
trace(xy[field]);

Hugh


> Cauê Waneck a écrit :
>> Great, great features, Nicolas!
>>  Have you reachead a conclusion on accessing dynamic field properties  
>> with the brackets? This would be specially useful for classes that  
>> implement Dynamic<Something> and that have a resolve function within.
>
> I think that's abusing the syntax. Brackets in haXe are for Array  
> accesses : some platforms made the choice to also enable field access  
> that way but it's not something that works in general.
>
> So better to explicitly call .resolve for such cases
>
> Nicolas
>



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

Re: Future Language Features

blackdog-2
In reply to this post by Nicolas Cannasse

What happened to async blocks as detailed here

http://old.haxe.org/proposals/haxe2

bd


On Wed, 19 Aug 2009 15:42:10 +0200
Nicolas Cannasse <[hidden email]> wrote:

> Hi,
>
> Talking with Franco this morning, we have setup the following page
> which list some ideas about future haXe Language and Compiler
> Features :
>
> http://haxe.org/com/features
>
> It's open for comments, but please don't edit it with your features
> wishlist until they have been confirmed OK for inclusion on the
> mailing list first.
>
> BEst,
> Nicolas
>


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

Re: Future Language Features

edA-qa mort-ora-y
In reply to this post by Nicolas Cannasse
Nicolas Cannasse wrote:
> I think that's abusing the syntax. Brackets in haXe are for Array
> accesses : some platforms made the choice to also enable field access
> that way but it's not something that works in general.

I agree this wouldn't be a good syntax.  But I'd be all in favour of
allowing the user to override the [] operator.  This would be great for
accessing things that behave like arrays, such as math-vectors and matrices.


--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Future Language Features

Nicolas Cannasse
In reply to this post by blackdog-2
black dog a écrit :
> What happened to async blocks as detailed here
>
> http://old.haxe.org/proposals/haxe2

I have not yet found a satisfying syntax/semantics, so it's not listed.

Nicolas

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

Re: Future Language Features

Benjamin Dasnois
In my opinion, operator overloading is a bad thing because it changes
the meaning of the operator depending on the class.

On Wed, Aug 19, 2009 at 6:54 PM, Nicolas
Cannasse<[hidden email]> wrote:

> black dog a écrit :
>>
>> What happened to async blocks as detailed here
>> http://old.haxe.org/proposals/haxe2
>
> I have not yet found a satisfying syntax/semantics, so it's not listed.
>
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
DASNOIS Benjamin
http://www.benjamindasnois.com

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

Re: Future Language Features

Cauê W.
In reply to this post by Nicolas Cannasse
I understand... It must be still harder to differentiate between an array call and a call to resolve function.
But I think it makes the code more readable, and hash-like functions more intuitive to use. Also, it makes the classes that implement Dynamic more useful, since the resolve automatically get called in all cases, not only in the ones that you know the field's name at compile time.

If brackets are already for array access, couldn't we implement another syntax for accessing fields?

2009/8/19 Nicolas Cannasse <[hidden email]>
Cauê Waneck a écrit :

Great, great features, Nicolas!

Have you reachead a conclusion on accessing dynamic field properties with the brackets? This would be specially useful for classes that implement Dynamic<Something> and that have a resolve function within.

I think that's abusing the syntax. Brackets in haXe are for Array accesses : some platforms made the choice to also enable field access that way but it's not something that works in general.

So better to explicitly call .resolve for such cases


Nicolas

--
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: Future Language Features

Armén
In reply to this post by Benjamin Dasnois
On Wed, Aug 19, 2009 at 19:28, Benjamin
Dasnois<[hidden email]> wrote:
> In my opinion, operator overloading is a bad thing because it changes
> the meaning of the operator depending on the class.

How is it a bad thing because of that? The expressiveness of a
language directly depends on variety being introduced first into said
language, and then expressing common operation known to the
user/programmer, such as multiplication, division, addition,
subtraction, etc. - into new types, such as different matrix
implementations. Since there is no inherent matrix basic type in haXe,
at least give users ability to write their own classes which do not
have those ugly "multiply" and "divide" function names, when it is
clear to any clear thinking person that matrix arithmetic should be
expressed using exactly the same syntax as real number arithmetic.

>
> On Wed, Aug 19, 2009 at 6:54 PM, Nicolas
> Cannasse<[hidden email]> wrote:
>> black dog a écrit :
>>>
>>> What happened to async blocks as detailed here
>>> http://old.haxe.org/proposals/haxe2
>>
>> I have not yet found a satisfying syntax/semantics, so it's not listed.
>>
>> Nicolas
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
>
>
> --
> DASNOIS Benjamin
> http://www.benjamindasnois.com
>
> --
> 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: Future Language Features

Pimm Hogeling
In reply to this post by Nicolas Cannasse
Hi all,

Good to see all the discussing. The thing I like most about haXe is that it's not just open source, it's really community-driven. I'd almost migrate to haXe just for that.

Let's get down to business. I'd like to point out a post I made last week about getters and setters: http://lists.motion-twin.com/pipermail/haxe/2009-August/028575.html. I feel that getters and setters combined with interfaces (or typedefs) are the biggest problem in haXe development at this moment. Therefor, I think it's the most important potential future language feature. I know getters and setters are complex because they get replaced at compile time, and I'm not really sure about the consequences it comes with. I want to invite others to respond to my ideas on this topic. That could be with ideas of your own, or technical details of what is and what isn't possible.

Thanks,

Pimm Hogeling

On Wed, Aug 19, 2009 at 15:42, Nicolas Cannasse <[hidden email]> wrote:
Hi,

Talking with Franco this morning, we have setup the following page which list some ideas about future haXe Language and Compiler Features :

http://haxe.org/com/features

It's open for comments, but please don't edit it with your features wishlist until they have been confirmed OK for inclusion on the mailing list first.

BEst,
Nicolas

--
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: Future Language Features

Lee Sylvester
In reply to this post by Nicolas Cannasse
Including a Flash SWC into my apps would be the one I want, as this  
would greatly increase the likelyhood of being able to get clients to  
accept using haXe in their projects.

Regards,
Lee




On 19 Aug 2009, at 14:42, Nicolas Cannasse <[hidden email]>  
wrote:

> Hi,
>
> Talking with Franco this morning, we have setup the following page  
> which list some ideas about future haXe Language and Compiler  
> Features :
>
> http://haxe.org/com/features
>
> It's open for comments, but please don't edit it with your features  
> wishlist until they have been confirmed OK for inclusion on the  
> mailing list first.
>
> BEst,
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org

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