Re: explicit line termination with ;: why?

2007-05-15 Thread Dave Whipp

Jonathan Lang wrote:


Close.  I'm thinking added functionality for semicolon alternatives
rather than the replace the semicolon stunt that Semi::Semicolons
pulls.  In particular, as long as there's no ambiguity between
prefix:? and postfix:?, I think that it would be quite useful for
postfix:? to act as a semicolon that additionally sets $_ equal to
the expression's value, allowing for a pseudo-Prolog style of syntax
(i.e., the code could include questions as well as declarations and
instructions).


A slightly tangental thought: is the behavior of Cgiven with no block 
defined? I.e. is


given $foo { when 1 {...} };

equivalent to

given $foo;
when 1 {...};


Re: explicit line termination with ;: why?

2007-05-15 Thread Luke Palmer

On 5/15/07, Dave Whipp [EMAIL PROTECTED] wrote:

A slightly tangental thought: is the behavior of Cgiven with no block
defined? I.e. is

given $foo { when 1 {...} };

equivalent to

given $foo;
when 1 {...};


Doubtful.

However, I do think that it's useful to be able to treat the rest of
the current scope as a block (usually with a parameter), for certain
kinds of closure-heavy code.  For example, instead of saying:

 {
   foo - $x {
 bar;
 baz - $y {
   quux;
   bizzle;
 }
   }
 }

Writing that as, say:

 {
   foo - $x;
   bar;
   baz - $y;
   quux;
   bizzle;
 }

Can really help readability in situations when the control flow wants
to look linear.  That's not to say that the - $x; syntax makes any
sense.

Luke


Re: explicit line termination with ;: why?

2007-05-15 Thread Larry Wall
On Tue, May 15, 2007 at 11:59:35AM -0700, Dave Whipp wrote:
: Jonathan Lang wrote:
: 
: Close.  I'm thinking added functionality for semicolon alternatives
: rather than the replace the semicolon stunt that Semi::Semicolons
: pulls.  In particular, as long as there's no ambiguity between
: prefix:? and postfix:?, I think that it would be quite useful for
: postfix:? to act as a semicolon that additionally sets $_ equal to
: the expression's value, allowing for a pseudo-Prolog style of syntax
: (i.e., the code could include questions as well as declarations and
: instructions).
: 
: A slightly tangental thought: is the behavior of Cgiven with no block 
: defined? I.e. is

It would be illegal syntax currently.

: given $foo { when 1 {...} };
: 
: equivalent to
: 
: given $foo;
: when 1 {...};

Both of these suggestions would seem to duplicate the existing construct:

$_ = $foo;

:-)

Of course, now someone will argue that unary:= should assign to $_ by
default, in which case we'd have to find a new interation operator...

Larry


Re: explicit line termination with ;: why?

2007-05-15 Thread Daniel Hulme
On Tue, May 15, 2007 at 01:14:44PM -0600, Luke Palmer wrote:
 However, I do think that it's useful to be able to treat the rest of
 the current scope as a block (usually with a parameter), for certain
 kinds of closure-heavy code.
Maybe this is a case for one of Mr. Lang's custom semicolons with added
functionality: you could have something that worked a bit like the
lambda-calculus .. It would slurp up as much of the RHS as possible,
which would almost always[1] be until the end of the enclosing block,
and 'return' it (in a syntactic way) to whatever on the LHS wants a
block.  So, like Mr. Palmer's example, you would get something like

sub do_stuff() {
  my @foo = get_me_a_list;
  for @foo :-
  .subst(/bar/,'baz').say;
}

[1] By almost always I mean I can't think of a reason for it to
sometimes not be that, but one or more may exist. Anywhere you would
want it to stop before the end of the enclosing block you should
probably use curlies anyway to stop it being confusing.

I'm not sure whether I would use these magic brace-opening semicolons
even if they were in. It seems to be to be less readable, but maybe
that's just because I haven't seen a compelling enough example. In the
worst case they would lead to code that looks like the old-style TeX
idiom of normal {\bf bold} normal, where you open braces around the
whole block and do a state-change-like thing inside rather than a
functional thing that takes the thing you want operated on as an
argument. That doesn't mean we shouldn't allow custom semicolons with
added functionality; just that maybe this is not the best use for them
after all.

-- 
Mary had a little sprout,From week to week, from month to month,
Its fleece was green as grass,   She kept the sprout in tow,
She hitched it to a bit of string,And everywhere that Mary went,
The silly little ass. The sprout was sure to go.


signature.asc
Description: Digital signature


Re: explicit line termination with ;: why?

2007-05-15 Thread Jonathan Lang

Larry Wall wrote:

Dave Whipp wrote:
: A slightly tangental thought: is the behavior of Cgiven with no block
: defined? I.e. is

It would be illegal syntax currently.


