Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?

[David Wheeler]

On Apr 14, 2005, at 7:06 PM, Patrick R. Michaud wrote:
So, <[a.z]>  matches "a", ".", and "z",
while   <[a..z]> matches characters "a" through "z" inclusive.
I was going to say that that was inconsistent, but since you never need 
to repeat a letter in a character class, well, I guess it isn't. But 
the first person to write <[a...]> gets what's comin' to 'em.

Regards,
David
--
David Wheeler
President, Kineticode, Inc.
http://www.kineticode.com/
Kineticode. Setting knowledge in motion.[sm]

Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?

[Patrick R. Michaud]

On Thu, Apr 14, 2005 at 05:21:05PM -0700, Larry Wall wrote:
> Given that we're trying to get rid of special
> exceptions, and - in character classes is weird, and we already
> use .. for ranges everywhere else, and nobody is going to put a
> repeated character into a character class, I'm wondering if
> 
> <-[a..z]>
> 
> should be allowed/encouraged/required.  It greatly improves the
> readability in my estimation.  

So, <[a.z]>  matches "a", ".", and "z", 
while   <[a..z]> matches characters "a" through "z" inclusive.

I think that works for me.  I'll implement it that way (and yes, there
*are* updates to PGE coming very soon!).  

I guess I can't complain too loudly about ".." over "-" for ranges
since I was the one who suggested replacing "," with ".." in quantifiers
(e.g., {1..3} instead of {1,3}).  Not that I'd be complaining anyway.  :-)

> The only problem with requiring .. is
> that people *will* write <[a-z]> out of habit, and we would probably
> have to outlaw the - form for many years before everyone would get
> used to the .. form.  So maybe we allow - but warn if not backslashed.

Just to make sure I have it right, by "allow -" you mean that 
<[a-z]> matches "a", "-", and "z" and produces a warning 
about an unescaped '-'?

Pm

Macros [was: Whither "use English"?]

[Sam Vilain]

