Parsing bug?

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

Parsing bug?

Bill Moorier
Apologies if there is a haxe bug-tracker that I missed somehow... I
thought it best to just post this to the list anyway.

This looks like a parsing bug to me.  The following code does compile:

class Foo {
    static function main() {
        for(n in [1,2,3]) {
            trace(n);
        }
        trace("blah");
        (new haxe.Timer(10 * 1000)).run = blah;
    }

    static function blah() {
        trace(42);
    }
}

While the following code does not:

class Foo {
    static function main() {
        for(n in [1,2,3]) {
            trace(n);
        }
        (new haxe.Timer(10 * 1000)).run = blah;
        trace("blah");
    }

    static function blah() {
        trace(42);
    }
}

All I did was to change the position of 'trace("blah")', and now I get
this error:

Foo.hx:3: lines 3-5 : Void cannot be called

Cheers,
Bill.
--
Bill Moorier: http://abstractnonsense.com
VP Software Development, http://www.justin.tv

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

Re: Parsing bug?

Ian Thomas
That's the second time in two weeks that's come up - and it's a bit obscure.

The trouble - as I understand it - is that bracketed code in haXe has
a return value.

The parser has seen the:
{
  trace (n);
}

of the for loop, correctly given it a return value, and then has seen
your parenthesised expression:
 (new haxe.Timer(10 * 1000))

on the next line. It parses it as:
{ code evaluating to a value}(someArg)

or, in other words, an attempt to call a function defined by the
bracketed code. As if you were saying

someVariable(someArg).

Does that make sense?

If you get rid of the paretheses here:
(new haxe.Timer(10 * 1000)).run = blah;

And make it, for example:
var timer:Timer=new haxe.Timer(10*1000);
timer.run=blah;

That should solve the problem.

Nicolas - I wonder if the parser needs work here? As I said, it's the
second time it's come up in a week and it's really not obvious from
just scanning the code.

HTH,
  Ian


On Tue, Oct 21, 2008 at 11:02 PM, Bill Moorier <[hidden email]> wrote:

> Apologies if there is a haxe bug-tracker that I missed somehow... I
> thought it best to just post this to the list anyway.
>
> This looks like a parsing bug to me.  The following code does compile:
>
> class Foo {
>    static function main() {
>        for(n in [1,2,3]) {
>            trace(n);
>        }
>        trace("blah");
>        (new haxe.Timer(10 * 1000)).run = blah;
>    }
>
>    static function blah() {
>        trace(42);
>    }
> }
>
> While the following code does not:
>
> class Foo {
>    static function main() {
>        for(n in [1,2,3]) {
>            trace(n);
>        }
>        (new haxe.Timer(10 * 1000)).run = blah;
>        trace("blah");
>    }
>
>    static function blah() {
>        trace(42);
>    }
> }
>
> All I did was to change the position of 'trace("blah")', and now I get
> this error:
>
> Foo.hx:3: lines 3-5 : Void cannot be called
>
> Cheers,
> Bill.
> --
> Bill Moorier: http://abstractnonsense.com
> VP Software Development, http://www.justin.tv
>
> --
> 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: Parsing bug?

Bill Moorier
That does make sense, thanks.

In the absence of a formal language spec, I guess I can't really claim
this is a bug... but it's probably not what most people will expect
;-)

Cheers,
Bill.


On Tue, Oct 21, 2008 at 3:16 PM, Ian Thomas <[hidden email]> wrote:

> That's the second time in two weeks that's come up - and it's a bit obscure.
>
> The trouble - as I understand it - is that bracketed code in haXe has
> a return value.
>
> The parser has seen the:
> {
>  trace (n);
> }
>
> of the for loop, correctly given it a return value, and then has seen
> your parenthesised expression:
>  (new haxe.Timer(10 * 1000))
>
> on the next line. It parses it as:
> { code evaluating to a value}(someArg)
>
> or, in other words, an attempt to call a function defined by the
> bracketed code. As if you were saying
>
> someVariable(someArg).
>
> Does that make sense?
>
> If you get rid of the paretheses here:
> (new haxe.Timer(10 * 1000)).run = blah;
>
> And make it, for example:
> var timer:Timer=new haxe.Timer(10*1000);
> timer.run=blah;
>
> That should solve the problem.
>
> Nicolas - I wonder if the parser needs work here? As I said, it's the
> second time it's come up in a week and it's really not obvious from
> just scanning the code.
>
> HTH,
>  Ian
>
>
> On Tue, Oct 21, 2008 at 11:02 PM, Bill Moorier <[hidden email]> wrote:
>> Apologies if there is a haxe bug-tracker that I missed somehow... I
>> thought it best to just post this to the list anyway.
>>
>> This looks like a parsing bug to me.  The following code does compile:
>>
>> class Foo {
>>    static function main() {
>>        for(n in [1,2,3]) {
>>            trace(n);
>>        }
>>        trace("blah");
>>        (new haxe.Timer(10 * 1000)).run = blah;
>>    }
>>
>>    static function blah() {
>>        trace(42);
>>    }
>> }
>>
>> While the following code does not:
>>
>> class Foo {
>>    static function main() {
>>        for(n in [1,2,3]) {
>>            trace(n);
>>        }
>>        (new haxe.Timer(10 * 1000)).run = blah;
>>        trace("blah");
>>    }
>>
>>    static function blah() {
>>        trace(42);
>>    }
>> }
>>
>> All I did was to change the position of 'trace("blah")', and now I get
>> this error:
>>
>> Foo.hx:3: lines 3-5 : Void cannot be called
>>
>> Cheers,
>> Bill.
>> --
>> Bill Moorier: http://abstractnonsense.com
>> VP Software Development, http://www.justin.tv
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Bill Moorier: http://abstractnonsense.com
VP Software Development, http://www.justin.tv

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

Re: Parsing bug?

Ian Liu Rodrigues
This is a bit of Lisp, where everything has a return value.
I like this approach, so we can do things like

var a = if(b) c else d;

since the "if" has a return value.

On Tue, Oct 21, 2008 at 8:35 PM, Bill Moorier <[hidden email]> wrote:
That does make sense, thanks.

In the absence of a formal language spec, I guess I can't really claim
this is a bug... but it's probably not what most people will expect
;-)

Cheers,
Bill.


On Tue, Oct 21, 2008 at 3:16 PM, Ian Thomas <[hidden email]> wrote:
> That's the second time in two weeks that's come up - and it's a bit obscure.
>
> The trouble - as I understand it - is that bracketed code in haXe has
> a return value.
>
> The parser has seen the:
> {
>  trace (n);
> }
>
> of the for loop, correctly given it a return value, and then has seen
> your parenthesised expression:
>  (new haxe.Timer(10 * 1000))
>
> on the next line. It parses it as:
> { code evaluating to a value}(someArg)
>
> or, in other words, an attempt to call a function defined by the
> bracketed code. As if you were saying
>
> someVariable(someArg).
>
> Does that make sense?
>
> If you get rid of the paretheses here:
> (new haxe.Timer(10 * 1000)).run = blah;
>
> And make it, for example:
> var timer:Timer=new haxe.Timer(10*1000);
> timer.run=blah;
>
> That should solve the problem.
>
> Nicolas - I wonder if the parser needs work here? As I said, it's the
> second time it's come up in a week and it's really not obvious from
> just scanning the code.
>
> HTH,
>  Ian
>
>
> On Tue, Oct 21, 2008 at 11:02 PM, Bill Moorier <[hidden email]> wrote:
>> Apologies if there is a haxe bug-tracker that I missed somehow... I
>> thought it best to just post this to the list anyway.
>>
>> This looks like a parsing bug to me.  The following code does compile:
>>
>> class Foo {
>>    static function main() {
>>        for(n in [1,2,3]) {
>>            trace(n);
>>        }
>>        trace("blah");
>>        (new haxe.Timer(10 * 1000)).run = blah;
>>    }
>>
>>    static function blah() {
>>        trace(42);
>>    }
>> }
>>
>> While the following code does not:
>>
>> class Foo {
>>    static function main() {
>>        for(n in [1,2,3]) {
>>            trace(n);
>>        }
>>        (new haxe.Timer(10 * 1000)).run = blah;
>>        trace("blah");
>>    }
>>
>>    static function blah() {
>>        trace(42);
>>    }
>> }
>>
>> All I did was to change the position of 'trace("blah")', and now I get
>> this error:
>>
>> Foo.hx:3: lines 3-5 : Void cannot be called
>>
>> Cheers,
>> Bill.
>> --
>> Bill Moorier: http://abstractnonsense.com
>> VP Software Development, http://www.justin.tv
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Bill Moorier: http://abstractnonsense.com
VP Software Development, http://www.justin.tv

--
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: Parsing bug?

Ian Thomas
On Tue, Oct 21, 2008 at 11:48 PM, Ian Liu <[hidden email]> wrote:
> This is a bit of Lisp, where everything has a return value.
> I like this approach, so we can do things like
>
> var a = if(b) c else d;
>
> since the "if" has a return value.