As I understand it, the proposal is to say that if the parser finds a
';' where it was expecting to find a control block, it treats the rest
of the current block as the expected control block - or something to
that effect.  Eh... messy, and with no substantial gain.


: given $foo { when 1 {...} };
:
: equivalent to
:
: given $foo;
: when 1 {...};

Both of these suggestions would seem to duplicate the existing construct:

$_ = $foo;

:-)


Agreed.  But I think that postfix:? is rather clean:

   $foo?
   when 1 {...}

Two catches:

1. I could easily define postfix:? myself, save for one thing: what
would I put as the parameter for the 'is equiv' trait, so that it has
terminator precedence?

2. 'when' implicitly leaves its current block after successfully being
executed (as per 'last'), since it's designed primarily for use as one
of a set of mutually-exclusive options.  I'm not sure how wise of a
decision that is, since it's easier to add a last to a block that
implicitly lacks one than it is to remove a last from a block that
implicitly includes one.  Part of me would strongly prefer that when
$x { ... } be exactly equivalent to if $_ ~~ $x { ... }, except for
the inability to append an else block to the former.


Of course, now someone will argue that unary:= should assign to $_ by
default, in which case we'd have to find a new iteration operator...


Horrors, no!  '=$filehandle' works just fine for reading an iterator,
thank you...

I _might_ flirt with the idea of postfix:= being equivalent to a
filehandle's '.say' method (i.e., writing to an iterator) - or not.
Given the mandatory whitespace that a postfix operator imposes on an
equivalent infix operator, I'd strongly suggest that good practice for
Perl 6 would be to avoid defining both forms if at all reasonable; and
infix:= definitely has the edge here.  (Rule of thumb: if you can
avoid doing something that will mandate or forbid whitespace, avoid
it.)

--
Jonathan Dataweaver Lang


Re: explicit line termination with ;: why?

2007-05-14 Thread Andrew Shitov
 I don't want to argue about the design of perl6[1], I just wonder: why
 the semicolon is still needed in the end of lines in perl6?

JavaScript allows to omit semicolumn. In lecture at Yahoo's YUI
Theatre one of JS's gurus talked about how it is organized in
JavaScript parser.

If the line of code is not ended with ';' the parser tries first
to assume that the next line continues current one. If then syntax error
occurs, the parser _goes_back_ and make another asumption that previous
line was ended with semicolumn.

Probably there are much more than one way to implement ';'-less but it
either slows down the compiler or makes grammar more complex.

And in fact Perl 6 already allows not to type ';' at the end of
{block} ;-)

The following simple snippets work correctly with Pugs and perl5:

 perl 6
sub debug ($value)
{
say $value
}
debug 'me'


# perl 5
sub debug
{
   print shift
}
debug 'me'


And finally, Perl is not an Assembler with one only instrucion per
line.


--
Andrew Shitov
__
[EMAIL PROTECTED] | http://www.shitov.ru



Re: explicit line termination with ;: why?

2007-05-14 Thread Larry Wall
On Mon, May 14, 2007 at 07:05:01PM +0200, gabriele renzi wrote:
: Hi everyone,
: 
: I don't want to argue about the design of perl6[1], I just wonder: why 
: the semicolon is still needed in the end of lines in perl6?
: 
: I can think of different reasons (history, readability, easier parsing 
: of multiline statements, force people to write one-line functions to 
: avoid typing them :) but I'm curious to know the real one.

The real one, eh?

These sorts of things are almost never for a single reason.  Some of
it is my prejudice against dangling syntax, and perhaps prejudice
against anything resembling Fortran.  Some of it is not wanting to
distinguish different kinds of whitespace any more than we already do.
Some of it is simplicity of parsing, both for the human reader as
well as for the computer.  I think if I had to pick one reason,
though, it's that it allows the parser to understand the intent of
the writer much better and hence give more useful diagnostics when
something seems to be going wrong.  Much more than other languages,
Perl depends on the prohibition against two terms in a row as a kind
of self-clocking mechanism to disambiguate programmer intent, and
not requiring a semicolon between the final term of one statement
and the first term of the next statement would tend to weaken that,
especially when the term starts with a prefix operator that could be
mistaken for an infix.

: Sorry if this is already been explained but my google-fu was not good 
: enough to find an answer.

Honest questions deserve honest answers, even if they aren't simple answers.

Larry


Re: explicit line termination with ;: why?

2007-05-14 Thread Aankhen

On 5/14/07, Andrew Shitov [EMAIL PROTECTED] wrote:

JavaScript allows to omit semicolumn.


Speaking of JavaScript, any experienced JavaScript programmer will
tell you that while semi-colons are in fact optional, you should
always treat them as mandatory, to avoid subtle errors creeping into
your code.

--
Aankhen
(We have no branches.)


