Compiler syntax parsing error?

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

Compiler syntax parsing error?

Armén
Having a type parametrized class with a static function makes it
impossible to call said function.

class A<T>
{
     public static function f()
     {
     }
}

A<Int>.f();

The above call results in compiler error "Unexpected ."

According to my logic, the type parameter is specified, so the class
is instantiated (and thus deduced), so the call should be a
no-problem, right?

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

Re: Compiler syntax parsing error?

Armén
Disregarding the less obvious (and less beautiful) solution to the
above, where one can simply typedef the parametrized class template
and use the typedef like:

<code>

typedef A_Int = A<Int>;

//...

A_Int.f();

</code>

...I am also finding some more weirdness. First of all, static
functions do not see or recognise the class type parameter for one
reason or another, i. e. inserting a reference to type parameter T in
function body results in compiler complaining class not found:

class A<T>
{
     public static function f()
     {
          var v: T;
     }
}

Umm, if according to Nicolas the compiler substitutes all references
to T with references to actual types being used, this should not be a
problem.

On Tue, Jun 23, 2009 at 14:15, [hidden email]<[hidden email]> wrote:

> Having a type parametrized class with a static function makes it
> impossible to call said function.
>
> class A<T>
> {
>     public static function f()
>     {
>     }
> }
>
> A<Int>.f();
>
> The above call results in compiler error "Unexpected ."
>
> According to my logic, the type parameter is specified, so the class
> is instantiated (and thus deduced), so the call should be a
> no-problem, right?
>

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

Re: Re: Compiler syntax parsing error?

Gamehaxe
Hi,
The type parameterisation in haxe is not actually
like c++ templates.  Think of it only as "type checking".


  class A<T>
  {
       // t must be a super class of T
       public static function a(t:T) {  }
  }

// Something must have field "x" that is an int
A< {x:Int} >.a(something)

but haxe does not like:

public static function f()  {  var v: T;  }

because it can only *check* the type of v, not create
a variable of type T.

Hugh






> Disregarding the less obvious (and less beautiful) solution to the
> above, where one can simply typedef the parametrized class template
> and use the typedef like:
>
> <code>
>
> typedef A_Int = A<Int>;
>
> //...
>
> A_Int.f();
>
> </code>
>
> ...I am also finding some more weirdness. First of all, static
> functions do not see or recognise the class type parameter for one
> reason or another, i. e. inserting a reference to type parameter T in
> function body results in compiler complaining class not found:
>
> class A<T>
> {
>      public static function f()
>      {
>           var v: T;
>      }
> }
>
> Umm, if according to Nicolas the compiler substitutes all references
> to T with references to actual types being used, this should not be a
> problem.
>
> On Tue, Jun 23, 2009 at 14:15, [hidden email]<[hidden email]>  
> wrote:
>> Having a type parametrized class with a static function makes it
>> impossible to call said function.
>>
>> class A<T>
>> {
>>     public static function f()
>>     {
>>     }
>> }
>>
>> A<Int>.f();
>>
>> The above call results in compiler error "Unexpected ."
>>
>> According to my logic, the type parameter is specified, so the class
>> is instantiated (and thus deduced), so the call should be a
>> no-problem, right?
>>
>
> --
> 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: Re: Compiler syntax parsing error?

Armén
> but haxe does not like:
>
> public static function f()  {  var v: T;  }
>
> because it can only *check* the type of v, not create
> a variable of type T.
>

Umm, i am not asking haXe to create a variable of type T, I am asking
it to recognize the scope and validity of identifier T, which is
defined in class declaration as a type parameter, and is thus valid
and identifiable for function 'f' and within its body. Obviously
calling static function of a instantiated class A<Int> implies that T
refers to the 'Int' type, also for static functions. This has nothing
to do with C++ templates.

By the way, if you remove 'static' modifier, suddenly haXe comes to
senses and recognizes T just fine.

Also, for what its worth, even though indeed there are some minor
differences between C++ templates and type parameters, essentially
these are the same concepts. I invite you and everybody else to show
me functional differences. As far as I am concerned there are none
functionally substantial. Difference in syntax does not count
obviously.

Well, I may be ignorant and I know I am cocky, but is asking haXe to
follow my logic too much? Must I follow haxes logic instead? All I
want is a more or less generic function.

On Tue, Jun 23, 2009 at 14:59, Hugh Sanderson<[hidden email]> wrote:

> Hi,
> The type parameterisation in haxe is not actually
> like c++ templates.  Think of it only as "type checking".
>
>
>  class A<T>
>  {
>      // t must be a super class of T
>      public static function a(t:T) {  }
>  }
>
> // Something must have field "x" that is an int
> A< {x:Int} >.a(something)
>
> but haxe does not like:
>
> public static function f()  {  var v: T;  }
>
> because it can only *check* the type of v, not create
> a variable of type T.
>
> Hugh
>
>
>
>
>
>
>> Disregarding the less obvious (and less beautiful) solution to the
>> above, where one can simply typedef the parametrized class template
>> and use the typedef like:
>>
>> <code>
>>
>> typedef A_Int = A<Int>;
>>
>> //...
>>
>> A_Int.f();
>>
>> </code>
>>
>> ...I am also finding some more weirdness. First of all, static
>> functions do not see or recognise the class type parameter for one
>> reason or another, i. e. inserting a reference to type parameter T in
>> function body results in compiler complaining class not found:
>>
>> class A<T>
>> {
>>     public static function f()
>>     {
>>          var v: T;
>>     }
>> }
>>
>> Umm, if according to Nicolas the compiler substitutes all references
>> to T with references to actual types being used, this should not be a
>> problem.
>>
>> On Tue, Jun 23, 2009 at 14:15, [hidden email]<[hidden email]>
>> wrote:
>>>
>>> Having a type parametrized class with a static function makes it
>>> impossible to call said function.
>>>
>>> class A<T>
>>> {
>>>     public static function f()
>>>     {
>>>     }
>>> }
>>>
>>> A<Int>.f();
>>>
>>> The above call results in compiler error "Unexpected ."
>>>
>>> According to my logic, the type parameter is specified, so the class
>>> is instantiated (and thus deduced), so the call should be a
>>> no-problem, right?
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
>
> --
> 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: Compiler syntax parsing error?

