HaXe or a new language?

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

HaXe or a new language?

Shelby Moore
I have some numbered suggestions for HaXe improvements near the bottom.
Thank you in advance for any feedback.

MAJOR ISSUE: I am still stuck on whether function callbacks from Neko to
HaXe are feasible?  Why so far I get no feedback on this list to this very
important question?

http://lists.motion-twin.com/pipermail/haxe/2010-January/033284.html

Note see haxeToNeko(), not nekoToHaxe() in above post.  Also, why does
std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
given that std.Neko.Lib.load() does cast and return a tfunction to a
Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?

http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx

Appears that std.neko.net.Socket (thus also haxe.Http and haxe.remoting.*)
is not asynchronous and instead uses chunked reading with a connection
timeout.  How to create robust real-time online applications that can
handle persistantly slow connections on Neko?  Whereas, I see that async
callback is supported for Javascript in haxe.Http, haxe.remoting.*, and
onreadystatechange callback in js.XMLHttpRequest.

I have started to work on my own new HaXe-like (static+dynamic typing)
language initially targetting Neko, primarily because there was no
response to the question about Neko to HaXe callbacks.

I would prefer to focus my efforts on HaXe (the concept of static+dynamic
is awesome), so as to not duplicate a huge amount of pre-existing work.
But without callbacks from external languages (significantly C and Neko),
HaXe can not implement my goal for enabling a new more granular and
interoperable model for open source (cooperative programming).  In my
composability model (which I believe will exponentially win the future of
open source), it is just as important for languages to interopt on a
platform as it is for a language to target multiple platforms and
languages.

I wish I had a better understanding of the implementation of functions and
closures that HaXe is employing on Neko.  I suppose I could take the time
to set up an environment to build HaXe from sources and alter the HaXe
sources to not delete the .neko file after compilation to .n (why isn't
there already a compile flag for that general need? Could someone with a
build environment add the flag to help out?) so I can study the
implementation details, but may consume significant time and the lack of
feedback on this issue is discouraging me.

Function callback from implementation layer (e.g. Neko) to the HLL (e.g.
HaXe), need not be concerned with the implementation of class (method
lookup), only with the way the HLL implements the argument list and return
value.  It appears that the only difference between HaXe function and Neko
tfunction, is the arguments and return value have to converted with
haxeToNeko() <--> nekoToHaxe()?  Thus callbacks are feasible now?

Additionally, to interopt at the implementation layer on HLL class (i.e.
to offer potential cross-language OOP interoptability), the format in the
implementation layer must be documented. If class member lookup is not a
hash table of member names, then multiple inheritance of interfaces and/or
of class with virtual (override) methods, requires runtime change of the
virtual table pointer (prototype) on (even implicit) cast:

http://en.wikipedia.org/w/index.php?title=Virtual_method_table&oldid=330860854#Multiple_inheritance_and_thunks

The point is that HaXe FFI and class member lookup are documentable, and
thus then interoperable.  The problem right now is we have no
documentation on how these are implemented on the various platforms.  I am
willing to help out on .neko if someone can provide a build of HaXe that
will optionally compile to .neko and not .n.  Or, perhaps Nicolas might be
able to answer the question on HaXe FFI and class member lookup formats.

Tangentially if I proceed on my own language, I would eliminate virtual
methods (override) as it semantically subverts static typing (and virtual
inheritance is unnecessary when interface is available):

http://lists.motion-twin.com/pipermail/neko/2010-January/002717.html

I also realized that the keywords 'interface' and 'implements' are
unnecessary, as any class with partial implementation could be construed
to be an interface (and thus can not be instantiated).  This would add the
feature of partial implementation of interfaces.

The LL(1) NBNF parser generator and parser to AST for my new language is
nearly complete (I've chosen a name but don't ask me yet), so I can begin
to make some comments about possible improvements for HaXe, given I have
had to start the process of thinking deeply about such matters for my new
design.  I hope to get feedback on thought processes early as possible.  I
may decide to halt work on this new HLL to focus my efforts on HaXe, if I
can get some helpful feedback.


Additional HaXe issues I think can be improved:

1. Class variables types are not inferred from the constructor:

http://haxe.org/ref/oop


2. Dynamic types must be declared and can not be inferred:

var o : Dynamic = {};

Or:

class Object implements Dynamic {};
var o = new Object();

