Re: Whither use English?
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
Re: Hyper operator corner case?
I found where Damain explains the rule as basically replicate dimensions,
extend lengths, using an identity value when extending the length.
http://www.mail-archive.com/perl6-language@perl.org/msg08304.html
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: subscripts are.... objects?
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: subscripts are.... objects?
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
%hashfoo | %hashbar | %hashbaz
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: Hyper operator corner case?
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?
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
should we change [^a-z] to -[a..z] instead of -[a-z]?
In writing some character class translation, I realized that -[a-z] and its ilk are rather hard to read because of the two hyphens that mean different things. We can't use ![a-z] because that's a 0-width lookahead. 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. 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. Larry
Macros [was: Whither use English?]
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: should we change [^a-z] to -[a..z] instead of -[a-z]?
At 5:21 PM -0700 4/14/05, Larry Wall wrote: In writing some character class translation, I realized that -[a-z] and its ilk are rather hard to read because of the two hyphens that mean different things. We can't use ![a-z] because that's a 0-width lookahead. 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. 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. Larry I don't see why the old syntax has to be supported at all. Lots of other regexp details are already being changed, such as the bounding '' and the removal of the leading internal '^', so people already have to edit their regexps. So they can replace the '-' too while they're at it; not very difficult. Moreover, I often create character classes that have a literal '-' in it, and it would be nice to not have to make that the last character in the class for it to parse properly. Also, the '..' is easy to learn because it is consistent with other parts of Perl 6. Likewise, the consistency is another plus when demonstrating what is good about Perl to folk who don't use it. -- Darren Duncan
Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
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
Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
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]