Nicolas Cannasse
In reply to this post by Armén
[hidden email] a écrit :

> Having a type parametrized class with a static function makes it
> impossible to call said function.
>
> class A<T>
> {
>      public static function f()
>      {
>      }
> }
>
> A<Int>.f();
>
> The above call results in compiler error "Unexpected ."

Class type parameters only work for classes instances, they can't be
used in class statics. This is mainly because the following have no
meaning :

class A<T> {
     static var foo : T;
}

Since there's only one class A , and then only one "foo" variable.
You can instead use function type parameters in statics :

static function foo<T>( x : T ) : T {
    return x;
}

Nicolas

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

Re: Compiler syntax parsing error?

Armén
Thanks, Nicolas. That clears it up. I guess in haXe, templates just
dont exist. Fine, I eat my hat and apologize to Hugh for calling haxe
param-types templates.

How do you call that static function by the way?

I can see that haXe does not like a f<Int> call syntax for instance.
THis means that the T has to be deduced otherwise, possibly as a
regular function argument type, like f(v) where v is Int, so that haXe
locks T to be Int? Am I making sense here?

On Tue, Jun 23, 2009 at 23:02, Nicolas
Cannasse<[hidden email]> wrote:

> [hidden email] a écrit :
>>
>> Having a type parametrized class with a static function makes it
>> impossible to call said function.
>>
>> class A<T>
>> {
>>     public static function f()
>>     {
>>     }
>> }
>>
>> A<Int>.f();
>>
>> The above call results in compiler error "Unexpected ."
>
> Class type parameters only work for classes instances, they can't be used in
> class statics. This is mainly because the following have no meaning :
>
> class A<T> {
>    static var foo : T;
> }
>
> Since there's only one class A , and then only one "foo" variable.
> You can instead use function type parameters in statics :
>
> static function foo<T>( x : T ) : T {
>   return x;
> }
>
> 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: Compiler syntax parsing error?

David Bergman
On Jun 23, 2009, at 6:27 PM, [hidden email] wrote:

> Thanks, Nicolas. That clears it up. I guess in haXe, templates just
> dont exist. Fine, I eat my hat and apologize to Hugh for calling haxe
> param-types templates.

Templates (or generics...) do exist in haXe, but as in Java, they are  
compile-time only, so all instantiations (i.e., concrete types) of A  
below will use the same static properties. This is a good thing, since  
that allow us to map one type to one type in the target environment,  
which makes runtime behavior a bit more predictable, compared to  
having to basically do what CFront did: mangle the names into new  
unique types, such as

        A<Int>  ===>   class A_int
        A<String> ===> class A_string

/David


> How do you call that static function by the way?
>
> I can see that haXe does not like a f<Int> call syntax for instance.
> THis means that the T has to be deduced otherwise, possibly as a
> regular function argument type, like f(v) where v is Int, so that haXe
> locks T to be Int? Am I making sense here?
>
> On Tue, Jun 23, 2009 at 23:02, Nicolas
> Cannasse<[hidden email]> wrote:
>> [hidden email] a écrit :
>>>
>>> Having a type parametrized class with a static function makes it
>>> impossible to call said function.
>>>
>>> class A<T>
>>> {
>>>     public static function f()
>>>     {
>>>     }
>>> }
>>>
>>> A<Int>.f();
>>>
>>> The above call results in compiler error "Unexpected ."
>>
>> Class type parameters only work for classes instances, they can't  
>> be used in
>> class statics. This is mainly because the following have no meaning :
>>
>> class A<T> {
>>    static var foo : T;
>> }
>>
>> Since there's only one class A , and then only one "foo" variable.
>> You can instead use function type parameters in statics :
>>
>> static function foo<T>( x : T ) : T {
>>   return x;
>> }
>>
>> Nicolas
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> 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: Compiler syntax parsing error?

Nicolas Cannasse
In reply to this post by Armén
[hidden email] a écrit :

> Thanks, Nicolas. That clears it up. I guess in haXe, templates just
> dont exist. Fine, I eat my hat and apologize to Hugh for calling haxe
> param-types templates.
>
> How do you call that static function by the way?
>
> I can see that haXe does not like a f<Int> call syntax for instance.
> THis means that the T has to be deduced otherwise, possibly as a
> regular function argument type, like f(v) where v is Int, so that haXe
> locks T to be Int? Am I making sense here?

Yes, it's using haXe type inference.

Nicolas

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

Re: Compiler syntax parsing error?