Larry Wall wrote:
(B> Well, only if you stick to a standard dialect.  As soon as you start
(B> defining your own macros, it gets a little trickier.
(B
(BInteresting, I hadn't considered that.
(B
(BHaving a quick browse through some of the discussions about macros, many
(Bof the macros I saw[*] looked something like they could be conceptualised
(Bas referring to the part of the AST where they were defined.
(B
(Bie, making the AST more of an Abstract Syntax Graph.  And macros like
(B'free' (ie, stack frame and scope-less) subs, with only the complication
(Bof variable binding.  The ability to have recursive macros would then
(Brelate to this graph-ness.
(B
(BWhat are the shortcomings of this view of macros, as 'smart' (symbol
(Bbinding) AST shortcuts?
(B
(BThe ability to know exactly what source corresponds to a given point on
(Bthe AST, as well as knowing straight after parse time (save for string
(Beval, of course) what each token in the source stream relates to is one
(Bthing that I'm aiming to have work with Perldoc.  I'm hoping this will
(Bassist I18N efforts and other uses like smart editors.
(B
(BBy smart editors, I'm talking about something that uses Perl/PPI as its
(Bgrammar parsing engine, and it highlights the code based on where each
(Btoken in the source stream ended up on the AST.  This would work
(Bcompletely with source that munges grammars (assuming the grammars are
(Bworking ;).  Then, use cases like performing L10N for display to non-
(BEnglish speakers would be 'easy'.  I can think of other side-benefits
(Bto such "regularity" of the language, such as allowing Programatica-
(Bstyle systems for visually identifying 'proof-carrying code' and
(B'testing certificates' (see http://xrl.us/programatica).
(B
(Bmacros that run at compile time, and insert strings back into the
(Bdocument source seem hackish and scary to these sorts of prospects.
(BBut then, one man's hackish and scary is another man's elegant
(Bsimplicity, I guess.
(B
(B* - in particular, messages like this:
(B- http://xrl.us/fr78
(B
(Bbut this one gives me a hint that there is more to the story... I
(Bdon't grok the intent of 'is parsed'
(B- http://xrl.us/fr8a

Re: subscripts are.... objects?

[Larry Wall]

On Thu, Apr 14, 2005 at 07:29:43PM +0200, Juerd wrote:
: So, what's the important downside of all this?

The fact that smartmatching a list doesn't slice, but is defined to
be array equality with smartmatch of each element in order:

if @array ~~ (1,2,3,"many") { say "array can count" }

Larry

Re: Hyper operator corner case?

[Larry Wall]

On Thu, Apr 14, 2005 at 11:08:21AM -0600, John Williams wrote:
: Good point.  Another one is: how does the meta_operator determine the
: "identity value" for user-defined operators?
: 
: (1,2,3,4,5) >>my_infix_op<< (3,2,4)
: 
: Maybe we should say that the excess length is simply copied unchanged.
: But some might argue that not calling the op for each element would be
: cheating somehow.  That's not my position, but I cannot think how to
: refute it right now, if you want the side-effects.

One naive possibility is to supply one identity value per precedence level.
Then you could get 0 for addition and 1 for multiplication.  Doesn't
really work though, given there are so many different kinds of addition
and multiplication lumped together.  Arguably the identity value for %
is Inf.

Another approach to get the side effects would be to assume that
whatever "meta" code is actually calling the scalar operator is
smart enough to coerce ordinary undefs into "undef but identity"
or some such that each individual operator would know how to deal
with rather than generating an exception/undef.

: > What I ask myself is wether (1,2,3) »+ 1 should be a syntax error or just
: > a different form to express the :(List,Scalar:&) case. BTW, I know that
: > &infix_prefix_meta_operator:{'»'} isn't mentioned in A12.
: >
: > > I could be wrong, though; I can't find any support for it in the design 
docs.

We decided that binary ops should always just have »« on both sides,
since it's essentially just a single "dwim this" bit of information.

Basically, »« is just a flagrant value of "1".

: "Replicate dimensions" is specified in the first version of A3.
: 
: The length issue was resolved on the mailing lists.
: Could someone add the ruling to S3 to answer this FAQ?
: 
: I believe the fine points fall out like this:
: 
:@a >>+<< 1# replicate
:@a >>+<< (1)  # replicate: (1) is still scalar
:@a >>+<< [1]  # extend: [1] is an array (and will auto-deref)

Yes.  Parens in scalar context do not automagically produce a list.
Comma is another matter, so

   @a >>+<< (1,)

turns out to be the same as

   @a >>+<< [1]

since there is no scalar comma operator in Perl 6.

All that being said, it's almost certainly the case that (1) is
a mistake.  and should perhaps produce a warning: "Useless use of
parentheses" or some such.  Not that we frown on useless use of
parentheses in general, since they're often clarifying precedence.
But nobody should be confused about the precedence of a simple term.

Larry

Re: subscripts are.... objects?

[Juerd]

Larry Wall skribis 2005-04-14 10:11 (-0700):
> Interestingly, if .{} defaulted to smart matching, ordinary .{'foo'}
> would essentially fall out of the samantics of "find me all the keys
> that smartmatch "foo", which is only one of them, presuming a hash
> that guarantees uniqueness.  One could view .{} as Perl's version of
> SQL's "select".

@foos = %hash{ /^foo_/ } ».value;

Wow. I love that.

%handles{IO::Socket}

Nice.

But the best thing about this is that it makes junctions more
meaningful:

%hash{'foo' | 'bar' | 'baz'}

I think meant

%hash | %hash | %hash

But indeed, SELECTing with ~~ is more useful:

%hash{ IO::Socket | IO::File | 'foo' }
%hash{ grep { %hash{$_}.does(IO::Socket|IO::File) || exists %hash{$_} }, 
%hash.keys }

So, what's the important downside of all this?


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

Re: subscripts are.... objects?

[Larry Wall]

On Tue, Apr 12, 2005 at 06:58:29PM +0300, Yuval Kogman wrote:
: 
: We blitzed a discussion on #perl 3 minutes ago, reaching the
: conclusion that negated subscripts are cool.
: 
: So i was thinking:
: 
: subscripts are objects.

I'm all in favor of powerful constructs, but we need to be *really*
careful not to compromise the visibility of ordinary integer
subscripting to the optimizer.  At one time we proposed that a
subscript could be either an ordinary slice or any selector that
could be smartmatched against the available indexes, but lately we've
been leaning toward the idea that subscripts are simple slices of
integers, and there should probably be an explicit method syntax to
tell the compiler to pessimize calls to fancy selectors.  As they say:
"Optimize for the common case."  And the common case here is integer
subscripting, by far.  That's basically all that distinguishes .[]
from .{}, after all (plus a bit of type checking).

Interestingly, if .{} defaulted to smart matching, ordinary .{'foo'}
would essentially fall out of the samantics of "find me all the keys
that smartmatch "foo", which is only one of them, presuming a hash
that guarantees uniqueness.  One could view .{} as Perl's version of
SQL's "select".

It could be argued that the same optimizability concerns apply to
hashes as well as arrays, but hashes are already bound into a fairly
heavy set of semantics, so going to the most general semantics via
MMD might not actually cost us much.  It might not cost us anything,
if general hash lookups have to go through MMD anyway.

Larry

Re: Hyper operator corner case?

[John Williams]

I found where Damain explains the rule as basically "replicate dimensions,
extend lengths", using an "identity value" when extending the length.


On Wed, 13 Apr 2005, Thomas Sandlaß wrote:

> Brent 'Dax' Royal-Gordon wrote:
> > IIRC, it's f) (1,2,3,4,5) >>+<< (1,2,$identity,$identity,$identity),
> > where $identity's value is determined by a table something like this:
>
> In the case of  &infix_circumfix_meta_operator:{'»','«'}:(List,List:&op)
> there's no "upgrade"---to use the S03 term.  A simple "apply &op where
> the lists overlap and keep the rest of the longer one" suffices.
> That is (1,2,3,4,5) >>+<< (1,2) becomes (1+1, 2+2, 3, 4, 5). For
> &infix_circumfix_meta_operator:{'»','«'}:(List,Scalar:&op) the upgrade
> works by applying the operator with the scalar to all entries:
> (1,2,3,4,5) >>+<< 1 becomes (1+1, 2+1, 3+1, 4+1, 5+1).

Good point.  Another one is: how does the meta_operator determine the
"identity value" for user-defined operators?

(1,2,3,4,5) >>my_infix_op<< (3,2,4)

Maybe we should say that the excess length is simply copied unchanged.
But some might argue that not calling the op for each element would be
cheating somehow.  That's not my position, but I cannot think how to
refute it right now, if you want the side-effects.

> What I ask myself is wether (1,2,3) »+ 1 should be a syntax error or just
> a different form to express the :(List,Scalar:&) case. BTW, I know that
> &infix_prefix_meta_operator:{'»'} isn't mentioned in A12.
>
> > I could be wrong, though; I can't find any support for it in the design 
> > docs.

"Replicate dimensions" is specified in the first version of A3.

The length issue was resolved on the mailing lists.
Could someone add the ruling to S3 to answer this FAQ?

I believe the fine points fall out like this:

   @a >>+<< 1# replicate
   @a >>+<< (1)  # replicate: (1) is still scalar
   @a >>+<< [1]  # extend: [1] is an array (and will auto-deref)

~ John Williams

Re: Whither "use English"?

[Larry Wall]

On Thu, Apr 14, 2005 at 01:25:15PM +1200, Sam Vilain wrote:
(B: Juerd wrote:
(B: >>According to Wikipedia there are around 400 million native English 
(B: >>speakers and 600 million people who have English as a second language. 
(B: >>Should the remaining ~5.5 billion humans be exluded from writing perl 
(B: >>code just so that we English speakers can understand all the code that is 
(B: >>written?
(B: >Yes.
(B: 
(B: So, you gladly invite the curse of semantic fixation.
(B: 
(B: $B2fITn3(B
(B
(BHmm, speaking of semantic fixation, in Japanese that last character
(Bhas come to mean "ambush" rather than "invite".  But either way,
(B
(B[EMAIL PROTECTED]&n3(B
(B
(B:-)
(B
(B(give or take a word order or two).
(B
(B: As we will know exactly what are symbols and what is code, it should
(B: even be possible to automatically perform L10N on source code, without
(B: breaking it.
(B
(BWell, only if you stick to a standard dialect.  As soon as you start
(Bdefining your own macros, it gets a little trickier.
(B
(B: So stop being empirical!
(B
(BEmpires also have their occasional uses.  :-)
(B
(BLarry