Re: explicit line termination with ;: why?

2007-05-14 Thread Jonathan Lang

gabriele renzi wrote:

Hi everyone,

I don't want to argue about the design of perl6, I just wonder: why
the semicolon is still needed in the end of lines in perl6?


It isn't - sometimes.  S03 identifies a number of ways that an
expression can be terminated: the semicolon (';'), a block-final
('}'), a control block (' { ... }'), a statement modifier
('if'|'unless'|'while'|'until'|'for'|'given'|'when')^, or a feed
operator ('==', '==', '==', '==').

^ FWIW, S03 needs updating, since it doesn't list 'given' or 'when'
among the statement modifiers in the block termination section.

A couple of thoughts:

1. There's a subtlety here: termination of an expression is not always
the same as termination of a statement.  In particular, ';' is pretty
much equivalent to the '==' feed operator when used in a bracketing
construct [1]^, and feed operators in general don't appear to force
statement termination the way that control blocks, statement
modifiers, and block-finals do.  Of course, this distinction may be me
misunderstanding how expression termination works.

2. This brings up the possibility of custom-designed termination
operators.  Question: which kinds of operators can have this
precedence?  That is, prefix, postfix, infix, circumfix, or
postcircumfix?  It appears to me that our current list of termination
operators includes analogs of most of these: postfix:;,
infix:{'=='}, circumfix:{ }, and postcircumfix:«\s{ }» [2]^.

  Meanwhile, how much clarity does the parser have between postfix
and infix?  That is, if I defined both postfix:foo and infix:foo,
would the parser be able to reliably distinguish between them?  This
matters to the current topic because ';' could be thought of as
'postfix-like' when used to terminate a statement, and 'infix-like'
when being used to construct feeds; if clarity between postfix and
infix exists, you might be able to do away with the bracketed
context clause - though it might not be wise to do so, even if you
could.)

  I'm thinking about this in terms of the possibility of adding more
punctuation to the syntax: consider something akin to a postfix:?
operator that behaves exactly like postfix:;, except that it
automatically topicalizes the expression's value.  Or a postfix:.
that always behaves the way that postfix:; does at statement level
[3]^.  Borrowing from Spanish, circumfix:¿ ? might be to
circumfix:{ } as postfix:? would be to postfix:;.  And so on.

  As long as we maintain clarity between the grammatical categories,
such punctuation operators shouldn't present any difficulty; e.g.,
postfix:? will not clobber prefix:? or vice versa, even if the
former has terminator precedence and the latter has symbolic unary
precedence.

  Or is this the sort of thing that you'd rather consign to explicit
hacks of the parser?

^[1]: see S09.
^[2]: Admittedly, this last one cheats a bit by putting whitespace
into the delimiter.  But the principle is the same.
^[3]: If this were included in the core, you might even reverse things
so that ';' is defined in terms of postfix:. or infix:{'=='},
depending on the context; in this case, postfix:? would be defined
in terms of postfix:., rather than postfix:;.  In fact, the only
thing keeping postfix:. from completely replacing postfix:; as a
statement terminator and insisting that the latter always be used as a
shortcut for feeds is the long tradition that the latter has in
programming languages - much like perl 6's infix:. replaces perl 5's
'-' because that's what everyone else uses.

--
Jonathan Dataweaver Lang


Re: explicit line termination with ;: why?

2007-05-14 Thread Jonathan Lang

Jonathan Lang wrote:

^[3]: If this were included in the core, you might even reverse things
so that ';' is defined in terms of postfix:. or infix:{'=='},
depending on the context; in this case, postfix:? would be defined
in terms of postfix:., rather than postfix:;.  In fact, the only
thing keeping postfix:. from completely replacing postfix:; as a
statement terminator and insisting that the latter always be used as a
shortcut for feeds is the long tradition that the latter has in
programming languages - much like perl 6's infix:. replaces perl 5's
'-' because that's what everyone else uses.


Umm, never mind.  I just realized that introducing a postfix:.
operator would complicate matters in unexpected ways by forcing
infix:. to require disambiguating whitespace, as per S02.  This
would be Very Bad in several ways, e.g., an infixed dot is given as
the appropriate way to separate a postfix operator from the term in
front of it when whitespace is forbidden.  Or the fact that 'foo.bar'
would no longer parse as expected.  :sigh:

--
Jonathan Dataweaver Lang


Re: explicit line termination with ;: why?

2007-05-14 Thread Daniel Hulme
On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
 2. This brings up the possibility of custom-designed termination
 operators.

cf. Semi::Semicolons. I think that being flexible enough that people can
write packages like that is one of Perl  6's greatest strengths.