Armén
In reply to this post by David Bergman
No, incorrect. That is exactly what is NOT happening in haXe. That is
why I backed down on my statement. If A<Int> becomes one runtime
class, and A<String> becomes another, then the following should have
worked (which does not):

class A<T>
{
     public static function f()
     {
          var foo: T = new T();
     }
}

If A for each type T becomes own class, then there exists a finite
permutation (instantiation) of function f, each with a variable
initialization of type T. Nicolas stated that "Since there's only one
class A , and then only one "foo" variable". This is why I said haXe
type parameters are NOT templates, because if they were, we would have
a class for each type T. Maybe we do, but then a question to Nicolas
is why does he say "there is only one class A"? If there is one class,
I understand that one cannot have more than one static function with a
single variable type, but if we are having A_Int and A_String
instantiation then either can have their own local variable
initialization in their respective static function 'f'.


On Wed, Jun 24, 2009 at 01:15, David
Bergman<[hidden email]> wrote:

> On Jun 23, 2009, at 6:27 PM, [hidden email] wrote:
>
>> Thanks, Nicolas. That clears it up. I guess in haXe, templates just
>> dont exist. Fine, I eat my hat and apologize to Hugh for calling haxe
>> param-types templates.
>
> Templates (or generics...) do exist in haXe, but as in Java, they are
> compile-time only, so all instantiations (i.e., concrete types) of A below
> will use the same static properties. This is a good thing, since that allow
> us to map one type to one type in the target environment, which makes
> runtime behavior a bit more predictable, compared to having to basically do
> what CFront did: mangle the names into new unique types, such as
>
>        A<Int>  ===>   class A_int
>        A<String> ===> class A_string
>
> /David
>
>
>> How do you call that static function by the way?
>>
>> I can see that haXe does not like a f<Int> call syntax for instance.
>> THis means that the T has to be deduced otherwise, possibly as a
>> regular function argument type, like f(v) where v is Int, so that haXe
>> locks T to be Int? Am I making sense here?
>>
>> On Tue, Jun 23, 2009 at 23:02, Nicolas
>> Cannasse<[hidden email]> wrote:
>>>
>>> [hidden email] a écrit :
>>>>
>>>> Having a type parametrized class with a static function makes it
>>>> impossible to call said function.
>>>>
>>>> class A<T>
>>>> {
>>>>    public static function f()
>>>>    {
>>>>    }
>>>> }
>>>>
>>>> A<Int>.f();
>>>>
>>>> The above call results in compiler error "Unexpected ."
>>>
>>> Class type parameters only work for classes instances, they can't be used
>>> in
>>> class statics. This is mainly because the following have no meaning :
>>>
>>> class A<T> {
>>>   static var foo : T;
>>> }
>>>
>>> Since there's only one class A , and then only one "foo" variable.
>>> You can instead use function type parameters in statics :
>>>
>>> static function foo<T>( x : T ) : T {
>>>  return x;
>>> }
>>>
>>> Nicolas
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> 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: Compiler syntax parsing error?

Tony Polinelli-2
I think the thing is that it is only at compiletime that the typing occurs. At runtime there is indeed only one instance of A afaik

 

On Wed, Jun 24, 2009 at 6:19 PM, [hidden email] <[hidden email]> wrote:
No, incorrect. That is exactly what is NOT happening in haXe. That is
why I backed down on my statement. If A<Int> becomes one runtime
class, and A<String> becomes another, then the following should have
worked (which does not):

class A<T>
{
    public static function f()
    {
         var foo: T = new T();
    }
}

If A for each type T becomes own class, then there exists a finite
permutation (instantiation) of function f, each with a variable
initialization of type T. Nicolas stated that "Since there's only one
class A , and then only one "foo" variable". This is why I said haXe
type parameters are NOT templates, because if they were, we would have
a class for each type T. Maybe we do, but then a question to Nicolas
is why does he say "there is only one class A"? If there is one class,
I understand that one cannot have more than one static function with a
single variable type, but if we are having A_Int and A_String
instantiation then either can have their own local variable
initialization in their respective static function 'f'.


On Wed, Jun 24, 2009 at 01:15, David
Bergman<[hidden email]> wrote:
> On Jun 23, 2009, at 6:27 PM, [hidden email] wrote:
>
>> Thanks, Nicolas. That clears it up. I guess in haXe, templates just
>> dont exist. Fine, I eat my hat and apologize to Hugh for calling haxe
>> param-types templates.
>
> Templates (or generics...) do exist in haXe, but as in Java, they are
> compile-time only, so all instantiations (i.e., concrete types) of A below
> will use the same static properties. This is a good thing, since that allow
> us to map one type to one type in the target environment, which makes
> runtime behavior a bit more predictable, compared to having to basically do
> what CFront did: mangle the names into new unique types, such as
>
>        A<Int>  ===>   class A_int
>        A<String> ===> class A_string
>
> /David
>
>
>> How do you call that static function by the way?
>>
>> I can see that haXe does not like a f<Int> call syntax for instance.
>> THis means that the T has to be deduced otherwise, possibly as a
>> regular function argument type, like f(v) where v is Int, so that haXe
>> locks T to be Int? Am I making sense here?
>>
>> On Tue, Jun 23, 2009 at 23:02, Nicolas
>> Cannasse<[hidden email]> wrote:
>>>
>>> [hidden email] a écrit :
>>>>
>>>> Having a type parametrized class with a static function makes it
>>>> impossible to call said function.
>>>>
>>>> class A<T>
>>>> {
>>>>    public static function f()
>>>>    {
>>>>    }
>>>> }
>>>>
>>>> A<Int>.f();
>>>>
>>>> The above call results in compiler error "Unexpected ."
>>>
>>> Class type parameters only work for classes instances, they can't be used
>>> in
>>> class statics. This is mainly because the following have no meaning :
>>>
>>> class A<T> {
>>>   static var foo : T;
>>> }
>>>
>>> Since there's only one class A , and then only one "foo" variable.
>>> You can instead use function type parameters in statics :
>>>
>>> static function foo<T>( x : T ) : T {
>>>  return x;
>>> }
>>>
>>> Nicolas
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
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: Compiler syntax parsing error?

