Re[2]: Whitespace

[Andrew Shitov]

 : so why not 'print($x)' == 'print ($x)' ;-)

 Plus we got rid of Perl-5's no-op unary +, so instead we're using
 whitespace to force it to be a list operator.

Thanks! I've got the idea.

I'd better refuse parenthesis than a space here. I think I'll never
drop space in a function call if it can be overcome :-)

--
___
Andrew, [EMAIL PROTECTED]
___

Re[2]: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)

[Andrew Shitov]

 why do we have to give up a space when calling functions under Pugs?

 Not sure whether it's enough of an answer, but see:
 http://dev.perl.org/perl6/doc/design/syn/S04.html#Statement_parsing

it says:

if $term ($x)   # syntax error (two terms in a row)


if this cause an error, why not treat '$term ($x)' as a function call.
At least when $term is not some abstract variable but valid name of simple
function.

--
___
Andrew, [EMAIL PROTECTED]
___

Re: Re[2]: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)

[Carl Franks]

   why do we have to give up a space when calling functions under Pugs?
 
   Not sure whether it's enough of an answer, but see:
   http://dev.perl.org/perl6/doc/design/syn/S04.html#Statement_parsing
 
 it says:
 
 if $term ($x)   # syntax error (two terms in a row)
 
 if this cause an error, why not treat '$term ($x)' as a function call.
 At least when $term is not some abstract variable but valid name of simple
 function.

(I have nothing to do with the design process, so this is just my take on it)...

I get the impression that driving these sort of decisions, is the
historical problem we've had with only `perl` being able to parse
Perl.
Syntax is getting tightened up a little, with the result that perl6
programs are much more easily read, with the intention of allowing
different compiler implementations.

Also, we can only know if $term contains a valid subroutine name at
runtime, and perl6 aims to allow very separate compilation and runtime
phases (and syntax errors need to be figured out at compilation time).

Carl