Long may it continue. Of course, if Perl 6 is actually parsed using a
descendant of Larry's 'Perl 6 grammar as a Perl 6 grammar', the compiler
could easily (*cough*) provide hooks to edit the grammar at parse-time,
meaning you can write your own (lexically scoped) Semi::Semicolons, or
Semi::Line::Continuation::Markers, or even
Semi::I::Don't::Really::Want::Prefix::Operators::Available::As::Methods.
Then there need be no arguments about what it looks like, and everyone
will be happy, and all programmers will hold hands and stop having
holy wars. Maybe.

-- 
Sometimes it's a Boat,  and sometimes it's more of an Accident.  It all
Depends on what? depends.
On whether I'm on the top of it or underneath it.
   -- A. A. Milne, 'Winnie-the-Pooh'   http://surreal.istic.org/


signature.asc
Description: Digital signature


Re: explicit line termination with ;: why?

2007-05-14 Thread Thomas Wittek
Andrew Shitov:
 If the line of code is not ended with ';' the parser tries first
 to assume [..]

Wouldn't that be unambigous?

 foo = 23
 bar = \
   42

?

I think there would be no ambiguities and you only had to add additional
syntax for the rare cases instead of the common cases.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]


Re: explicit line termination with ;: why?

2007-05-14 Thread John Macdonald
On Tue, May 15, 2007 at 01:22:48AM +0200, Thomas Wittek wrote:
 Andrew Shitov:
  If the line of code is not ended with ';' the parser tries first
  to assume [..]
 
 Wouldn't that be unambigous?
 
  foo = 23
  bar = \
42
 
 ?
 
 I think there would be no ambiguities and you only had to add additional
 syntax for the rare cases instead of the common cases.

Without explicit \ to join unterminated lines you get:

  foo = 23
  if x == 7
  { y = 5; z = 6 }

Is that:

  foo = 23
  if x == 7;
  { y = 5; z = 6 }

or:

  foo = 23;
  if x == 7
  { y = 5; z = 6 }

?

With explicit \ to join unterminated lines you just get more
ugliness than having semicolons.  It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage.  The syntax of
the last element is the same as the rest so you can shuffle
the order around easily without having to add a separator to
the end of what used to be the final element and remove the
separator on what is now the final element.

Having punctuation where there is a stop is more natural than
having an explicit marker for don't stop here, keep going.

-- 


Re: explicit line termination with ;: why?

2007-05-14 Thread Thomas Wittek
John Macdonald schrieb:
 It's also, in many cases,
 harder to edit - that's why a trailing comma in a list that
 is surrounded by parens, or a trailing semicolon in a block
 surrounded by braces, is easier to manage.

Now that the list is surrounded by parens makes clear that it ends with
the closing paren and not with a line break. So you could still use
commas (without backslashes) to separate the items over multiple lines.
See e.g. http://docs.python.org/ref/implicit-joining.html

 Having punctuation where there is a stop is more natural than
 having an explicit marker for don't stop here, keep going.

That's the pro-semicolon reason that makes most sense in all comments
that I've read so far in this discussion.
But maybe that's just something where you have to get used to.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]


Re: explicit line termination with ;: why?

2007-05-14 Thread Jonathan Lang

On 5/14/07, Daniel Hulme [EMAIL PROTECTED] wrote:

On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
 2. This brings up the possibility of custom-designed termination
 operators.

cf. Semi::Semicolons.


Close.  I'm thinking added functionality for semicolon alternatives
rather than the replace the semicolon stunt that Semi::Semicolons
pulls.  In particular, as long as there's no ambiguity between
prefix:? and postfix:?, I think that it would be quite useful for
postfix:? to act as a semicolon that additionally sets $_ equal to
the expression's value, allowing for a pseudo-Prolog style of syntax
(i.e., the code could include questions as well as declarations and
instructions).

--
Jonathan Dataweaver Lang


Re: explicit line termination with ;: why?

2007-05-14 Thread John Macdonald
On Tue, May 15, 2007 at 02:02:06AM +0200, Thomas Wittek wrote:
 John Macdonald schrieb:
  It's also, in many cases,
  harder to edit - that's why a trailing comma in a list that
  is surrounded by parens, or a trailing semicolon in a block
  surrounded by braces, is easier to manage.
 
 Now that the list is surrounded by parens makes clear that it ends with
 the closing paren and not with a line break. So you could still use
 commas (without backslashes) to separate the items over multiple lines.
 See e.g. http://docs.python.org/ref/implicit-joining.html

I was actually talking about existing perl5 here.  I write:

my %h = (
x = 100,
y = 75,
z = 99,
);

explicitly writing the unrequired comma on the last element
(z=99).  That way, if I add another element to the hash there's
no danger that I will forget to go back and add the comma to
the line above.  Alternately, if I reorder the hash elements
(maybe sorting on the value instead of the key) I don't have
to check whether there is now a commaless line in the middle
of the reordered bunch.

--