Nicolas Cannasse
Tony Polinelli a écrit :
> I think the thing is that it is only at compiletime that the typing
> occurs. At runtime there is indeed only one instance of A afaik

It might depend on the platform support for generics, but this should
not make any difference.

Nicolas

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

Re: Compiler syntax parsing error?

Armén
What if one implements the haxe.rtti.Generic interface? Would that
have haXe generate a separate class for each inferred/specified type
T?

On Wed, Jun 24, 2009 at 10:31, Nicolas
Cannasse<[hidden email]> wrote:

> Tony Polinelli a écrit :
>>
>> I think the thing is that it is only at compiletime that the typing
>> occurs. At runtime there is indeed only one instance of A afaik
>
> It might depend on the platform support for generics, but this should not
> make any difference.
>
> 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: Compiler syntax parsing error?

Nicolas Cannasse
[hidden email] a écrit :
> What if one implements the haxe.rtti.Generic interface? Would that
> have haXe generate a separate class for each inferred/specified type
> T?

Yes, this is how it works.

But even when you are actually using different classes for instances,
you still have one single Class object which contains static variables
and functions.

Think about it like :

class A<T> {
     static function foo() {}
     var x : T;
}

is seperated into :

class A {
     static function foo() {}
}

class A_Int {
    var x : Int;
}

class A_String {
    var x : String;
}

...

Nicolas

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

Re: Compiler syntax parsing error?

David Bergman
In reply to this post by Armén
On Jun 24, 2009, at 4:19 AM, [hidden email] wrote:

> No, incorrect.

Read my post again, please. I said that it is *one* class in runtime,  
and why that is better, *compared* to creating various classes  
(through the CFront-type name mangling)

...

/David



> That is exactly what is NOT happening in haXe. That is
> why I backed down on my statement. If A<Int> becomes one runtime
> class, and A<String> becomes another, then the following should have
> worked (which does not):
>
> class A<T>
> {
>     public static function f()
>     {
>          var foo: T = new T();
>     }
> }
>
> If A for each type T becomes own class, then there exists a finite
> permutation (instantiation) of function f, each with a variable
> initialization of type T. Nicolas stated that "Since there's only one
> class A , and then only one "foo" variable". This is why I said haXe
> type parameters are NOT templates, because if they were, we would have
> a class for each type T. Maybe we do, but then a question to Nicolas
> is why does he say "there is only one class A"? If there is one class,
> I understand that one cannot have more than one static function with a
> single variable type, but if we are having A_Int and A_String
> instantiation then either can have their own local variable
> initialization in their respective static function 'f'.
>
>
> On Wed, Jun 24, 2009 at 01:15, David
> Bergman<[hidden email]> wrote:
>> On Jun 23, 2009, at 6:27 PM, [hidden email] wrote:
>>
>>> Thanks, Nicolas. That clears it up. I guess in haXe, templates just
>>> dont exist. Fine, I eat my hat and apologize to Hugh for calling  
>>> haxe
>>> param-types templates.
>>
>> Templates (or generics...) do exist in haXe, but as in Java, they are
>> compile-time only, so all instantiations (i.e., concrete types) of  
>> A below
>> will use the same static properties. This is a good thing, since  
>> that allow
>> us to map one type to one type in the target environment, which makes
>> runtime behavior a bit more predictable, compared to having to  
>> basically do
>> what CFront did: mangle the names into new unique types, such as
>>
>>        A<Int>  ===>   class A_int
>>        A<String> ===> class A_string
>>
>> /David
>>
>>
>>> How do you call that static function by the way?
>>>
>>> I can see that haXe does not like a f<Int> call syntax for instance.
>>> THis means that the T has to be deduced otherwise, possibly as a
>>> regular function argument type, like f(v) where v is Int, so that  
>>> haXe
>>> locks T to be Int? Am I making sense here?
>>>
>>> On Tue, Jun 23, 2009 at 23:02, Nicolas
>>> Cannasse<[hidden email]> wrote:
>>>>
>>>> [hidden email] a écrit :
>>>>>
>>>>> Having a type parametrized class with a static function makes it
>>>>> impossible to call said function.
>>>>>
>>>>> class A<T>
>>>>> {
>>>>>    public static function f()
>>>>>    {
>>>>>    }
>>>>> }
>>>>>
>>>>> A<Int>.f();
>>>>>
>>>>> The above call results in compiler error "Unexpected ."
>>>>
>>>> Class type parameters only work for classes instances, they can't  
>>>> be used
>>>> in
>>>> class statics. This is mainly because the following have no  
>>>> meaning :
>>>>
>>>> class A<T> {
>>>>   static var foo : T;
>>>> }
>>>>
>>>> Since there's only one class A , and then only one "foo" variable.
>>>> You can instead use function type parameters in statics :
>>>>
>>>> static function foo<T>( x : T ) : T {
>>>>  return x;
>>>> }
>>>>
>>>> Nicolas
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> 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: Compiler syntax parsing error?

