S02 - s/environmental variables/environment variables/g please

[Randal L. Schwartz]

Please, let us agree to use the traditional name of environment variables in
the docs, and not re-introduce its bastardized cousin, which hurts my ears.
Thanks.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: S02 - s/environmental variables/environment variables/g please

[james]

On Sat, Apr 29, 2006 at 07:50:02AM -0700, Randal L. Schwartz wrote:
 Please, let us agree to use the traditional name of environment variables in
 the docs, and not re-introduce its bastardized cousin, which hurts my ears.
 Thanks.
I think they are different things.  An environment variable is something
in %*ENV.  An environmental variable is a variable which was declared with
env $foo, and which can be seen by callers.

I rather dislike this naming scheme, but can't think of a better one.

  -=- James Mastros

A shorter long dot

[Juerd]

 16:50  audreyt Juerd: write to p6l and explain the .. conflict,

The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable, is quite a lot.

Illustration:

$xyzzy.foo();
$fooz. .foo();  # doesn't line up, so we have to change the
# *previous* line!
$foo. .foo();   # this lines up again.

So we use:

$xyzzy. .foo();
$fooz.  .foo();
$foo.   .foo();

which is ugly and feels bad. It feels bad, because we're adding much
more whitespace (two character positions in total) than we had to
bridge. And it's a lot of work (many, many keystrokes!) to go back and
change something.

However, the whitespace in between cannot simply be made optional, as
then it would clash with the range operator. As ranges are even more
important than a sane long dot solution, the long dot had to change.

Larry indicated that changing the long dot would have to involve
changing the first character. The only feasible solution in the tiny
glyphs section was the backtick. I refrain from explaining why that
will widely be considered a bad idea.

Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with

 and propose .: as a solution,

That's right, dot-colon. There are more glyphs available, but none of
them is nice like this. The basis is in regexes, where a colon means you
commit to have parsed the left side of the colon. That's how the colon
already reads in the indirect object notation, and the colon in
$foo.map:{...} can already be read.

So the actual solution is to make the method call operator not ., but
.:. Of course, a lone . still works and is the recommended style for
all simple method calls that don't have to be lined up. You can also
explain it as . still being the base operator, where .: is a special
form. Whatever you like best :)

 and . : as an extension, 

Of course, it wouldn't be a solution to the long dot problem if it
didn't allow an arbitrary amount of whitespace in between. 

So, obviously, it does allow lots of whitespace in between. And, of
course, comments. If you really hate your future maintainer, you could
even put some POD in between.

$xyzzy.foo();
$fooz.:foo();
$foo. :foo();

Or, if you prefer:

$xyzzy.:foo();
$fooz. :foo();
$foo.  :foo();

Or, if you actually LIKE the extra whitespace that the current long dot
mandates:

$xyzzy. :foo();
$fooz.  :foo();
$foo.   :foo();

 and . + as an generalization,

Of course, this works nicely with the operators it was inspired by, that
were also inspired by regex postfix operators: .*, .+ and .?. They
can also contain whitespace in our proposal.

The dot-colon fixes another problem too. You couldn't line them up
anymore:

$foo.?bar();
$foo.baz();   # makes the ? look like part of the method name

So, now you can:

$foo.?bar();
$foo.:baz();

And an illustration with whitespace in between:

$xyzzy.:foo();
$fooz. ?foo();
$fo.   *foo();

 and coexistence/removal of . . as a consideration

If we have dot-colon, we could keep the old long dot too. That would
work well with my preference for ... as the first part of the old long
dot, as three dots stand out much better at the end of a line:

$foo...
.bar();

Though that isn't really dependent on the old long dot. It can live
separately. In fact, postfix ... could be a generic eat whitespace
and pretend it wasn't there operator:

$foo...
.bar()...
.baz();

$foo...
.:bar();  # with normal old long dot, would be :bar(), looking like
  # a pair, not a method call.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

[svn:perl6-synopsis] r9004 - doc/trunk/design/syn

[autrijus]

Author: autrijus
Date: Sat Apr 29 08:27:29 2006
New Revision: 9004

Modified:
   doc/trunk/design/syn/S02.pod

Log:
* S02: Change the section headings Atoms and Molecules to the more
  descriptive Lexical Conventions and Whitespace and Comments.
  Reported by: Wassercrats

Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podSat Apr 29 08:27:29 2006
@@ -23,7 +23,7 @@
 These updates are not marked--if a Synopsis disagrees with its
 Apocalypse, assume the Synopsis is correct.)
 