The following will not infer a dynamic object with unlimited fields,
because it is inferred to be an Anonymous/Structural static type (
http://haxe.org/ref/type_advanced ):

var o = {};
var oo = { x : 1, y : 2 };

Given preference for dynamic typing when execution speed is less important
than programming speed (which is 80% of the time in my experience), I
would prefer the less verbose default to infer Dynamic when assigning
{...} and add a Static type (which means "the type as inferred", so only
needs to be used for {...} and does nothing on cast).  I would not change
class to be Dynamic by default.  Untyped block is not a lower verbosity
solution because it applies to everything in the block, and thus untyped
has to be repeated perhaps at every var declaration.  Low verbosity is one
of the significant reasons why dynamic coding is more readable and thus
faster coding and learning/studying code.


3. Non-static class method can not be curried type safely (
http://haxe.org/ref/callback ) in following case, because there is no way
to use callback() to curry the following:

Lambda.map( ['string1','string2'], function( s ) { return s.charAt( 3 ); } );


4. Dynamic fields can not be accessed with bracket syntax
instance[String], instead must either use verbose Reflect api for or wrap
the code in 'untyped':

http://lists.motion-twin.com/pipermail/haxe/2008-December/021365.html
http://lists.motion-twin.com/pipermail/haxe/2008-December/021372.html
http://lists.motion-twin.com/pipermail/haxe/2008-December/021390.html

I do not understand what 'untyped' does.  Is 'untyped' code passed through
unaltered to the implementation layer, thus give different semantics on
different platforms?

We can use std.Hash<String> instead of Dynamic class, but still more
verbose than bracket syntax.


5. Am I correct that the following does not create a Javascript-like
coupling of an Object and Array with unlimited dynamic fields in addition
to the integer indexed array of dynamic buckets?

var o : Dynamic = new Array<Dynamic>();

Of course such a coupling could be simulated in HaXe as follows, but why
not make it automatic as it is often needed to store the elements of an
array in a companion hash table to speed lookup of index and to pass these
around together (and besides when one is writing dynamic typed code, they
care not much about speed or memory, but care most about code elegance and
low verbosity):

class Object implements Dynamic {};
var o = new Object()
o.array = new Array<Dynamic>();

However, we still have problem #4 above.


6. Verbosity (else runtime semantic errors) when comparing basic types
(Int, Float, Bool) to null on different platform targets, since must
remember to wrap in Null<BasicType> or declare Dynamic:

http://lists.motion-twin.com/pipermail/haxe/2008-November/021040.html
http://lists.motion-twin.com/pipermail/haxe/2008-November/021002.html

I thought I read some where that HaXe will not allow reading a local or
class var that was not set?  If true, the above only applies to Array (and
global variables?) of basic type.

HaXe could be "fixed" to output compiler warnings when comparing null to a
basic type that is not nullable (e.g. when Null<> is not used on Flash 9),
and add an optional compiler flag to force the default for basic types to
be Null<> on all platforms.

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

Re: HaXe or a new language?

Lee Sylvester
Shelby Moore wrote:
> I have some numbered suggestions for HaXe improvements near the bottom.
> Thank you in advance for any feedback.
>
> MAJOR ISSUE: I am still stuck on whether function callbacks from Neko to
> HaXe are feasible?  Why so far I get no feedback on this list to this very
> important question?

Not too sure what you mean by this, but:

You can create a function in Neko and pass it to haXe, which can then be
callable in native haXe much like it is in Neko

You can create a function in haXe and pass it to Neko and execute it in
the Neko C code

Is that what you wanted answered? :-)

Lee



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

Re: HaXe or a new language?

Lee Sylvester
In reply to this post by Shelby Moore
I thought I'd better clarify how this works. If you create a function in
C that you'd like callable in your haXe code, you create your method,
such as

value add_ints( value param1, value param2 )
{
    int a = val_int( param1 );
    int b = val_int( param2 );
    return alloc_int( a + b );
}

expose the function from C

DEFINE_PRIM( add_ints, 2 );

And in your haXe code, you create a static link to that method, by means of:

var add : Function = neko.Lib.load( "myNekoNdll", "add_ints", 2 );

You can then call it at will in haXe

var result = add( 2, 2 );


Likewise, you can also pass a haXe function from haXe to your C lib and
call it in the C code, such as

value exec_func( value func )
{
    value result = val_call2( func, alloc_int( 2 ), alloc_int( 2 ) );
    return result;
}


Hope that helps

Lee



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

Re: HaXe or a new language?

Heinz Hölzer-2
In reply to this post by Shelby Moore
you can keep the generated neko code with
  --neko-source

this is also listed in the usage with

haxe --help



Am 01.02.2010 20:41, schrieb Shelby Moore:

> I have some numbered suggestions for HaXe improvements near the bottom.
> Thank you in advance for any feedback.
>
> MAJOR ISSUE: I am still stuck on whether function callbacks from Neko to
> HaXe are feasible?  Why so far I get no feedback on this list to this very
> important question?
>
> http://lists.motion-twin.com/pipermail/haxe/2010-January/033284.html
>
> Note see haxeToNeko(), not nekoToHaxe() in above post.  Also, why does
> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
> given that std.Neko.Lib.load() does cast and return a tfunction to a
> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>
> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx
>
> Appears that std.neko.net.Socket (thus also haxe.Http and haxe.remoting.*)
> is not asynchronous and instead uses chunked reading with a connection
> timeout.  How to create robust real-time online applications that can
> handle persistantly slow connections on Neko?  Whereas, I see that async
> callback is supported for Javascript in haxe.Http, haxe.remoting.*, and
> onreadystatechange callback in js.XMLHttpRequest.
>
> I have started to work on my own new HaXe-like (static+dynamic typing)
> language initially targetting Neko, primarily because there was no
> response to the question about Neko to HaXe callbacks.
>
> I would prefer to focus my efforts on HaXe (the concept of static+dynamic
> is awesome), so as to not duplicate a huge amount of pre-existing work.
> But without callbacks from external languages (significantly C and Neko),
> HaXe can not implement my goal for enabling a new more granular and
> interoperable model for open source (cooperative programming).  In my
> composability model (which I believe will exponentially win the future of
> open source), it is just as important for languages to interopt on a
> platform as it is for a language to target multiple platforms and
> languages.
>
> I wish I had a better understanding of the implementation of functions and
> closures that HaXe is employing on Neko.  I suppose I could take the time
> to set up an environment to build HaXe from sources and alter the HaXe
> sources to not delete the .neko file after compilation to .n (why isn't
> there already a compile flag for that general need? Could someone with a
> build environment add the flag to help out?) so I can study the
> implementation details, but may consume significant time and the lack of
> feedback on this issue is discouraging me.
>
> Function callback from implementation layer (e.g. Neko) to the HLL (e.g.
> HaXe), need not be concerned with the implementation of class (method
> lookup), only with the way the HLL implements the argument list and return
> value.  It appears that the only difference between HaXe function and Neko
> tfunction, is the arguments and return value have to converted with
> haxeToNeko()<-->  nekoToHaxe()?  Thus callbacks are feasible now?
>
> Additionally, to interopt at the implementation layer on HLL class (i.e.
> to offer potential cross-language OOP interoptability), the format in the
> implementation layer must be documented. If class member lookup is not a
> hash table of member names, then multiple inheritance of interfaces and/or
> of class with virtual (override) methods, requires runtime change of the
> virtual table pointer (prototype) on (even implicit) cast:
>
> http://en.wikipedia.org/w/index.php?title=Virtual_method_table&oldid=330860854#Multiple_inheritance_and_thunks
>
> The point is that HaXe FFI and class member lookup are documentable, and
> thus then interoperable.  The problem right now is we have no
> documentation on how these are implemented on the various platforms.  I am
> willing to help out on .neko if someone can provide a build of HaXe that
> will optionally compile to .neko and not .n.  Or, perhaps Nicolas might be
> able to answer the question on HaXe FFI and class member lookup formats.
>
> Tangentially if I proceed on my own language, I would eliminate virtual
> methods (override) as it semantically subverts static typing (and virtual
> inheritance is unnecessary when interface is available):
>
> http://lists.motion-twin.com/pipermail/neko/2010-January/002717.html
>
> I also realized that the keywords 'interface' and 'implements' are
> unnecessary, as any class with partial implementation could be construed
> to be an interface (and thus can not be instantiated).  This would add the
> feature of partial implementation of interfaces.
>
> The LL(1) NBNF parser generator and parser to AST for my new language is
> nearly complete (I've chosen a name but don't ask me yet), so I can begin
> to make some comments about possible improvements for HaXe, given I have
> had to start the process of thinking deeply about such matters for my new
> design.  I hope to get feedback on thought processes early as possible.  I
> may decide to halt work on this new HLL to focus my efforts on HaXe, if I
> can get some helpful feedback.
>
>
> Additional HaXe issues I think can be improved:
>
> 1. Class variables types are not inferred from the constructor:
>
> http://haxe.org/ref/oop
>
>
> 2. Dynamic types must be declared and can not be inferred:
>
> var o : Dynamic = {};
>
> Or:
>
> class Object implements Dynamic {};
> var o = new Object();
>
> The following will not infer a dynamic object with unlimited fields,
> because it is inferred to be an Anonymous/Structural static type (
> http://haxe.org/ref/type_advanced ):
>
> var o = {};
> var oo = { x : 1, y : 2 };
>
> Given preference for dynamic typing when execution speed is less important
> than programming speed (which is 80% of the time in my experience), I
> would prefer the less verbose default to infer Dynamic when assigning
> {...} and add a Static type (which means "the type as inferred", so only
> needs to be used for {...} and does nothing on cast).  I would not change
> class to be Dynamic by default.  Untyped block is not a lower verbosity
> solution because it applies to everything in the block, and thus untyped
> has to be repeated perhaps at every var declaration.  Low verbosity is one
> of the significant reasons why dynamic coding is more readable and thus
> faster coding and learning/studying code.
>
>
> 3. Non-static class method can not be curried type safely (
> http://haxe.org/ref/callback ) in following case, because there is no way
> to use callback() to curry the following:
>
> Lambda.map( ['string1','string2'], function( s ) { return s.charAt( 3 ); } );
>
>
> 4. Dynamic fields can not be accessed with bracket syntax
> instance[String], instead must either use verbose Reflect api for or wrap
> the code in 'untyped':
>
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021365.html
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021372.html
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021390.html
>
> I do not understand what 'untyped' does.  Is 'untyped' code passed through
> unaltered to the implementation layer, thus give different semantics on
> different platforms?
>
> We can use std.Hash<String>  instead of Dynamic class, but still more
> verbose than bracket syntax.
>
>
> 5. Am I correct that the following does not create a Javascript-like
> coupling of an Object and Array with unlimited dynamic fields in addition
> to the integer indexed array of dynamic buckets?
>
> var o : Dynamic = new Array<Dynamic>();
>
> Of course such a coupling could be simulated in HaXe as follows, but why
> not make it automatic as it is often needed to store the elements of an
> array in a companion hash table to speed lookup of index and to pass these
> around together (and besides when one is writing dynamic typed code, they
> care not much about speed or memory, but care most about code elegance and
> low verbosity):
>
> class Object implements Dynamic {};
> var o = new Object()
> o.array = new Array<Dynamic>();
>
> However, we still have problem #4 above.
>
>
> 6. Verbosity (else runtime semantic errors) when comparing basic types
> (Int, Float, Bool) to null on different platform targets, since must
> remember to wrap in Null<BasicType>  or declare Dynamic:
>
> http://lists.motion-twin.com/pipermail/haxe/2008-November/021040.html
> http://lists.motion-twin.com/pipermail/haxe/2008-November/021002.html
>
> I thought I read some where that HaXe will not allow reading a local or
> class var that was not set?  If true, the above only applies to Array (and
> global variables?) of basic type.
>
> HaXe could be "fixed" to output compiler warnings when comparing null to a
> basic type that is not nullable (e.g. when Null<>  is not used on Flash 9),
> and add an optional compiler flag to force the default for basic types to
> be Null<>  on all platforms.
>
>    


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

Re: HaXe or a new language?

clemos
In reply to this post by Shelby Moore
On Mon, Feb 1, 2010 at 8:41 PM, Shelby Moore <[hidden email]> wrote:

[snip]

> I wish I had a better understanding of the implementation of functions and
> closures that HaXe is employing on Neko.  I suppose I could take the time
> to set up an environment to build HaXe from sources and alter the HaXe
> sources to not delete the .neko file after compilation to .n (why isn't
> there already a compile flag for that general need? Could someone with a
> build environment add the flag to help out?) so I can study the
> implementation details, but may consume significant time and the lack of
> feedback on this issue is discouraging me.

[snip]

There actually is a flag for that " --neko-source"
see "haxe --help"

Hope this helps
++++++
Clément

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

Re: HaXe or a new language?

Shelby Moore
In reply to this post by Shelby Moore
> I also realized that the keywords 'interface' and 'implements' are
> unnecessary, as any class with partial implementation could be construed
> to be an interface (and thus can not be instantiated).  This would add the
> feature of partial implementation of interfaces.

Correction, I mean 'interface' and 'extends' are unnecessary.

I understand that 'implements' is virtual inheritance (i.e. duplicate
copies in the inheritance tree are merged):

http://www.phpcompiler.org/articles/virtualinheritance.htm
(also an example of how to document the class implementation format)

Given my idea for inheriting any implementation of interfaces, if one
wants 'extends', then use 'implements' instead.

If one wants more than one copy of the inherited class members, then in
the constructor assign an instance to a class member variable 'parent',
then use parent.member instead of super.member.  This parent.* methodology
only breaks virtual methods (override) and up-casting entire instance to
the parent class copy (doesn't break up-casting to the 'implements'
interfaces), but in prior post I argued virtual methods from upcasted
references break type safety and are unnecessary given we have
'implements'.

I do not discuss potential down-casting, because it would be a run time
type check and could throw an exception.

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

Re: HaXe or a new language?

Shelby Moore
In reply to this post by Lee Sylvester
> I thought I'd better clarify how this works. If you create a function in
> C that you'd like callable in your haXe code, you create your method,
> such as
>
> value add_ints( value param1, value param2 )
> {
>     int a = val_int( param1 );
>     int b = val_int( param2 );
>     return alloc_int( a + b );
> }
>
> expose the function from C
>
> DEFINE_PRIM( add_ints, 2 );
>
> And in your haXe code, you create a static link to that method, by means
> of:
>
> var add : Function = neko.Lib.load( "myNekoNdll", "add_ints", 2 );
>
> You can then call it at will in haXe
>
> var result = add( 2, 2 );


Thanks, but the C FFI is interfacing with Neko types?

Thus, we need to convert the arguments and return value?

var neko_int = neko.haxeToNeko( 2 );
var result = neko.nekoToHaxe( add( neko_int, neko_int ) );


> Likewise, you can also pass a haXe function from haXe to your C lib and
> call it in the C code, such as
>
> value exec_func( value func )
> {
>     value result = val_call2( func, alloc_int( 2 ), alloc_int( 2 ) );
>     return result;
> }
>
>
> Hope that helps


Yes thanks very much, that is what I was hoping for and it helps a lot.

This is what I expected to be the case.

Note, the func must call neko.nekoToHaxe() on its input arguments, because
alloc_int( 2 ) creates a Neko int, not a Haxe int.

If the above works, again I repeat that that neko.haxeToNeko() (and
neko.nekoToHaxe) should be fixed to not throw an exception when the input
argument is a function type.

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

Re: HaXe or a new language?

Lee Sylvester
If I remember correctly, you only need to convert arrays and strings,
not int's, float's, functions etc.

haxeToNeko and nekoToHaxe are simply helpers. Most basic types don't
need converting at all and string and array types can be converted
manually by doing

untyped myArray.__a
untyped myString.__s

Everything else is good to go.

I could be wrong, as this may have changed in more recent haXe releases,
but I'm pretty sure it hasn't. So, put simply, my example in my previous
email can be taken literally :-)

Lee





Shelby Moore wrote:

>> I thought I'd better clarify how this works. If you create a function in
>> C that you'd like callable in your haXe code, you create your method,
>> such as
>>
>> value add_ints( value param1, value param2 )
>> {
>>     int a = val_int( param1 );
>>     int b = val_int( param2 );
>>     return alloc_int( a + b );
>> }
>>
>> expose the function from C
>>
>> DEFINE_PRIM( add_ints, 2 );
>>
>> And in your haXe code, you create a static link to that method, by means
>> of:
>>
>> var add : Function = neko.Lib.load( "myNekoNdll", "add_ints", 2 );
>>
>> You can then call it at will in haXe
>>
>> var result = add( 2, 2 );
>>    
>
>
> Thanks, but the C FFI is interfacing with Neko types?
>
> Thus, we need to convert the arguments and return value?
>
> var neko_int = neko.haxeToNeko( 2 );
> var result = neko.nekoToHaxe( add( neko_int, neko_int ) );
>
>
>  
>> Likewise, you can also pass a haXe function from haXe to your C lib and
>> call it in the C code, such as
>>
>> value exec_func( value func )
>> {
>>     value result = val_call2( func, alloc_int( 2 ), alloc_int( 2 ) );
>>     return result;
>> }
>>
>>
>> Hope that helps
>>    
>
>
> Yes thanks very much, that is what I was hoping for and it helps a lot.
>
> This is what I expected to be the case.
>
> Note, the func must call neko.nekoToHaxe() on its input arguments, because
> alloc_int( 2 ) creates a Neko int, not a Haxe int.
>
> If the above works, again I repeat that that neko.haxeToNeko() (and
> neko.nekoToHaxe) should be fixed to not throw an exception when the input
> argument is a function type.
>
>  


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

Re: HaXe or a new language?

Lee Sylvester
In reply to this post by Shelby Moore
It may help for you to check out some ndll source files. My ndll
projects contain all the C source as well as the haXe wrapper classes.
They'll give you a good idea as to how it all works. My best advice is
to look at the SQLite sources, as they're nice and neat and cover every
data type conversion you need to know about.

Lee





Shelby Moore wrote:

>> I thought I'd better clarify how this works. If you create a function in
>> C that you'd like callable in your haXe code, you create your method,
>> such as
>>
>> value add_ints( value param1, value param2 )
>> {
>>     int a = val_int( param1 );
>>     int b = val_int( param2 );
>>     return alloc_int( a + b );
>> }
>>
>> expose the function from C
>>
>> DEFINE_PRIM( add_ints, 2 );
>>
>> And in your haXe code, you create a static link to that method, by means
>> of:
>>
>> var add : Function = neko.Lib.load( "myNekoNdll", "add_ints", 2 );
>>
>> You can then call it at will in haXe
>>
>> var result = add( 2, 2 );
>>    
>
>
> Thanks, but the C FFI is interfacing with Neko types?
>
> Thus, we need to convert the arguments and return value?
>
> var neko_int = neko.haxeToNeko( 2 );
> var result = neko.nekoToHaxe( add( neko_int, neko_int ) );
>
>
>  
>> Likewise, you can also pass a haXe function from haXe to your C lib and
>> call it in the C code, such as
>>
>> value exec_func( value func )
>> {
>>     value result = val_call2( func, alloc_int( 2 ), alloc_int( 2 ) );
>>     return result;
>> }
>>
>>
>> Hope that helps
>>    
>
>
> Yes thanks very much, that is what I was hoping for and it helps a lot.
>
> This is what I expected to be the case.
>
> Note, the func must call neko.nekoToHaxe() on its input arguments, because
> alloc_int( 2 ) creates a Neko int, not a Haxe int.
>
> If the above works, again I repeat that that neko.haxeToNeko() (and
> neko.nekoToHaxe) should be fixed to not throw an exception when the input
> argument is a function type.
>
>  


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

Re: HaXe or a new language?

Shelby Moore
In reply to this post by Heinz Hölzer-2
> you can keep the generated neko code with
>   --neko-source
>
> this is also listed in the usage with
>
> haxe --help

Thanks guys.

If only I had two eyes:

http://code.google.com/p/haxe/source/browse/trunk/main.ml#370

I was looking in the wrong place and do not know OCaml (I'm Haskel
literate) and so on quick look, misunderstood what the source is doing:

http://code.google.com/p/haxe/source/browse/trunk/genneko.ml#760

Thanks to the helpful feedback, as for the other "improvements" I
suggested, I might decide continue to implement my new language and target
HaXe instead of Neko initially.  The syntax would ne nearly identical to
HaXe, so it should be a painless transistion for those who prefer the
"less verbose" style for their dynamic coding.  I think this might make
HaXe+Neko more competitive with Python, especially if I get my concept
rolling for massive new libraries of code (in HaXe or my new language
which would output HaXe).

Exciting except I hate vaporware.

It is notable that so far (since Oct 2008) I was only able to find very
few things I personally would change about HaXe to achieve the ideal
(80/20) balance for static+dynamic typing.

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

Re: HaXe or a new language?

Heinz Hölzer-2
In reply to this post by Shelby Moore
you should take a look at the source code of the std-library,
so you can see that an int is just returned without conversion.

neko.Sys:

public static function nekoToHaxe( v : Dynamic ) : Dynamic untyped {
         switch( __dollar__typeof(v) ) {
         case __dollar__tnull: return v;
         case __dollar__tint: return v;
         case __dollar__tfloat: return v;
         case __dollar__tbool: return v;
         case __dollar__tstring: return new String(v);
         case __dollar__tarray:
             var a = Array.new1(v,__dollar__asize(v));
             for( i in 0...a.length )
                 a[i] = nekoToHaxe(a[i]);
             return a;
         case __dollar__tobject:
             var f = __dollar__objfields(v);
             var i = 0;
             var l = __dollar__asize(f);
             var o = __dollar__new(v);
             if( __dollar__objgetproto(v) != null )
                 throw "Can't convert object prototype";
             while( i < l ) {
                 
__dollar__objset(o,f[i],nekoToHaxe(__dollar__objget(v,f[i])));
                 i += 1;
             }
             return o;
         default:
             throw "Can't convert "+string(v);
         }
     }

     /**
         Converts a Neko value to its haXe equivalent. Used to unwrap
String and Arrays Objects into raw Neko values.
     **/
     public static function haxeToNeko( v : Dynamic ) : Dynamic untyped {
         switch( __dollar__typeof(v) ) {
         case __dollar__tnull: return v;
         case __dollar__tint: return v;
         case __dollar__tfloat: return v;
         case __dollar__tbool: return v;
         case __dollar__tobject:
             var cl = v.__class__;
             if( cl == String )
                 return v.__s;
             if( cl == Array ) {
                 var a = untyped __dollar__amake(v.length);
                 for( i in 0...v.length )
                     a[i] = haxeToNeko(v[i]);
                 return a;
             }
             if( cl != null || __dollar__objgetproto(v) != null )
                 throw "Can't convert "+string(v);
             var f = __dollar__objfields(v);
             var i = 0;
             var l = __dollar__asize(f);
             var o = __dollar__new(v);
             while( i < l ) {
                 
__dollar__objset(o,f[i],haxeToNeko(__dollar__objget(v,f[i])));
                 i += 1;
             }
             return o;
         default:
             throw "Can't convert "+string(v);
         }
     }


Am 01.02.2010 22:38, schrieb Shelby Moore:

>> I thought I'd better clarify how this works. If you create a function in
>> C that you'd like callable in your haXe code, you create your method,
>> such as
>>
>> value add_ints( value param1, value param2 )
>> {
>>      int a = val_int( param1 );
>>      int b = val_int( param2 );
>>      return alloc_int( a + b );
>> }
>>
>> expose the function from C
>>
>> DEFINE_PRIM( add_ints, 2 );
>>
>> And in your haXe code, you create a static link to that method, by means
>> of:
>>
>> var add : Function = neko.Lib.load( "myNekoNdll", "add_ints", 2 );
>>
>> You can then call it at will in haXe
>>
>> var result = add( 2, 2 );
>>      
>
> Thanks, but the C FFI is interfacing with Neko types?
>
> Thus, we need to convert the arguments and return value?
>
> var neko_int = neko.haxeToNeko( 2 );
> var result = neko.nekoToHaxe( add( neko_int, neko_int ) );
>
>
>    
>> Likewise, you can also pass a haXe function from haXe to your C lib and
>> call it in the C code, such as
>>
>> value exec_func( value func )
>> {
>>      value result = val_call2( func, alloc_int( 2 ), alloc_int( 2 ) );
>>      return result;
>> }
>>
>>
>> Hope that helps
>>      
>
> Yes thanks very much, that is what I was hoping for and it helps a lot.
>
> This is what I expected to be the case.
>
> Note, the func must call neko.nekoToHaxe() on its input arguments, because
> alloc_int( 2 ) creates a Neko int, not a Haxe int.
>
> If the above works, again I repeat that that neko.haxeToNeko() (and
> neko.nekoToHaxe) should be fixed to not throw an exception when the input
> argument is a function type.
>
>    


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

Re: HaXe or a new language?

Heinz Hölzer-2
In reply to this post by Shelby Moore
sorry, it's neko.Lib not Sys!

Am 01.02.2010 22:38, schrieb Shelby Moore:

>> I thought I'd better clarify how this works. If you create a function in
>> C that you'd like callable in your haXe code, you create your method,
>> such as
>>
>> value add_ints( value param1, value param2 )
>> {
>>      int a = val_int( param1 );
>>      int b = val_int( param2 );
>>      return alloc_int( a + b );
>> }
>>
>> expose the function from C
>>
>> DEFINE_PRIM( add_ints, 2 );
>>
>> And in your haXe code, you create a static link to that method, by means
>> of:
>>
>> var add : Function = neko.Lib.load( "myNekoNdll", "add_ints", 2 );
>>
>> You can then call it at will in haXe
>>
>> var result = add( 2, 2 );
>>      
>
> Thanks, but the C FFI is interfacing with Neko types?
>
> Thus, we need to convert the arguments and return value?
>
> var neko_int = neko.haxeToNeko( 2 );
> var result = neko.nekoToHaxe( add( neko_int, neko_int ) );
>
>
>    
>> Likewise, you can also pass a haXe function from haXe to your C lib and
>> call it in the C code, such as
>>
>> value exec_func( value func )
>> {
>>      value result = val_call2( func, alloc_int( 2 ), alloc_int( 2 ) );
>>      return result;
>> }
>>
>>
>> Hope that helps
>>      
>
> Yes thanks very much, that is what I was hoping for and it helps a lot.
>
> This is what I expected to be the case.
>
> Note, the func must call neko.nekoToHaxe() on its input arguments, because
> alloc_int( 2 ) creates a Neko int, not a Haxe int.
>
> If the above works, again I repeat that that neko.haxeToNeko() (and
> neko.nekoToHaxe) should be fixed to not throw an exception when the input
> argument is a function type.
>
>    


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

Re: HaXe or a new language?

Shelby Moore
In reply to this post by Lee Sylvester
> If I remember correctly, you only need to convert arrays and strings,
> not int's, float's, functions etc.
>
> haxeToNeko and nekoToHaxe are simply helpers. Most basic types don't
> need converting at all and string and array types can be converted
> manually by doing
>
> untyped myArray.__a
> untyped myString.__s
>
> Everything else is good to go.


Agreed:

http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx#98

Again thanks so much for sharing the pointers to examples and confirming
that calling back from Neko to HaXe works.

It would be great if a callback example was added to the documentation page:

http://haxe.org/doc/neko/ffi?lang=en

>
> I could be wrong, as this may have changed in more recent haXe releases,
> but I'm pretty sure it hasn't. So, put simply, my example in my previous
> email can be taken literally :-)


The API documentation agrees that conversion only applies to Strings and
Arrays:

http://haxe.org/api/neko/lib?lang=en

We are warned to use haxeToNeko and nekoToHaxe, so our code won't break if
the implementation changes.

http://haxe.org/doc/advanced/magic

"Use these resources with care; they may change between versions."

Wouldn't hurt to use them every where, if for no other reason that if we
change an argument or return type in future to Dynamic and forget to add
the conversion wrapper.

As for extra verbosity, I plan to code a wrapper for the loader to obscure
that and provide type safety.

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

Re: HaXe or a new language?

back2dos
In reply to this post by Shelby Moore
Shelby Moore wrote:

> I have some numbered suggestions for HaXe improvements near the bottom.
> Thank you in advance for any feedback.
>
> MAJOR ISSUE: I am still stuck on whether function callbacks from Neko to
> HaXe are feasible?  Why so far I get no feedback on this list to this very
> important question?
>
> http://lists.motion-twin.com/pipermail/haxe/2010-January/033284.html
>
> Note see haxeToNeko(), not nekoToHaxe() in above post.  Also, why does
> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
> given that std.Neko.Lib.load() does cast and return a tfunction to a
> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>  
yes, this is very strange. it should only throw an exception for
tabstract and simply return the original value for tfunction.
> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx
>
> Appears that std.neko.net.Socket (thus also haxe.Http and haxe.remoting.*)
> is not asynchronous and instead uses chunked reading with a connection
> timeout.  How to create robust real-time online applications that can
> handle persistantly slow connections on Neko?  Whereas, I see that async
> callback is supported for Javascript in haxe.Http, haxe.remoting.*, and
> onreadystatechange callback in js.XMLHttpRequest.
>  
if you do not want to wait for the socket, start a background thread to
do that.

> I have started to work on my own new HaXe-like (static+dynamic typing)
> language initially targetting Neko, primarily because there was no
> response to the question about Neko to HaXe callbacks.
>
> I would prefer to focus my efforts on HaXe (the concept of static+dynamic
> is awesome), so as to not duplicate a huge amount of pre-existing work.
> But without callbacks from external languages (significantly C and Neko),
> HaXe can not implement my goal for enabling a new more granular and
> interoperable model for open source (cooperative programming).  In my
> composability model (which I believe will exponentially win the future of
> open source), it is just as important for languages to interopt on a
> platform as it is for a language to target multiple platforms and
> languages.
>  
haXe doesn't have a concept of static+dynamic. haXe is completely static.
haXe target platforms are dynamic and the dynamic features can be used
when bypassing the static type-system.
dynamic behaviour is always platform specific.

> I wish I had a better understanding of the implementation of functions and
> closures that HaXe is employing on Neko.  I suppose I could take the time
> to set up an environment to build HaXe from sources and alter the HaXe
> sources to not delete the .neko file after compilation to .n (why isn't
> there already a compile flag for that general need? Could someone with a
> build environment add the flag to help out?) so I can study the
> implementation details, but may consume significant time and the lack of
> feedback on this issue is discouraging me.
>
> Function callback from implementation layer (e.g. Neko) to the HLL (e.g.
> HaXe), need not be concerned with the implementation of class (method
> lookup), only with the way the HLL implements the argument list and return
> value.  It appears that the only difference between HaXe function and Neko
> tfunction, is the arguments and return value have to converted with
> haxeToNeko() <--> nekoToHaxe()?  Thus callbacks are feasible now?
>  
yes, callbacks between haXe and neko are possible. you do not need to
convert values between haXe and neko.
The only two differences between haXe and neko are strings and arrays.
In the haXe world, neko arrays and strings are NativeArray and NativeString.
In the neko world, haXe arrays and strings are objects referencing the
underlying value and using neko VM operator overloading
(http://nekovm.org/specs#operators_overloading) to behave as native
arrays and strings.

> Additionally, to interopt at the implementation layer on HLL class (i.e.
> to offer potential cross-language OOP interoptability), the format in the
> implementation layer must be documented. If class member lookup is not a
> hash table of member names, then multiple inheritance of interfaces and/or
> of class with virtual (override) methods, requires runtime change of the
> virtual table pointer (prototype) on (even implicit) cast:
>
> http://en.wikipedia.org/w/index.php?title=Virtual_method_table&oldid=330860854#Multiple_inheritance_and_thunks
>
> The point is that HaXe FFI and class member lookup are documentable, and
> thus then interoperable.  The problem right now is we have no
> documentation on how these are implemented on the various platforms.  I am
> willing to help out on .neko if someone can provide a build of HaXe that
> will optionally compile to .neko and not .n.  Or, perhaps Nicolas might be
> able to answer the question on HaXe FFI and class member lookup formats.
>  
as already stated, you can use --neko-source as documented in
http://haxe.org/doc/compiler
also you may want to have a look at the neko builtins
http://nekovm.org/doc/view/builtins. I found it quite revealing and
helpful for understanding neko.
however I don't understand what you're up to.
vtables and prototypes are completely unrelated. a prototype object is a
regular first class object that lookups of undefined properties are
forwarded to.

> Tangentially if I proceed on my own language, I would eliminate virtual
> methods (override) as it semantically subverts static typing (and virtual
> inheritance is unnecessary when interface is available):
>
> http://lists.motion-twin.com/pipermail/neko/2010-January/002717.html
>
> I also realized that the keywords 'interface' and 'implements' are
> unnecessary, as any class with partial implementation could be construed
> to be an interface (and thus can not be instantiated).  This would add the
> feature of partial implementation of interfaces.
>  
haXe targets platforms such as the AVM2. The AVM2 allows classes to
extend one superclass and to implement multiple interfaces.
Anything else will probably throw a VerifyError when booting.
As long as haXe will try to stay compatible with the native languages fo
targets like these, it will always be very limited.
People prefer the idea of being able to interoperate with AS3 as good as
possible, to that of having more sensible semantics brought to haXe.
Looking at the current usage of haXe and that of AS3, I think they have
a point.

> The LL(1) NBNF parser generator and parser to AST for my new language is
> nearly complete (I've chosen a name but don't ask me yet), so I can begin
> to make some comments about possible improvements for HaXe, given I have
> had to start the process of thinking deeply about such matters for my new
> design.  I hope to get feedback on thought processes early as possible.  I
> may decide to halt work on this new HLL to focus my efforts on HaXe, if I
> can get some helpful feedback.
>
>
> Additional HaXe issues I think can be improved:
>
> 1. Class variables types are not inferred from the constructor:
>
> http://haxe.org/ref/oop
>  
that'd be nice to have actually. i guess it's not obvious to do. also,
you may not choose to initialize some variables in the constructor and
the question is, what to do then.

>
> 2. Dynamic types must be declared and can not be inferred:
>
> var o : Dynamic = {};
>
> Or:
>
> class Object implements Dynamic {};
> var o = new Object();
>
> The following will not infer a dynamic object with unlimited fields,
> because it is inferred to be an Anonymous/Structural static type (
> http://haxe.org/ref/type_advanced ):
>
> var o = {};
> var oo = { x : 1, y : 2 };
>
> Given preference for dynamic typing when execution speed is less important
> than programming speed (which is 80% of the time in my experience), I
> would prefer the less verbose default to infer Dynamic when assigning
> {...} and add a Static type (which means "the type as inferred", so only
> needs to be used for {...} and does nothing on cast).  I would not change
> class to be Dynamic by default.  Untyped block is not a lower verbosity
> solution because it applies to everything in the block, and thus untyped
> has to be repeated perhaps at every var declaration.  Low verbosity is one
> of the significant reasons why dynamic coding is more readable and thus
> faster coding and learning/studying code.
>  
it is not a haXe but a platform feature that anonymous objects actually
may have unlimited fields. that's exactly why you require untyped.
a backend could just as well decide to compile an anonymous object into
"sealed" objects.
using anonymous objects as a hashes is wrong use. if you look at good
cross-platfrom projects such as hscript, you will realize people always
use Hash instead.

anonymous objects are anonymous objects and hashes are hashes. the
former are entities or at least records, the latter are collections.
throwing them all together doesn't make code better, clearer or easier
to understand or study.

also, I don't see why programming speed is faster if everything is dynamic.
most of the overhead required by popular statically typed languages is
completely reduced in haXe through type inference.
and there is little if any programming speed benefit in letting
anonymous objects be dynamic. it's more of a good way to shoot yourself
in the foot.
>
> 3. Non-static class method can not be curried type safely (
> http://haxe.org/ref/callback ) in following case, because there is no way
> to use callback() to curry the following:
>
> Lambda.map( ['string1','string2'], function( s ) { return s.charAt( 3 ); } );
>  
it'd be cool if this worked with callback somehow, yet it's a little
hard to imagine.
could you provide an example of how you would like this to work?
>
> 4. Dynamic fields can not be accessed with bracket syntax
> instance[String], instead must either use verbose Reflect api for or wrap
> the code in 'untyped':
>  
why should they be?
it's arguable whether ArrayAccess<T> shouldn't rather be
ArrayAccess<K,T> but that'd be quite hard on some platforms.
ArrayAccess is a marker implying that the specified object supports
Array access on the native platform.
Array access is compiled to native array access on all platforms except C++.
Nonetheless, lookup of values by keys from a collection is not
semantically equivalent with a lookup of property by name from an object,
so it's not really clear to me, why it should be using the same syntax.
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021365.html
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021372.html
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021390.html
>
> I do not understand what 'untyped' does.  Is 'untyped' code passed through
> unaltered to the implementation layer, thus give different semantics on
> different platforms?
>  
yes, it does give different semantics on different platforms. as far as
I know, it isn't necessarily passed through
unaltered (altough this is the case for most platforms).
> We can use std.Hash<String> instead of Dynamic class, but still more
> verbose than bracket syntax.
>  
see above.

>
> 5. Am I correct that the following does not create a Javascript-like
> coupling of an Object and Array with unlimited dynamic fields in addition
> to the integer indexed array of dynamic buckets?
>
> var o : Dynamic = new Array<Dynamic>();
>
> Of course such a coupling could be simulated in HaXe as follows, but why
> not make it automatic as it is often needed to store the elements of an
> array in a companion hash table to speed lookup of index and to pass these
> around together (and besides when one is writing dynamic typed code, they
> care not much about speed or memory, but care most about code elegance and
> low verbosity):
>
> class Object implements Dynamic {};
> var o = new Object()
> o.array = new Array<Dynamic>();
>
> However, we still have problem #4 above.
>  
see above.

>
> 6. Verbosity (else runtime semantic errors) when comparing basic types
> (Int, Float, Bool) to null on different platform targets, since must
> remember to wrap in Null<BasicType> or declare Dynamic:
>
> http://lists.motion-twin.com/pipermail/haxe/2008-November/021040.html
> http://lists.motion-twin.com/pipermail/haxe/2008-November/021002.html
>
> I thought I read some where that HaXe will not allow reading a local or
> class var that was not set?  If true, the above only applies to Array (and
> global variables?) of basic type.
>
> HaXe could be "fixed" to output compiler warnings when comparing null to a
> basic type that is not nullable (e.g. when Null<> is not used on Flash 9),
> and add an optional compiler flag to force the default for basic types to
> be Null<> on all platforms.
>  
I agree haXe is not very consistent with nullability in many ways.
Also, I find it strange that Null<SomeEnum> cannot be matched against
null in switch statements.

greetz
back2dos

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

Re: HaXe or a new language?

Shelby Moore
In reply to this post by Shelby Moore
[snip...8<....]

> The LL(1) NBNF parser generator and parser to AST for my new language is
> nearly complete

Note in case any one was astute enough to snicker at that claim (<big
grin>), it is only LL(1) because I used <...> instead of {...} as value,
because '{' conflicts with scoping block, both of which are expressions in
the Neko and HaXe grammer.

This is so I can have a non-complex LL(1) parser generator.  I want the
parser generator to be very easy to understand so more people can see how
easy it is to make their own languages.

I can patch the code output from the parser generator to LL(5) look ahead
(need up to 5 tokens) for this specific branch in the parse tree.

Or I could change the grammar to not allow scoping blocks to be
expressions, and this would improve compatibility with Javascript, but
remove that HaXe feature.

The parser generator is currently written in Javascript and if I meet my
goal (see my suggestions below) to make my new language 90% syntax
compatible with Javascript for the dynamic code case, then (assuming I
create wrappers for the standard Javascript classes) it will be trivial to
bootstrap that parser, as well ease transistion to HaXe strictness (via my
new language) for Javascript programmers.  Note I stated I might continue
my new language and make it output HaXe:

http://lists.motion-twin.com/pipermail/haxe/2010-February/033349.html

> 2. Dynamic types must be declared and can not be inferred:
>
> var o : Dynamic = {};
>
> Or:
>
> class Object implements Dynamic {};
> var o = new Object();
>
> The following will not infer a dynamic object with unlimited fields,
> because it is inferred to be an Anonymous/Structural static type (
> http://haxe.org/ref/type_advanced ):
>
> var o = {};
> var oo = { x : 1, y : 2 };
>
> Given preference for dynamic typing when execution speed is less important
> than programming speed (which is 80% of the time in my experience), I
> would prefer the less verbose default to infer Dynamic when assigning
> {...} and add a Static type (which means "the type as inferred", so only
> needs to be used for {...} and does nothing on cast).  I would not change
> class to be Dynamic by default.  Untyped block is not a lower verbosity
> solution because it applies to everything in the block, and thus untyped
> has to be repeated perhaps at every var declaration.  Low verbosity is one
> of the significant reasons why dynamic coding is more readable and thus
> faster coding and learning/studying code.

[snip...8<....]

> 4. Dynamic fields can not be accessed with bracket syntax
> instance[String], instead must either use verbose Reflect api for or wrap
> the code in 'untyped':
>
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021365.html
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021372.html
> http://lists.motion-twin.com/pipermail/haxe/2008-December/021390.html
>
> I do not understand what 'untyped' does.  Is 'untyped' code passed through
> unaltered to the implementation layer, thus give different semantics on
> different platforms?
>
> We can use std.Hash<String> instead of Dynamic class, but still more
> verbose than bracket syntax.
>
>
> 5. Am I correct that the following does not create a Javascript-like
> coupling of an Object and Array with unlimited dynamic fields in addition
> to the integer indexed array of dynamic buckets?
>
> var o : Dynamic = new Array<Dynamic>();
>
> Of course such a coupling could be simulated in HaXe as follows, but why
> not make it automatic as it is often needed to store the elements of an
> array in a companion hash table to speed lookup of index and to pass these
> around together (and besides when one is writing dynamic typed code, they
> care not much about speed or memory, but care most about code elegance and
> low verbosity):
>
> class Object implements Dynamic {};
> var o = new Object()
> o.array = new Array<Dynamic>();
>
> However, we still have problem #4 above.

[snip...8<....]

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

Re: HaXe or a new language?

Shelby Moore
In reply to this post by back2dos
Thanks for taking the time to share your knowledge with me.

Replying to this post:
http://lists.motion-twin.com/pipermail/haxe/2010-February/033353.html

[snip...8<....]

>> Also, why does
>> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
>> given that std.Neko.Lib.load() does cast and return a tfunction to a
>> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>>
> yes, this is very strange. it should only throw an exception for
> tabstract and simply return the original value for tfunction.

Thanks for confirming it is a bug.  I don't know where to report HaXe
bugs.  I am not set up to edit sources and build HaXe yet.

[snip...8<....]

>> Appears that std.neko.net.Socket (thus also haxe.Http and
>> haxe.remoting.*)
>> is not asynchronous and instead uses chunked reading with a connection
>> timeout.  How to create robust real-time online applications that can
>> handle persistantly slow connections on Neko?  Whereas, I see that async
>> callback is supported for Javascript in haxe.Http, haxe.remoting.*, and
>> onreadystatechange callback in js.XMLHttpRequest.
>>
> if you do not want to wait for the socket, start a background thread to
> do that.

Ah yes.  Thanks.

Someone could build that into the haxe.Http and haxe.remoting.*, to
correctly support the asynchronous callbacks that already exist in those
APIs.  Imho, that would be more elegant.


>> I have started to work on my own new HaXe-like (static+dynamic typing)
>> language initially targetting Neko, primarily because there was no
>> response to the question about Neko to HaXe callbacks.
>>
>> I would prefer to focus my efforts on HaXe (the concept of
>> static+dynamic
>> is awesome)

[snip...8<....]

> haXe doesn't have a concept of static+dynamic. haXe is completely static.
> haXe target platforms are dynamic and the dynamic features can be used
> when bypassing the static type-system.
> dynamic behaviour is always platform specific.

Agreed that is one valid perspective, but HaXe also supports the dynamic
capability (e.g. unlimited .fields) on platforms which are not natively
dynamic (e.g. C++).  And it is my understanding that the dynamic
capability is not different on each platform?  Can you enumerate any
aspects of the dynamic which varies on platforms?  Please distinguish from
'untyped'.

I do not understand what 'untyped' does?  I keep asking but do not get a
straight and complete explanation.  Does 'untyped' passthrough the code to
the platform (C++ code?)?  Or is 'untyped' referring to magic in the
gen*.ml layer of the HaXe compiler?  It would really help me if someone
could explain 'untyped' more.

Thus (other than 'untyped'), 'dynamic' is a fine grained way to opt out of
type checking and thus I view HaXe as static+dynamic typing language.  And
I think that is really cool feature, because 80% of the code (prototyping
which we never end up needing to make faster) is dynamic and 20% of it
needs to be fully typed, especially the public interfaces and code we need
to go faster (but not fast enough to bother with C code).  I actually
think the one minor mistake in the design of HaXe (which I am planning to
correct now) is that the verbosity should be optimized for the dynamic
case, because it is the most frequent case.  The static typing is
optimized for correctness (am planning to fix a few OOP items there also)
and speed.  That is the 80/20 combination and again I think it is really
cool concept.

Like most of you, what initially made me aware of HaXe in Oct 2008 was I
needed a quick and free way to test out some Flash/AS3 code (highly
optimized and OOP JPEG encoded and decoder I wrote, which I will get
around to open sourcing).  I saw immediately the potential for HaXe:

http://lists.motion-twin.com/pipermail/haxe/2008-November/020935.html

On Nov. 25, 2008, Shelby Moore wrote:
"Agreed for small enough programs (and I share your enthusiam about the
breathe of fresh air going from C++ to dynamically typed languages), but
as diversity of integration rises, then along the outer perimeter of what
one small group/programmer(s) controls intimately, then then the static
typing afaics will become more critical.

A (my) vision for the Web3.0 is one of massively parallel collaboration
and integration at programming level, i.e. Remoting not just to the server
but between P2P clients (imho the server must die and become
distributed...this is a deep topic...).  It is a bigger vision than my own
personal coding efficiency on my own personal (smaller economy-of-scale)
projects that I entirely control"

But got sidetracked on other things for past year, and only now it is
coming crystal clear to me that bigger role for HaXe (or something like
it) and how to achieve it (an important cog in a bigger plan).  And the
reason I mention that, is that it shows we need other avenues (than Flash)
to bring HaXe to the attention of the world.  HaXe community has been
focused on output targets.  They did not target the browser itself (not
the web page but the browser extension).  I know what to do.  My
CoolPage.com had million downloads (confirm at download.com) back in the
late 90s of free Yahoo Geocities (when million was a huge number), before
MySpace and Friendster existed.


[snip...8<....]

>> ...It appears that the only difference between HaXe function and
>> Neko
>> tfunction, is the arguments and return value have to converted with
>> haxeToNeko() <--> nekoToHaxe()?  Thus callbacks are feasible now?
>>
> yes, callbacks between haXe and neko are possible. you do not need to
> convert values between haXe and neko.
> The only two differences between haXe and neko are strings and arrays.
> In the haXe world, neko arrays and strings are NativeArray and
> NativeString.
> In the neko world, haXe arrays and strings are objects referencing the
> underlying value and using neko VM operator overloading
> (http://nekovm.org/specs#operators_overloading) to behave as native
> arrays and strings.


Ah interesting.  Why does the array access need to be overloaded?  Is that
just to support dynamic array resizing or is there more going on?

[snip...8<....]

> as already stated, you can use --neko-source as documented in
> http://haxe.org/doc/compiler

Please excuse me for missing that.  A senior moment (at 44.5).

> also you may want to have a look at the neko builtins
> http://nekovm.org/doc/view/builtins.

Agreed, I had viewed that page.

> I found it quite revealing and
> helpful for understanding neko.
> however I don't understand what you're up to.
> vtables and prototypes are completely unrelated. a prototype object is a
> regular first class object that lookups of undefined properties are
> forwarded to.

They are two possible ways of implementing HaXe class methods on Neko.
The vtable is faster, but the prototype would be easier to interopt with
and document perhaps.  And a hash table (prototype) inheritance would be
trivial to cast to its component HaXe 'inferface's.  If you are not
following me how HaXe classes could be implemented with prototypes, then
we could take it off list to discuss, but I doubt it is really important.
I just need to know the format that HaXe is using for its implementation
on Neko, and I assume it is using vtables since HaXe is prioritizing speed
(especially on Neko).


>> Tangentially if I proceed on my own language, I would eliminate virtual
>> methods (override) as it semantically subverts static typing (and
>> virtual
>> inheritance is unnecessary when interface is available):
>>
>> http://lists.motion-twin.com/pipermail/neko/2010-January/002717.html
>>
>> I also realized that the keywords 'interface' and 'implements' are
>> unnecessary, as any class with partial implementation could be construed
>> to be an interface (and thus can not be instantiated).  This would add
>> the
>> feature of partial implementation of interfaces.

Note I corrected and amended the above here:

http://lists.motion-twin.com/pipermail/haxe/2010-February/033343.html

> haXe targets platforms such as the AVM2. The AVM2 allows classes to
> extend one superclass and to implement multiple interfaces.
> Anything else will probably throw a VerifyError when booting.
> As long as haXe will try to stay compatible with the native languages fo
> targets like these, it will always be very limited.
> People prefer the idea of being able to interoperate with AS3 as good as
> possible, to that of having more sensible semantics brought to haXe.
> Looking at the current usage of haXe and that of AS3, I think they have
> a point.

I can build a language on top of HaXe to give me what I want, so I (and
anyone who wants same) do not have to interfere with HaXe's priorities:

http://lists.motion-twin.com/pipermail/haxe/2010-February/033355.html

In that way, it is win-win and we both help build market share for each
other.  And it helps when I read your perspective.

[snip...8<....]

>> Additional HaXe issues I think can be improved:
>>
>> 1. Class variables types are not inferred from the constructor:
>>
>> http://haxe.org/ref/oop
>>
> that'd be nice to have actually. i guess it's not obvious to do.

So far, I can not envision why not.  The hierarchy should be in the AST.
I am planning to do it if HaXe does not first.

> also,
> you may not choose to initialize some variables in the constructor and
> the question is, what to do then.

Output a compiler error saying that variable must be typed.


>> 2. Dynamic types must be declared and can not be inferred:
>>
>> var o : Dynamic = {};
>>
>> Or:
>>
>> class Object implements Dynamic {};
>> var o = new Object();
>>
>> The following will not infer a dynamic object with unlimited fields,
>> because it is inferred to be an Anonymous/Structural static type (
>> http://haxe.org/ref/type_advanced ):
>>
>> var o = {};
>> var oo = { x : 1, y : 2 };
>>
>> Given preference for dynamic typing when execution speed is less
>> important
>> than programming speed (which is 80% of the time in my experience), I
>> would prefer the less verbose default to infer Dynamic when assigning
>> {...} and add a Static type (which means "the type as inferred", so only
>> needs to be used for {...} and does nothing on cast).  I would not
>> change
>> class to be Dynamic by default.  Untyped block is not a lower verbosity
>> solution because it applies to everything in the block, and thus untyped
>> has to be repeated perhaps at every var declaration.  Low verbosity is
>> one
>> of the significant reasons why dynamic coding is more readable and thus
>> faster coding and learning/studying code.
>>
> it is not a haXe but a platform feature that anonymous objects actually
> may have unlimited fields.


Are you sure?  That seems to disagree with the documentation:

http://haxe.org/ref/dynamic

So C++ does not support unlimited fields on Dynamic?  Bummer.  It means
HaXe code breaks on C++.  Imo, that will need to be fixed.

> that's exactly why you require untyped.

There seems to be great confusion about the semantics of untyped.  I still
don't understand what you mean in this context for untyped.

> a backend could just as well decide to compile an anonymous object into
> "sealed" objects.

The documentation does not say that.

> using anonymous objects as a hashes is wrong use.
> if you look at good
> cross-platfrom projects such as hscript, you will realize people always
> use Hash instead.
>
> anonymous objects are anonymous objects and hashes are hashes. the
> former are entities or at least records, the latter are collections.
> throwing them all together doesn't make code better, clearer or easier
> to understand or study.


A counter-point to that logic above is that calling std.Hash<String>
methods is much more verbose than . and bracket ["string"] access.  Look
at my example comparison code in the links I provided (it is a big
difference in readability and comprehension).  Coding efficiency and
readability is more important for getting work done, which is an often
stated reason why Python is so popular.  Why not have both cross-platform
and minimum verbosity?  Why force a sacrifice that can be avoided?

I do not understand why an anonymous object is not also a hashed
collection?  As a matter of fact it is on dynamic platforms (although
Javascript does not provide map&every methods on Object, only on Array,
but these can be easily added, and does provide for(in) and PHP provides
foreach), and no reason HaXe can't emulate it on platforms where it is
not.

The single most important rule for making things popular is K.I.S.S and
low verbosity is one aspect of lower complexity.  (which is probably why
my posts are less popular <big grin>).  Put the complexity behind HaXe at
the implementation layer, not in front of it in the programmers eyeballs.

Any way, no need to argue, when I can create my own language and HaXe can
do things its way, so that we can compete for market share in win-win
manner of helping each other.  Nevertheless I am interested to learn more
about your rationale, in case I might adopt your stance.


> also, I don't see why programming speed is faster if everything is
> dynamic.
> most of the overhead required by popular statically typed languages is
> completely reduced in haXe through type inference.


Agreed type inference helps a lot, but I am just pointing a few
suggestions to further decrease the verbosity in HaXe.  And type inference
is an example of 80% of code being untyped and only 20% being typed,
notwithstanding the coolness that the types propogate via inference.


> and there is little if any programming speed benefit in letting
> anonymous objects be dynamic. it's more of a good way to shoot yourself
> in the foot.

Can you explain to me why?  I noted above the method calls on a hash are
much more verbose.  If you prefer to overload . and [] on a Hash class, I
am agreeable.  Whether you call it a Hash or an anonymouse object, I want
the low verbosity result is the same.  Also instantiating the anonymous
object should ideally be low verbosity, since these are used often.


>> 3. Non-static class method can not be curried type safely (
>> http://haxe.org/ref/callback ) in following case, because there is no
>> way
>> to use callback() to curry the following:
>>
>> Lambda.map( ['string1','string2'], function( s ) { return s.charAt( 3 );
>> } );
>>
> it'd be cool if this worked with callback somehow, yet it's a little
> hard to imagine.
> could you provide an example of how you would like this to work?

Exactly the same syntax as now:

Lambda.map( ['string1','string2'], callback( String.charAt, 3 ); );

callback (a compiled keyword) should be smart enough (has access to the
AST) to know at compile tie that charAt is a non-static method and so it
will return a function whose first argument is the obj to the apply to the
method.


>> 4. Dynamic fields can not be accessed with bracket syntax
>> instance[String], instead must either use verbose Reflect api for or
>> wrap
>> the code in 'untyped':
>>
> why should they be?

To reduce verbosity for accessing unlimited fields.

> it's arguable whether ArrayAccess<T> shouldn't rather be
> ArrayAccess<K,T> but that'd be quite hard on some platforms.
> ArrayAccess is a marker implying that the specified object supports
> Array access on the native platform.
> Array access is compiled to native array access on all platforms except
> C++.
> Nonetheless, lookup of values by keys from a collection is not
> semantically equivalent with a lookup of property by name from an object,
> so it's not really clear to me, why it should be using the same syntax.


Irregardless whether one has the opinion that property is not semantically
the same as as key in a hash table, I offer the point to make property
access by string variable as low verbosity as possible.  Conceptually it
is an overloading of the . and [] operators.

[snip...8<....]

>> I do not understand what 'untyped' does.  Is 'untyped' code passed
>> through
>> unaltered to the implementation layer, thus give different semantics on
>> different platforms?
>>
> yes, it does give different semantics on different platforms. as far as
> I know, it isn't necessarily passed through
> unaltered (altough this is the case for most platforms).

Thanks and still I do not have a concrete specification of what untyped
does.  I wonder who knows?  Seems so far like a hacky feature that will
cause problems.  I don't even know what it is doing when I read code in
the libraries.  Would be better to replace with something that has well
defined semantics.

[snip...8<....]

> I agree haXe is not very consistent with nullability in many ways.
> Also, I find it strange that Null<SomeEnum> cannot be matched against
> null in switch statements.

I didn't know that.  Thanks.

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

Re: HaXe or a new language?

Shelby Moore
Let me be more mathematical and explicit.

>> also, I don't see why programming speed is faster if everything is
>> dynamic.
>> most of the overhead required by popular statically typed languages is
>> completely reduced in haXe through type inference.
>
>
> Agreed type inference helps a lot, but I am just pointing a few
> suggestions to further decrease the verbosity in HaXe.  And type inference
> is an example of 80% of code being untyped and only 20% being typed,
> notwithstanding the coolness that the types propogate via inference.

Note I wrote "80% of code being untyped", not "80% of code being dynamic".

Point being that give the 80/20 rule of nature, 80% of dynamic code is not
dynamic, just not explicitly typed.  And 80% of typed code need not be
explicitly typed.

HaXe is optimized for that overlap.  It is the 20% of dynamic code that I
am trying to make less verbose, because it occurs 80% of time or 4x more
frequently than the typed cases.

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

Re: HaXe or a new language?

Tony Polinelli
>HaXe is optimized for that overlap.  It is the 20% of dynamic code that I
>am trying to make less verbose, because it occurs 80% of time or 4x more
>frequently than the typed cases.

hah - do you have any pie graphs or spreadsheets which track these
percentages? ;P



On Tue, Feb 2, 2010 at 4:12 PM, Shelby Moore <[hidden email]> wrote:

> Let me be more mathematical and explicit.
>
>>> also, I don't see why programming speed is faster if everything is
>>> dynamic.
>>> most of the overhead required by popular statically typed languages is
>>> completely reduced in haXe through type inference.
>>
>>
>> Agreed type inference helps a lot, but I am just pointing a few
>> suggestions to further decrease the verbosity in HaXe.  And type inference
>> is an example of 80% of code being untyped and only 20% being typed,
>> notwithstanding the coolness that the types propogate via inference.
>
> Note I wrote "80% of code being untyped", not "80% of code being dynamic".
>
> Point being that give the 80/20 rule of nature, 80% of dynamic code is not
> dynamic, just not explicitly typed.  And 80% of typed code need not be
> explicitly typed.
>
> HaXe is optimized for that overlap.  It is the 20% of dynamic code that I
> am trying to make less verbose, because it occurs 80% of time or 4x more
> frequently than the typed cases.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Tony Polinelli
http://touchmypixel.com

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

Re: HaXe or a new language?

Shelby Moore
>>HaXe is optimized for that overlap.  It is the 20% of dynamic code that I
>>am trying to make less verbose, because it occurs 80% of time or 4x more
>>frequently than the typed cases.

Make that "than the EXPLICITLY typed cases".

>
> hah - do you have any pie graphs or spreadsheets which track these
> percentages? ;P

Apple or pecan? ;)

100% is less arbitrary.

Type inference in theory enables one to 100% minimize verbosity of
explicit typing (down to the minimum number of explicit declarations
needed to constrain the types of all the untyped).  I am just trying to
see if we can get 100% minimization of verbosity (e.g. explicit 'dynamic'
type declarations) with the dynamic case.

Perhaps some have the perspective that HaXe is only a typed language and
that the dynamic features of the language are not the main focus and
should not be given priority.  I take the view that both the typed
features of the HaXe (or if not HaXe then a new language) and the dynamic
features of the language are important.  I will take type inference when
it doesn't cost me anything or I need it.  And other times I will take
dynamic capability because it helps me code faster and more
elegantly/comprehensibly.  Some camps have the view that everything type
checked and semantically orthogonal (e.g. hash key vs. property) gives the
most coherence and re-use.  For me it varies according to the situation.
I want optimization of both coding styles, if possible in one language so
I don't have to constantly switch entire toolsets, thinking modes, and
interoption issues.  People will use both and demand the best tools for
each case.  For me what made HaXe unique was not just the type inference
for static typing, but also the ability to combine static and dynamic
typing.  And that it targets Neko, which imho has the correct low
complexity model for potential language interoperability.  Also that it
targets other platforms/languages.  All of these aspects combine to give
maximum possibilities to prevent code being trapped and effort being
wasted.

I look for unifying technologies that increase diversity.  The key to
making them popular is to make them simple and intuitive.  Right now there
are aspects of the HaXe dynamic code cases which are not untuitive as
using Javascript.  That is the bar I measure against, since it is a
massively popular language.

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

Re: HaXe or a new language?

Shelby Moore
In reply to this post by Shelby Moore
> Lambda.map( ['string1','string2'], callback( String.charAt, 3 ); );
>
> callback (a compiled keyword) should be smart enough (has access to the
> AST) to know at compile tie that charAt is a non-static method and so it
> will return a function whose first argument is the obj to the apply to the
> method.

This is a case where statically (compile time) typed coding will be less
verbose than dynamic, because the compiler can infer for example that
Math.* are static methods and String.charAt is not.

Whereas for dynamic case, we will either need a separate function for each
case (e.g. callback1 and callback2), or we need callback to check if its
first argument is a string, then pass methods as callback( 'method',
object, ... ) and functions as callback( function, ... ).

Also for the static typed case above, the compiler can detect the type of
the function the return value of callback is being assigned to (e.g. if
first argument of Lambda.map() is array of Dynamic), and then provide a
matching function and either issue a compiler error or automatically cast
the value where appropriate, e.g.:

return function( Dynamic d ) { String s = cast d; s.charAt( 3 ); }

Does HaXe automatically cast Dynamic to any type?  Or does the programmer
have to explicitly cast to avoid a compiler error?  Perhaps it should be a
compiler option (flag).  Personally I would favor automatic cast (lower
verbosity so do not have to cast the return value from callback to Void ->
Dynamic), because the whole point of Dynamic is that the programmer is
taking responsibility for the typing errors and letting the runtime
exceptions (and unit testing) catch mistakes.

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