Armén
David, I was wrong I guess. In any case we are mangling terms here. I
do not really care whether templates exist at runtime, compile-time,
or both. C++ templates only exist at template compilation phase (which
itself is only a part of compilation phase), and the machine that runs
the program is most often a simple CISC machine (x86) without any
notion of classes, much less class templates. This does not stop C++
compilers from providing programmers with a working generics facility.
I understand haXe provides something a bit different, but I am not yet
sure how should I use type parameters in haXe, and what benefits are
there for me in it.

On Wed, Jun 24, 2009 at 16:51, David
Bergman<[hidden email]> wrote:

> On Jun 24, 2009, at 4:19 AM, [hidden email] wrote:
>
>> No, incorrect.
>
> Read my post again, please. I said that it is *one* class in runtime, and
> why that is better, *compared* to creating various classes (through the
> CFront-type name mangling)
>
> ...
>
> /David
>
>
>
>> That is exactly what is NOT happening in haXe. That is
>> why I backed down on my statement. If A<Int> becomes one runtime
>> class, and A<String> becomes another, then the following should have
>> worked (which does not):
>>
>> class A<T>
>> {
>>    public static function f()
>>    {
>>         var foo: T = new T();
>>    }
>> }
>>
>> If A for each type T becomes own class, then there exists a finite
>> permutation (instantiation) of function f, each with a variable
>> initialization of type T. Nicolas stated that "Since there's only one
>> class A , and then only one "foo" variable". This is why I said haXe
>> type parameters are NOT templates, because if they were, we would have
>> a class for each type T. Maybe we do, but then a question to Nicolas
>> is why does he say "there is only one class A"? If there is one class,
>> I understand that one cannot have more than one static function with a
>> single variable type, but if we are having A_Int and A_String
>> instantiation then either can have their own local variable
>> initialization in their respective static function 'f'.
>>
>>
>> On Wed, Jun 24, 2009 at 01:15, David
>> Bergman<[hidden email]> wrote:
>>>
>>> On Jun 23, 2009, at 6:27 PM, [hidden email] wrote:
>>>
>>>> Thanks, Nicolas. That clears it up. I guess in haXe, templates just
>>>> dont exist. Fine, I eat my hat and apologize to Hugh for calling haxe
>>>> param-types templates.
>>>
>>> Templates (or generics...) do exist in haXe, but as in Java, they are
>>> compile-time only, so all instantiations (i.e., concrete types) of A
>>> below
>>> will use the same static properties. This is a good thing, since that
>>> allow
>>> us to map one type to one type in the target environment, which makes
>>> runtime behavior a bit more predictable, compared to having to basically
>>> do
>>> what CFront did: mangle the names into new unique types, such as
>>>
>>>       A<Int>  ===>   class A_int
>>>       A<String> ===> class A_string
>>>
>>> /David
>>>
>>>
>>>> How do you call that static function by the way?
>>>>
>>>> I can see that haXe does not like a f<Int> call syntax for instance.
>>>> THis means that the T has to be deduced otherwise, possibly as a
>>>> regular function argument type, like f(v) where v is Int, so that haXe
>>>> locks T to be Int? Am I making sense here?
>>>>
>>>> On Tue, Jun 23, 2009 at 23:02, Nicolas
>>>> Cannasse<[hidden email]> wrote:
>>>>>
>>>>> [hidden email] a écrit :
>>>>>>
>>>>>> Having a type parametrized class with a static function makes it
>>>>>> impossible to call said function.
>>>>>>
>>>>>> class A<T>
>>>>>> {
>>>>>>   public static function f()
>>>>>>   {
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> A<Int>.f();
>>>>>>
>>>>>> The above call results in compiler error "Unexpected ."
>>>>>
>>>>> Class type parameters only work for classes instances, they can't be
>>>>> used
>>>>> in
>>>>> class statics. This is mainly because the following have no meaning :
>>>>>
>>>>> class A<T> {
>>>>>  static var foo : T;
>>>>> }
>>>>>
>>>>> Since there's only one class A , and then only one "foo" variable.
>>>>> You can instead use function type parameters in statics :
>>>>>
>>>>> static function foo<T>( x : T ) : T {
>>>>>  return x;
>>>>> }
>>>>>
>>>>> Nicolas
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> 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: Compiler syntax parsing error?

Armén
In reply to this post by Nicolas Cannasse
Nicolas, in the following blog post http://www.ncannasse.fr
/blog/haxe_polymorphism_and_variance?lang=en you give an example which
is of interest to me:

class Pair<T> {
    public function make(a : T, b : T) : Array<T> {
         return [a,b];
    }
}

In explaining the example, you incorrectly(?) refer to the 'make'
function as "Pair.make". Are you sure, you did not intend a static
function there? Because 'make' is certainly not a static in the
example, yet you refer to it as 'Pair.make' and in fact state "This
now works, you can write Pair.make("hello","world!") and
Pair.make(0,1) and they both get accepted by the type checker.".
Obviously you CANNOT write "Pair.make" because 'make' is not static -
it is an instance method, not a class method. Either you forgot to
include the 'static' keyword, or I do not know what to make of it. I
am betting on the former.

The funny thing is, if you make 'make' static, it will not compile at
all. You will be getting a "Class not found: T" error. Which is very
close to where my problem lies.

What should I make of this? I mean, it is your own example.

On Wed, Jun 24, 2009 at 13:49, Nicolas
Cannasse<[hidden email]> wrote:

> [hidden email] a écrit :
>>
>> What if one implements the haxe.rtti.Generic interface? Would that
>> have haXe generate a separate class for each inferred/specified type
>> T?
>
> Yes, this is how it works.
>
> But even when you are actually using different classes for instances, you
> still have one single Class object which contains static variables and
> functions.
>
> Think about it like :
>
> class A<T> {
>    static function foo() {}
>    var x : T;
> }
>
> is seperated into :
>
> class A {
>    static function foo() {}
> }
>
> class A_Int {
>   var x : Int;
> }
>
> class A_String {
>   var x : String;
> }
>
> ...
>
> 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: Compiler syntax parsing error?

Nicolas Cannasse
[hidden email] a écrit :
> Nicolas, in the following blog post http://www.ncannasse.fr
> /blog/haxe_polymorphism_and_variance?lang=en you give an example which
> is of interest to me:
>
> class Pair<T> {
>     public function make(a : T, b : T) : Array<T> {
>          return [a,b];
>     }
> }

Yes, the "static" is missing, and this was a very old way of
implementing per-function parameters before they were available in the
language (the post is from more than 3 years ago).

Today, one would write the following :

class Pair {
     public static function make<T>(a : T, b : T) : Array<T>{
        return [a,b];
     }
}

Nicolas

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

Re: Compiler syntax parsing error?

David Bergman
In reply to this post by Armén
On Jun 24, 2009, at 12:08 PM, [hidden email] wrote:

> David, I was wrong I guess. In any case we are mangling terms here.

No, we are not mangling terms. Where were we doing that?

> I
> do not really care whether templates exist at runtime, compile-time,
> or both. C++ templates only exist at template compilation phase (which
> itself is only a part of compilation phase), and the machine that runs
> the program is most often a simple CISC machine (x86) without any
> notion of classes, much less class templates. This does not stop C++
> compilers from providing programmers with a working generics facility.
> I understand haXe provides something a bit different, but I am not yet
> sure how should I use type parameters in haXe, and what benefits are
> there for me in it.

Well, if you understood what I meant with "existing in runtime,"  
instead of this silly "lesson" of yours, you would understand exactly  
what benefits are there, and what you miss by not having a runtime  
representation of a specific template instantiation. All OO languages  
have a runtime object layout system. That such a system is mapped to  
data sections and machine instructions is not important here. C++ have  
a fairly intricate runtime object system, although it provides very  
limited introspection facilities.

In Java and haXe, there is *one* runtime (yes, runtime) representation  
of a class (in the form of class variables, a dispatch table for  
methods and some reflection mechanisms) behind a template. I.e., all  
instantiations yield the same type. Is there any benefit to this kind  
of template system? Yes, there is, it lets you use the same structure  
or algorithms for different types, without any runtime extra costs  
(such as the regular OO ad hoc polymorphism); this is what true  
polymorphism is all about. I.e., you do not have to go back and forth  
between a type T and Dynamic all the time and just *hope* that  
developers use that same type all the time for a specific use.

NOTE: As Nicolas pointed out, though, this is not written in stone,  
since some targets *could* choose to use the target's template  
mechanism, which *could* yield. I think this freedom is ugly, though,  
and would much rather have a homogeneous implementation of templates  
on *all* targets; let us leave this freedom for now, and focus on Neko  
and Flash targets.

Have you ever used templates in C++? In Java [generic...]? What were  
the benefits for you there? And, why would those benefits not apply  
with haXe's template system?

/David

>
> On Wed, Jun 24, 2009 at 16:51, David
> Bergman<[hidden email]> wrote:
>> On Jun 24, 2009, at 4:19 AM, [hidden email] wrote:
>>
>>> No, incorrect.
>>
>> Read my post again, please. I said that it is *one* class in  
>> runtime, and
>> why that is better, *compared* to creating various classes (through  
>> the
>> CFront-type name mangling)
>>
>> ...
>>
>> /David
>>
>>
>>
>>> That is exactly what is NOT happening in haXe. That is
>>> why I backed down on my statement. If A<Int> becomes one runtime
>>> class, and A<String> becomes another, then the following should have
>>> worked (which does not):
>>>
>>> class A<T>
>>> {
>>>    public static function f()
>>>    {
>>>         var foo: T = new T();
>>>    }
>>> }
>>>
>>> If A for each type T becomes own class, then there exists a finite
>>> permutation (instantiation) of function f, each with a variable
>>> initialization of type T. Nicolas stated that "Since there's only  
>>> one
>>> class A , and then only one "foo" variable". This is why I said haXe
>>> type parameters are NOT templates, because if they were, we would  
>>> have
>>> a class for each type T. Maybe we do, but then a question to Nicolas
>>> is why does he say "there is only one class A"? If there is one  
>>> class,
>>> I understand that one cannot have more than one static function  
>>> with a
>>> single variable type, but if we are having A_Int and A_String
>>> instantiation then either can have their own local variable
>>> initialization in their respective static function 'f'.
>>>
>>>
>>> On Wed, Jun 24, 2009 at 01:15, David
>>> Bergman<[hidden email]> wrote:
>>>>
>>>> On Jun 23, 2009, at 6:27 PM, [hidden email] wrote:
>>>>
>>>>> Thanks, Nicolas. That clears it up. I guess in haXe, templates  
>>>>> just
>>>>> dont exist. Fine, I eat my hat and apologize to Hugh for calling  
>>>>> haxe
>>>>> param-types templates.
>>>>
>>>> Templates (or generics...) do exist in haXe, but as in Java, they  
>>>> are
>>>> compile-time only, so all instantiations (i.e., concrete types)  
>>>> of A
>>>> below
>>>> will use the same static properties. This is a good thing, since  
>>>> that
>>>> allow
>>>> us to map one type to one type in the target environment, which  
>>>> makes
>>>> runtime behavior a bit more predictable, compared to having to  
>>>> basically
>>>> do
>>>> what CFront did: mangle the names into new unique types, such as
>>>>
>>>>       A<Int>  ===>   class A_int
>>>>       A<String> ===> class A_string
>>>>
>>>> /David
>>>>
>>>>
>>>>> How do you call that static function by the way?
>>>>>
>>>>> I can see that haXe does not like a f<Int> call syntax for  
>>>>> instance.
>>>>> THis means that the T has to be deduced otherwise, possibly as a
>>>>> regular function argument type, like f(v) where v is Int, so  
>>>>> that haXe
>>>>> locks T to be Int? Am I making sense here?
>>>>>
>>>>> On Tue, Jun 23, 2009 at 23:02, Nicolas
>>>>> Cannasse<[hidden email]> wrote:
>>>>>>
>>>>>> [hidden email] a écrit :
>>>>>>>
>>>>>>> Having a type parametrized class with a static function makes it
>>>>>>> impossible to call said function.
>>>>>>>
>>>>>>> class A<T>
>>>>>>> {
>>>>>>>   public static function f()
>>>>>>>   {
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> A<Int>.f();
>>>>>>>
>>>>>>> The above call results in compiler error "Unexpected ."
>>>>>>
>>>>>> Class type parameters only work for classes instances, they  
>>>>>> can't be
>>>>>> used
>>>>>> in
>>>>>> class statics. This is mainly because the following have no  
>>>>>> meaning :
>>>>>>
>>>>>> class A<T> {
>>>>>>  static var foo : T;
>>>>>> }
>>>>>>
>>>>>> Since there's only one class A , and then only one "foo"  
>>>>>> variable.
>>>>>> You can instead use function type parameters in statics :
>>>>>>
>>>>>> static function foo<T>( x : T ) : T {
>>>>>>  return x;
>>>>>> }
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> 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: Compiler syntax parsing error?

Armén
David, I am not 14, please act civilized :-) What "lesson" would you
be referring to? I am not giving out lessons. I mentioned mangling
terms, because this discussion is watering out the original topic into
unnecessary "lessons" on Java and what not. RTTI, introspection, and
the way a machine works are irrelevant. The only relevant things here
are syntax, parser, and language semantics. Which is what I wanted to
know. Instead I am being explained what haXe does internally. This is
not a good way to document semantics. Compiler internals are compiler
internals. Sadly, not much documentation is available on what EXACTLY
haXe type parameters are and are not, so comparisons with C++
templates cannot be avoided as I am trying to make a picture of the
concept. haXe is in a dire need of a better documentation, and I have
no chance of writing one even, because I do not know the exact
semantics. Here I was thinking a static function might inherit the T
type, when I am explained that in fact it does not. Is that
self-explanatory from scarce information on the Web? No.

Yes, I have used C++ templates extensively. C++ is the language I know
best of all (about 10 years of experience). ActionScript 1 and other
ECMAScript-262 flavors come next. The discussion on benefits of C++
templates is best left for another occasion, IMHO. This much can be
said though: They work for me to a much more substantial degree.

I do not use Java.

On Wed, Jun 24, 2009 at 18:51, David
Bergman<[hidden email]> wrote:

> On Jun 24, 2009, at 12:08 PM, [hidden email] wrote:
>
>> David, I was wrong I guess. In any case we are mangling terms here.
>
> No, we are not mangling terms. Where were we doing that?
>
>> I
>> do not really care whether templates exist at runtime, compile-time,
>> or both. C++ templates only exist at template compilation phase (which
>> itself is only a part of compilation phase), and the machine that runs
>> the program is most often a simple CISC machine (x86) without any
>> notion of classes, much less class templates. This does not stop C++
>> compilers from providing programmers with a working generics facility.
>> I understand haXe provides something a bit different, but I am not yet
>> sure how should I use type parameters in haXe, and what benefits are
>> there for me in it.
>
> Well, if you understood what I meant with "existing in runtime," instead of
> this silly "lesson" of yours, you would understand exactly what benefits are
> there, and what you miss by not having a runtime representation of a
> specific template instantiation. All OO languages have a runtime object
> layout system. That such a system is mapped to data sections and machine
> instructions is not important here. C++ have a fairly intricate runtime
> object system, although it provides very limited introspection facilities.
>
> In Java and haXe, there is *one* runtime (yes, runtime) representation of a
> class (in the form of class variables, a dispatch table for methods and some
> reflection mechanisms) behind a template. I.e., all instantiations yield the
> same type. Is there any benefit to this kind of template system? Yes, there
> is, it lets you use the same structure or algorithms for different types,
> without any runtime extra costs (such as the regular OO ad hoc
> polymorphism); this is what true polymorphism is all about. I.e., you do not
> have to go back and forth between a type T and Dynamic all the time and just
> *hope* that developers use that same type all the time for a specific use.
>
> NOTE: As Nicolas pointed out, though, this is not written in stone, since
> some targets *could* choose to use the target's template mechanism, which
> *could* yield. I think this freedom is ugly, though, and would much rather
> have a homogeneous implementation of templates on *all* targets; let us
> leave this freedom for now, and focus on Neko and Flash targets.
>
> Have you ever used templates in C++? In Java [generic...]? What were the
> benefits for you there? And, why would those benefits not apply with haXe's
> template system?
>
> /David
>
>>
>> On Wed, Jun 24, 2009 at 16:51, David
>> Bergman<[hidden email]> wrote:
>>>
>>> On Jun 24, 2009, at 4:19 AM, [hidden email] wrote:
>>>
>>>> No, incorrect.
>>>
>>> Read my post again, please. I said that it is *one* class in runtime, and
>>> why that is better, *compared* to creating various classes (through the
>>> CFront-type name mangling)
>>>
>>> ...
>>>
>>> /David
>>>
>>>
>>>
>>>> That is exactly what is NOT happening in haXe. That is
>>>> why I backed down on my statement. If A<Int> becomes one runtime
>>>> class, and A<String> becomes another, then the following should have
>>>> worked (which does not):
>>>>
>>>> class A<T>
>>>> {
>>>>   public static function f()
>>>>   {
>>>>        var foo: T = new T();
>>>>   }
>>>> }
>>>>
>>>> If A for each type T becomes own class, then there exists a finite
>>>> permutation (instantiation) of function f, each with a variable
>>>> initialization of type T. Nicolas stated that "Since there's only one
>>>> class A , and then only one "foo" variable". This is why I said haXe
>>>> type parameters are NOT templates, because if they were, we would have
>>>> a class for each type T. Maybe we do, but then a question to Nicolas
>>>> is why does he say "there is only one class A"? If there is one class,
>>>> I understand that one cannot have more than one static function with a
>>>> single variable type, but if we are having A_Int and A_String
>>>> instantiation then either can have their own local variable
>>>> initialization in their respective static function 'f'.
>>>>
>>>>
>>>> On Wed, Jun 24, 2009 at 01:15, David
>>>> Bergman<[hidden email]> wrote:
>>>>>
>>>>> On Jun 23, 2009, at 6:27 PM, [hidden email] wrote:
>>>>>
>>>>>> Thanks, Nicolas. That clears it up. I guess in haXe, templates just
>>>>>> dont exist. Fine, I eat my hat and apologize to Hugh for calling haxe
>>>>>> param-types templates.
>>>>>
>>>>> Templates (or generics...) do exist in haXe, but as in Java, they are
>>>>> compile-time only, so all instantiations (i.e., concrete types) of A
>>>>> below
>>>>> will use the same static properties. This is a good thing, since that
>>>>> allow
>>>>> us to map one type to one type in the target environment, which makes
>>>>> runtime behavior a bit more predictable, compared to having to
>>>>> basically
>>>>> do
>>>>> what CFront did: mangle the names into new unique types, such as
>>>>>
>>>>>      A<Int>  ===>   class A_int
>>>>>      A<String> ===> class A_string
>>>>>
>>>>> /David
>>>>>
>>>>>
>>>>>> How do you call that static function by the way?
>>>>>>
>>>>>> I can see that haXe does not like a f<Int> call syntax for instance.
>>>>>> THis means that the T has to be deduced otherwise, possibly as a
>>>>>> regular function argument type, like f(v) where v is Int, so that haXe
>>>>>> locks T to be Int? Am I making sense here?
>>>>>>
>>>>>> On Tue, Jun 23, 2009 at 23:02, Nicolas
>>>>>> Cannasse<[hidden email]> wrote:
>>>>>>>
>>>>>>> [hidden email] a écrit :
>>>>>>>>
>>>>>>>> Having a type parametrized class with a static function makes it
>>>>>>>> impossible to call said function.
>>>>>>>>
>>>>>>>> class A<T>
>>>>>>>> {
>>>>>>>>  public static function f()
>>>>>>>>  {
>>>>>>>>  }
>>>>>>>> }
>>>>>>>>
>>>>>>>> A<Int>.f();
>>>>>>>>
>>>>>>>> The above call results in compiler error "Unexpected ."
>>>>>>>
>>>>>>> Class type parameters only work for classes instances, they can't be
>>>>>>> used
>>>>>>> in
>>>>>>> class statics. This is mainly because the following have no meaning :
>>>>>>>
>>>>>>> class A<T> {
>>>>>>>  static var foo : T;
>>>>>>> }
>>>>>>>
>>>>>>> Since there's only one class A , and then only one "foo" variable.
>>>>>>> You can instead use function type parameters in statics :
>>>>>>>
>>>>>>> static function foo<T>( x : T ) : T {
>>>>>>>  return x;
>>>>>>> }
>>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>> --
>>>>>>> haXe - an open source web programming language
>>>>>>> http://haxe.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

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