Yes, it's a great approach - but - it does lead to situations like
Bill's, where as he says it's not what most people would expect and
it's not easy to spot the cause of the problem.

I was wondering whether there were any obvious ways to either filter
out some of the cases (would you _ever_ want to call the bracketed
portion of a for loop as a function?) or to print out a compiler
warning for some of the cases ('is this really what you meant?')

Ian

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

Re: Parsing bug?

Ian Martins
In reply to this post by Ian Liu Rodrigues
Ian Liu wrote:
> This is a bit of Lisp, where everything has a return value.
> I like this approach, so we can do things like
>
> var a = if(b) c else d;
>
> since the "if" has a return value.
couldn't we still do

var a = b ? c : d;



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

Re: Parsing bug?

Kostas Michalopoulos
In reply to this post by Bill Moorier
Bill Moorier wrote:
> That does make sense, thanks.
>
> In the absence of a formal language spec, I guess I can't really claim
> this is a bug... but it's probably not what most people will expect
> ;-)
>

How about writing a formal language spec then (or at least something
that describes the language itself fully than the current docs)? I
didn't knew this feature either and reading the docs -which are made
more like as a tutorial- didn't mentioned.

Also if this is done it should be in downloadable and printable format
(that is, PDF) too. Not only html/wiki. That would help a lot.

Kostas "Bad Sector" Michalopoulos

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

Re: Parsing bug?

Ian Liu Rodrigues
The docs do say about these behavior. Anything enclosed by {} are blocks which return the last statement as its type.
So, when the "for" terminates on the Moorier code, the block returns Void since that is the return type of trace function.

I agree that this feature are awkward for loops.

On Wed, Oct 22, 2008 at 6:05 AM, Kostas Michalopoulos <[hidden email]> wrote:
Bill Moorier wrote:
That does make sense, thanks.

In the absence of a formal language spec, I guess I can't really claim
this is a bug... but it's probably not what most people will expect
;-)


How about writing a formal language spec then (or at least something that describes the language itself fully than the current docs)? I didn't knew this feature either and reading the docs -which are made more like as a tutorial- didn't mentioned.

Also if this is done it should be in downloadable and printable format (that is, PDF) too. Not only html/wiki. That would help a lot.

Kostas "Bad Sector" Michalopoulos

--
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: Parsing bug?

Benjamin Dasnois
In reply to this post by Kostas Michalopoulos
Hello,

I think the old spec were more complete and we should have a link to
them on the wiki because they were more formal. Even if there was no
warning for such case it was explained that every block has a return
type. And so, a good developer ( ;) ) should be able to figure that...
(ergh... I admit it's not obvious but it's quite good !)

Anyway, if I were to write a course about haXe for my school, that is
certainly a case that I would give to the students as a
troubleshooting exercise. ;)

Regards,

On Wed, Oct 22, 2008 at 10:05 AM, Kostas Michalopoulos
<[hidden email]> wrote:

> Bill Moorier wrote:
>>
>> That does make sense, thanks.
>>
>> In the absence of a formal language spec, I guess I can't really claim
>> this is a bug... but it's probably not what most people will expect
>> ;-)
>>
>
> How about writing a formal language spec then (or at least something that
> describes the language itself fully than the current docs)? I didn't knew
> this feature either and reading the docs -which are made more like as a
> tutorial- didn't mentioned.
>
> Also if this is done it should be in downloadable and printable format (that
> is, PDF) too. Not only html/wiki. That would help a lot.
>
> Kostas "Bad Sector" Michalopoulos
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



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

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

Re: Parsing bug?

Nicolas Cannasse
In reply to this post by Ian Thomas
> Nicolas - I wonder if the parser needs work here? As I said, it's the
> second time it's come up in a week and it's really not obvious from
> just scanning the code.

Fixed on CVS, for switch/for/while/do/try/if
It shouldn't affect existing code, and in case it does it can easily be
fixed :

switch(x) { ... } + 1

would need to be :

(switch(x) { ....}) + 1

Nicolas


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

Re: Parsing bug?

Ian Thomas
Brilliant. :-)

Cheers,
   Ian

On Wed, Oct 22, 2008 at 1:40 PM, Nicolas Cannasse
<[hidden email]> wrote:

>> Nicolas - I wonder if the parser needs work here? As I said, it's the
>> second time it's come up in a week and it's really not obvious from
>> just scanning the code.
>
> Fixed on CVS, for switch/for/while/do/try/if
> It shouldn't affect existing code, and in case it does it can easily be
> fixed :
>
> switch(x) { ... } + 1
>
> would need to be :
>
> (switch(x) { ....}) + 1
>
> Nicolas
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

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