-=head1 Atoms
+=head1 Lexical Conventions
 
 =over 4
 
@@ -71,7 +71,7 @@
 
 =back
 
-=head1 Molecules
+=head1 Whitespace and Comments
 
 =over 4
 

Fw: ([EMAIL PROTECTED]) Re: A shorter long dot

[Juerd]

I get a message like this for every message that I send to this list.
Trying to contact [EMAIL PROTECTED] did not result in response or change.

Any ideas?

- Forwarded message from sbc sbc [EMAIL PROTECTED] -

From: sbc sbc [EMAIL PROTECTED]
Date: Sat, 29 Apr 2006 08:31:24 -0700 (PDT)
To: [EMAIL PROTECTED]
Subject: Re: A shorter long dot

Testing with sbc30k

 [EMAIL PROTECTED] wrote:
 16:50  audreyt Juerd: write to p6l and explain the .. conflict,

The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable, is quite a lot.

Illustration:

$xyzzy.foo();
$fooz. .foo();  # doesn't line up, so we have to change the
# *previous* line!
$foo. .foo();   # this lines up again.

So we use:

$xyzzy. .foo();
$fooz.  .foo();
$foo.   .foo();

which is ugly and feels bad. It feels bad, because we're adding much
more whitespace (two character positions in total) than we had to
bridge. And it's a lot of work (many, many keystrokes!) to go back and
change something.

However, the whitespace in between cannot simply be made optional, as
then it would clash with the range operator. As ranges are even more
important than a sane long dot solution, the long dot had to change.

Larry indicated that changing the long dot would have to involve
changing the first character. The only feasible solution in the tiny
glyphs section was the backtick. I refrain from explaining why that
will widely be considered a bad idea.

Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with

 and propose .: as a solution,

That's right, dot-colon. There are more glyphs available, but none of
them is nice like this. The basis is in regexes, where a colon means you
commit to have parsed the left side of the colon. That's how the colon
already reads in the indirect object notation, and the colon in
$foo.map:{...} can already be read.

So the actual solution is to make the method call operator not ., but
.:. Of course, a lone . still works and is the recommended style for
all simple method calls that don't have to be lined up. You can also
explain it as . still being the base operator, where .: is a special
form. Whatever you like best :)

 and . : as an extension, 

Of course, it wouldn't be a solution to the long dot problem if it
didn't allow an arbitrary amount of whitespace in between. 

So, obviously, it does allow lots of whitespace in between. And, of
course, comments. If you really hate your future maintainer, you could
even put some POD in between.

$xyzzy.foo();
$fooz.:foo();
$foo. :foo();

Or, if you prefer:

$xyzzy.:foo();
$fooz. :foo();
$foo.  :foo();

Or, if you actually LIKE the extra whitespace that the current long dot
mandates:

$xyzzy. :foo();
$fooz.  :foo();
$foo.   :foo();

 and . + as an generalization,

Of course, this works nicely with the operators it was inspired by, that
were also inspired by regex postfix operators: .*, .+ and .?. They
can also contain whitespace in our proposal.

The dot-colon fixes another problem too. You couldn't line them up
anymore:

$foo.?bar();
   

- End forwarded message -


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: A shorter long dot

[Yuval Kogman]

On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote:
 This would make the enormous semantic difference between:
 
foo. :bar()
 
 and:
 
foo  :bar()
 
 depend on a visual difference of about four pixels. :-(

You're not counting the space around the dot, which counts. To me
they look completely different

 We need to be careful not to require the language to solve problems that
 are better solved with tools.

On that point I agree, but I think it was a question of
aesthetics... Juerd?

$foo. .bar;
$ba.  .bar;
$x.   .bar;

$foo.bar;
$ba.:bar;
$x. :bar;

Frankly I don't think there's *that* much of a difference - each has
pros and cons.

-- 
  Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org  0xEBD27418



pgpWe4XRnb3kg.pgp
Description: PGP signature

Re: Fw: ([EMAIL PROTECTED]) Re: A shorter long dot

[Yuval Kogman]

On Sat, Apr 29, 2006 at 18:12:34 +0100, Nicholas Clark wrote:
 On Sat, Apr 29, 2006 at 05:59:37PM +0200, Juerd wrote:
  I get a message like this for every message that I send to this list.
  Trying to contact [EMAIL PROTECTED] did not result in response or change.
  
  Any ideas?
 
 Forward that message (with full headers) to [EMAIL PROTECTED]
 who will then apply the LART.
 
 As I figure I'm about to get one, I'll (also) forward mine.

Just got one...

By LARTing you mean forcibly unsubscribing? because the message was
sent to me directly too...

-- 
  Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org  0xEBD27418



pgpXVm8b225FF.pgp
Description: PGP signature

Re: A shorter long dot

[chromatic]

On Saturday 29 April 2006 16:58, Yuval Kogman wrote:

 On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote:

  This would make the enormous semantic difference between:
 
 foo. :bar()
 
  and:
 
 foo  :bar()
 
  depend on a visual difference of about four pixels. :-(

 You're not counting the space around the dot, which counts. To me
 they look completely different

Two invisible things look completely different to you?

-- c

Re: A shorter long dot

[Yuval Kogman]

On Sat, Apr 29, 2006 at 19:03:28 -0700, chromatic wrote:

 Two invisible things look completely different to you?

If dots looked like this:



then they would be invisible.

-- 
  Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org  0xEBD27418



pgplPt8CiApME.pgp
Description: PGP signature

Re: A shorter long dot

[Jonathan Lang]

Damian Conway wrote:

Juerd wrote:
 Audrey cleverly suggested that changing the second character would also
 work, and that has many more glyphs available. So she came up with

 and propose .: as a solution

 $xyzzy.:foo();
 $fooz. :foo();
 $foo.  :foo();

This would make the enormous semantic difference between:

foo. :bar()

and:

foo  :bar()

depend on a visual difference of about four pixels. :-(

We've strived to eliminate homonyms from Perl 6. I'd much rather not introduce
one at this late stage.


Is there a reason that we've been insisting that a long dot should use
whitespace as filling?

To me, foo.   .bar shares a common problem with foo.   :bar - in
both cases, my gut instinct is to consider foo and bar to be
separate entities, disconnected from each other - quite the opposite
of what's intended.  OTOH, this problem would go away if the filler
was primarily, say, underscores:

 foo.___.bar

or

 foo.___:bar

visually look like foo and bar are attached to each other.

Of course, without any sort of whitespace, there would be no way for a
long dot to span lines; so you might want to allow newline characters
as well.  But then, you run into problems such as:

 foo.
 ___.bar

being illegal, because the second line contains leading whitespace characters...

Perhaps you would be best off allowing both whitespace characters and
underscores as filler, and strongly suggesting that whitespace only be
used to span lines: by convention, the only whitespace that ought to
be used in a long dot would be something that matches /\n\s*/.

With this in place, the distinction would be between

 foo.:bar

and

 foo   :bar

...very easy to distinguish.

--
Jonathan Dataweaver Lang

Re: A shorter long dot

[chromatic]

On Saturday 29 April 2006 18:29, Yuval Kogman wrote:

 If dots looked like this:



 then they would be invisible.

Use a laptop with a speck of dust in the wrong place in slightly wrong 
lighting and the wrong four pixels might as well be invisible.

Precious few of @Larry deserve the nickname Ol' Eagle Eye.  This really 
doesn't seem like a place to argue for such subtlety when the difference in 
behavior is so large.

-- c

Re: A shorter long dot

[Austin Hastings]

Audrey Tang wrote:

Damian Conway wrote:
  

Juerd wrote:


and propose .: as a solution


$xyzzy.:foo();
$fooz. :foo();
$foo.  :foo();
  

This would make the enormous semantic difference between:

   foo. :bar()

and:

   foo  :bar()

depend on a visual difference of about four pixels. :-(



Good (and floating) point.  How about this:

$antler.bar;
$xyzzy.:bar;
$blah. .bar;
$foo.  .bar;

That is, introduce only the non-space-filled .: variant, and retain the
space-filled long dot.
  


How about if we replace dot with - and then you can specify any number
of dashes for alignment:

$antler-bar;
$xyzzy--bar;
$blah---bar;
$foobar;

Or, to put it another way: what hard problem is it that you guys are
actively avoiding, that you've spent a week talking about making
substantial changes to the language in order to facilitate lining up
method names?

=Austin

Re: A shorter long dot

[Damian Conway]

Good (and floating) point.


Boom boom! ;-)


How about this:


$antler.bar;
$xyzzy.:bar;
$blah. .bar;
$foo.  .bar;

That is, introduce only the non-space-filled .: variant, and retain the
space-filled long dot.


But do we really need *three* distinct forms of method call, in addition to
the (easily alignable) indirect object syntax?

Is:

 $antler. .bar;
 $xyzzy.  .bar;
 $blah.   .bar;
 $foo..bar;

really so intolerable, for those who are gung-ho to line up the method names?

Damian