> So bool would perhaps be a synthetic property that has opposite
polarity
> from bit? I can see that, sort of. It's something like electrons
being
> negative, thank you Mr. Franklin.
s/bit/yes/
yes?
And, despite perl5's use of no as the opposite
of use, and given that there may be no use in
> If you're trying to confuse me, I can assure you it's unnecessary.
;-)
Hey, I try.
--me
(Under cover Ruby/Python agent and
promotor of RFCs 380 thru 1,000,000)
> Well clearly "on" is the opposite of "no". Yes?
maybe, as in:
my cat maybe Dog;
for some form of relaxed typing constraint.
My apologies if the following has already been suggested.
I know Larry said the colon was his, but presumably he's
not talking about the double colon, as currently used as a
package name separator, right?
What if:
use Foo::Bar qw/ qux waldo /;
can be written:
use Foo::Bar :: qux waldo
Larry:
> Currently, @ and [] are a promise that you don't intend to use string
> indexing on this variable. The optimizer can make good use of this
> information. For non-tied arrays of compact intrinsic types, this
> is going to be a major performance win in Perl 6.
Assuming that optimization
> : Assuming that optimization opportunities remained intact,
>
> They won't, but go on.
Because the syntax won't provide the compiler enough info?
> : do you think conflating @ and % would be a perl6 design win?
>
> Nope, I still think most ordinary people want different
> operators for stri
Larry:
> : > Currently, @ and [] are a promise that you don't intend to use
string
> : > indexing on this variable. The optimizer can make good use of
this
> : > information. For non-tied arrays of compact intrinsic types, this
> : > is going to be a major performance win in Perl 6.
Clearly the
Larry,
No need to respond to individual points, because you
are so clearly wrong. ;> But I would appreciate an
overall response of something like either "this ain't
happening, so give up" or "it remains a possibility,
but I'm not yet remotely convinced". Thanks for your
continued forbearance.
>
> an ordered hash is common
Arrays too.
> not wise ... to alter features just for beginners.
Agreed.
> (PS 11 people isn't a statistic, its a night at the pub)
Your round...
The extra complexity of a separate hash syntax might
be justified for other reasons, but not the ones
> Hm, OK. What does this access and using what method ?
>
> $foo = '1.2';
> @bar[$foo];
This is an argument against conflating @ and %.
It has nothing to do with using [] instead of {}.
(I accept that the @/% issue is problematic. Otoh,
I don't yet see @/% conflation as being obviously
a b
e with that.
My vote is now against conflating [] and {}.
---
Please bear with me just a (hoefully little) longer.
Ok, why not deprecate %foo and always use @
instead and have [] and {} represent two indexing
name spaces?
In perl 6 experiments, and perl 7, you'll have % to
play with.
Graham Barr said:
> I am not interested in continuing this in private.
As you wish.
> If you don't want your comments public then be quite.
I thought it was best for the list if we had some private
exchanges first to reduce noise. I'll try to remember
that you don't like that approach.
> surv
> As someone else pointed out (I forget who). But beginners are not
> always the best people to ask. Beginner don't stay beginners for
> long I think the quote was.
And as I said before, I agree.
I picked the beginners list as much because it was
active as anything else. They are *somebody* afte
> (i.e. ordered or "associative").
A (probably futile, but one has to try) plea for
people to use "numbered" rather than "ordered".
@foo = ['England', 'France', 'Germany'];# unordered
%foo = {First => Fred', Last => 'Bloggs']; # ordered
(I'd also suggest "named" instead of the scie
I will read replies, and respond to off list emails,
but I will refrain from posting to the list on this topic
for at least one week.
If you have nothing new to add, then please don't post.
Suggestion: pseudohash.
%foo{Fred} = 'Bloggs';
$bar = %bar[1];# $bar is 'Bloggs'
Suggest
Just a thought. No need for replies.
Suggestion: rename local your.
my is mine, nothing to do with anyone else's code.
our is ours, used in my code and declared in a package
known to my code.
your is yours, the value used in code I call. Oh, and
it's also ours.
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
Right?
Should there be a strict mode that warns if a
method name matches a built in property name?
trict mode that warns if a
method name matches a built in property name?
--
Q1 followed from me thinking about my/our concepts
as they might apply to properties. The more I thought
about it, the more I gravitated toward the proposed
system (lowercase for builtins, Mixedcase for use
pretty much exactly what I was thinking.
One of several benefits would be to help deal with the
introduction of new properties in later Perl versions.
When an older class was used with the newer Perl,
conflicting names would immediately break or warn,
which it seems to me would be a Good Thing.
> On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote:
> > Question 1:
> >
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to
>> Consider the code:
>>
>> my $foo = 1 is Found;
>> &bar($foo);
>>
>> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>>
>> Does the value of $baz have the Found property?
>
> Yes.
>
>> If so, does the compiler know that?
>
> No. Because i
t, where I had my doubts about stricture being
an on topic perl6-language issue, I have none
about static analysis support from the compiler.
So, no more on that here from me...
> Larry's MMV on that ;-)
Man I really need to get up to speed with these
acronyms. I know YMMV, is MMV a distant
cousin perhaps?
> [strict typing]
>
> Not a negative, but realize that many people find it
> of less value than the annoyances it brings with it
> (myself included)
Michael, I don't know which is more impressive; the
fact that use of a strictly typed language implies that
a copy of you would land on the poor un
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
>
> it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thi
> I have done a quick scan of the archives for a
> discussion on this topic and didn't see it; if I
> just missed it, I'd appreciate it if someone
> could send me a link to the thread or
> applicable RFC[s].
I suspect you didn't use the all search, right?
Just
(The intent is that) Perl 6 will be a better general purpose
programming language for building application specific
sub-languages.
I'm interested in how far Perl 6 could go in providing support
for a high-level expressive syntax sub-language for dealing
with relational data. To the extent the gen
> the end user is going to be able to
> redefine the syntax anyway,
Yes. But if the syntax for arrays and db data are to
be simultaneously the same and as ideal as possible,
then either the core array syntax needs to be relatively
ideal for relational db data, or one needs to redefine
the array s
ot of database access, what do you
suggest IS a good fit?
> array (or hash, you don't seem to care)
Records have named fields so one dimension is like a hash.
> Get started now - Perl 5's..
...arrays are one dimensional.
> tie and overload support should be more than
Sam, I don't think we're on the same wavelength.
So a direct response seems pointless.
Larry himself said:
"while allowing multidimensional arrays to distinguish
between [this and that] in a manner more conducive to
database programming"
Ok, I did s/numerical/database/, but what's
> modeling of the whole database
Doesn't seem like it's hard to do.
With MD arrays, you are all but there anyway:
Table:
A 2d array.
Whatever is introduced to more directly support
handling MD arrays could very plausibly help in
more directly supporting handling of single tabl
cond col of
array 2 would pick both rows from both arrays.
Seems simple to me. Perhaps you meant the concrete
method and/or syntax to achieve the join, or to reference
the two arrays, or to reference the result table. But thinking
of concrete details like that is way premature.
For one thing, if Simon
oins between arrays, and Nd discontiguous slice
subsets across joined arrays) to be a powerful yet
simple general purpose algebra for creating
normalized tabular datastructures. This has nothing
to do with dbs, even less to do with SQL, and
everything to do with general purpose programming
expressiveness.
> > For what it's worth, I like it.
>
> So do I, actually... it's sort of growing on me.
Me too. (I think it (~ for concat, ^ for negation) is just fine.)
The "clash" with =~ is disappointing though.
Now if Larry had the cahones to change the =~ operator...
(I
ies if one applies
several of these:
$foo : bar baz qux
instead of
qux(baz(bar($foo)))
I realize this isn't particularly appealing, but bare with me
a little longer.
So, in:
$foo : bar
bar in this context is not a property, but instead a more
general "post" or similar (allu
> Me:
[$foo is bar] can change the value of $foo.
> Damian:
Yes. For example:
my $foo is persistent;
Could you explain this further please?
> Me:
$foo : bar baz is roughly equivalent to baz(bar($foo))
> Damian:
Err. No. T
> > What I was suggesting was to consider broadening what the
> > $foo : bar style postfix sub syntax allows/assists bar to do,
> > so that bars can be used to set properties OR do other stuff.
> >
> What's the practical utility of this?
1. Simplification for perl 6 implementation. I would expec
asing of multi-dimensional arrays into derived sub-structures?
In other words, isn't there a more general problem of how to provide
MD access and what to do with the currently one dimensional operations
like:
for (@foo) {
when @foo is multi-dimensional?
Jeremy Howard wrote RFCs that I th
> use strict 'recursive';
If this is not yet done and is deemed a good idea, I'd add that it
seems to me to be equally applicable to perl 5.
Further, considering the more general
[pragma] 'recursive';
I can imagine pragma adverbs / attributes.
I searched p
In a nutshell, you are viewing:
foo if bar;
as two statements rather than one, right?
Personally, I think it's more natural to view the above as one
statement, so any my anywhere in one element of it does not
apply to other elements of it.
ean something utterly different
in other common languages. And I never did find 'multimethods'
appealing either.)
Even if the dispatcher is the heart of multimethods, perhaps it
would be nice if it were convenient to replace the dispatcher
in whole or part. Kinda reminds me of the story of the old mop.
> If the dispatcher is drop-in replacable, what does its
> interface look like?
I'm thinking this is either deep in mop territory, or a probably quite
straightforward set of decisions about dispatch tables, depending
on how you look at things.
I found just one relevant occurence of 'mop' in perl
Dan, I don't immediately see how per object/class dispatch
control helps to make multimethods pluggable. Perhaps a
multimethod (a set of methods) is a class/object? Is there
a general mop for dispatch?
More generally:
> Yes. Ordinary subroutine overloading (like that offered by C++)
> certainly
>> What about if the symbol doesn't exist in the caller's scope
>> and the caller is not in the process of being compiled? Can
>> the new symbol be ignored since there obviously isn't any
>> code in the caller's scope referring to a lexical with that
>> name?
>
> No. Because so
A quarter-baked idea:
How about punting by using nan (all lowercase)
as a boolean logic not-a-number, leaving NaN
for someone to (later) create an IEEE style
tristate not-a-number.
Later:
$foo == NaN; # NaN literal is not same as nan literal
use NaN;
NaN(expr);
> [concerns over conflation of post-processing and post-assertions]
Having read A4 thoroughly, twice, this was my only real concern
(which contrasted with an overall sense of "wow, this is so cool").
--me
once at the time POST does.
Personally I'd leave this out until it became clear, well
past p6.0, whether it was really worth it, but it seems
worth mentioning.).
--me
icitly break
> out of a topicalizer, it should not be last. I'd suggest break!
> So it looks to me like we need a break.
I'm glad Larry didn't suggest 'done', because I really enjoyed Apo4.
I'll suggest it instead.
> I also happen to think that Exception i
lock you write clean up code that frees some
resources. If you inherit from that method, and do not
inherit the LAST block, then you've got a leak. This is
obviously a mild example.
--me
ited and the code
is not. One can optionally not inherit the conditions
(at least preconditions, from another post I just read).
And one can optionally inherit the code (by calling it).
Right?
Btw, are you going to have an equivalent of super?
--me
> [final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
, then one could type:
LAST: {
or
last: {
--me
"Non-yet-thrown exceptions must be a useful concept."
This is a bullet point from a list in Apo4 introducing
coverage of exception handling. Was Larry talking
about an exception object that hasn't yet been thrown?
Did he refer to this issue again anywhere else in the Apo?
--me
> But suppose you want all .foo to refer to self and not
> to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or
> The following syntaxes have been seen:
>
> foo()
> .foo()
> ..foo() ## rejected because ".." is different binary op
> class.foo()
> FooClass.foo()
> ::foo()
> Package::foo()
> $foo()
> $_.foo()
With a nod to Piers, and with apologes if this is silly in
the context of Perl 6 syntax, wh
Let me see if I understand the final version of your (Mike's)
suggestions
and where it appears to be headed:
Backwards compatibility:
perl5 extended syntax still works in perl6 if one happens to use it.
Forward conversion:
Automatic conversion of relevant perl5 regex syntax to perl6 is s
g to Larry, run time properties will most often be used
to contradict a built-in or compile time property. If he is right
about the dominant case being a contradiction, 'but' works
better for me than anything else I can think of, including 'now'
(explained below).
-
Even if
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
which is cool where being explicit simplifies things, but
ain't where implicit is simpler. So, maybe add an op ('$'?)
or switch that makes parens capturing by d
> Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)
> /pat/i m:i/pat/ or // or even m ???
Why lose the modifier-following-final-delimiter
syntax? Is this to avoid a parsing issue, or
because it's linguistically odd to have a modifier
at the end?
> /^pat$/m /^^pat$$/
What's the mnemonic here? It feels the wrong
way round -- like a single
Larry said:
> I haven't decided yet whether matches embedded in
> [a regex embedded] closure should automatically pick
> up where the outer match is, or whether there should
> be some explicit match op to mean that, much like \G
> only better. I'm thinking when the current topic is a
> match state
> : I'd expect . to match newlines by default. For a . that
> : didn't match newlines, I'd expect to need to use [^\n].
>
> But . has never matched newlines by default, not even in grep.
Perhaps. But:
First, I would have thought you *can't* make . match newlines
in grep, period. If so, then whe
> > : I'd expect . to match newlines by default.
I forgot, fourth, this simplifies the rule for . -- it
would become period matches any char, period.
Fifth, it makes the writing of "match anything but
newline" into an explicit [^\n], which I consider a
good thing.
Of course, all this is minor s
> when matching against something like "foo\nwiffle\nbarfoo\n"
>/(foo.*)$/ # matches the last line
/(foo[^\n]*)$/ # assuming perl 6 meaning of $, end of string
>/(foo.*)$/m # matches the first line
/(foo[^\n]*)$$/ # assuming perl 6 meaning of $$, end of line
or
/(foo.*?
[modified repost due to warnock's dilemma]
Would something like these DWIM?
# match pat1 _ pat2 and capture pat2 match:
/ pat1 { ($foo) = / pat2 / } /
# match pat1 _ 'foo bar':
/ pat1 { 'foo bar' } /
# match pat2 if not pat1
/ { ! /pat1/ } pat2 } /
# match pat2 if
I'm basically sold on Damian's conclusions. On the other
hand the 'otherwise' clause still feels to me like a CAPITALS
block.
So, as a tweak, I suggest:
while condition() {
...
}
NONE {
...
}
--
ralph
> : Would something like these DWIM?
> :
> : # match pat1 _ pat2 and capture pat2 match:
> : / pat1 { ($foo) = / pat2 / } /
>
> Yes
So a match in a closure starts where the outer match
was. Simple enough.
Will:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1 { ($foo)
Current p6 rx syntax aiui regarding embedded code:
/
#1 do (may include an explicit fail):
{ code }
#2 do with implicit 'or fail'
<( code )>
#3 interp lit:
$( { code } )
#4 interp as rx:
<{ code }>
/
This feels cryptic. Do we need abbreviated syntax for
> > $roundor7 = rx /<+[17]>/
> > That is: the union of the two character classes.
>
> Thank you; that wasn't in A5, E5 or S5. Will there be <-> as
> well?
>From A5:
The outer <...> also naturally serves as a container
for any extra syntax we decide to come up with for
charac
> Damian Conway wrote:
> >>And is the is/but distinction still around?
> >
> >Oh, yes.
>
> Could someone please reference where this decision was
> made. I do not find any information describing the distinction.
The following May 2001 post was related. Poke around the
thread it was in, especial
> [run time control of assignment behavior when array contains pairs]
How much have I misunderstood things from a mechanisms
available point of view (as against a practical / nice way to
do things) when I suggest something along the lines of:
my sub op:= (*@list : %adverbs) {
...
I may be missing your point, but based on my somewhat
fuzzy understanding:
> Oh. Duh. Why don't we have such a mechanism for matches?
>
> m/ my $date := /
>
> is ambiguous to the eyes. But I think it's necessary to have a
lexical
> scoping mechanism for matches
The above would at least hav
> I'm talking about just in the same namespace, how
> do we keep rules from messing with file-scoped
> (or any-scoped, for that matter) lexicals or globals.
> How do we get rule- or closure-scoped lexicals
> that are put into $0?
How about something like the following rework of
the capture/hypoth
In several forms of courier, and some other text fonts
I view code in, I find it hard to visually distinguish the
pattern element:
<( ... )>
from:
<{ ... }>
What about replacing the former syntax with:
?
--
ralph
Backtracking syntax includes:
:, ::, :::, ,
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
bikeshed might
> [EMAIL PROTECTED] (Me) writes:
> > 1. It's nice how the ':', '::', and ':::' progression indicates
> > progressively wider scope. But I would be surprised if
> > newbies don't say to themselves, "now just how wide a
> > sco
27;s where I add my other small niggle: it's not
clear to me /mnemonically/ which is which. Even if
you can tell which is a brace and which a paren, you
are still left wondering what each does when you're
learning this new stuff. I mean, which one of these is
executing some code t
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
I've looked before for discussion of the rationale behind
introducing attr/has and failed to find it. I noticed you
mention Zurich, so perhaps this decision followed from
discussion in living color (as against b+w).
Anyhow, what was deemed wrong with using my/our?
And...
> class Zap {
> my %.za
> Nothing the matter with "our" for class attributes since they're
> already stored in the package if we follow Perl 5's lead. But using
> "my" for instance attributes is problematic if we allow a class to
> be reopened:
>
> class Blurfl {
> my $.foo;
> }
> ...
> class Blurfl is
> Somebody fairly recently recommended some decent fixed-width
typefaces.
> I think it may have been MJD, but I can't find the reference right now
> (could be at work).
Michael Schwern recently suggested "Monaco,
Neep or, if you can find them, Mishawaka or ProFont".
I investigated and found this
> And that's also why we need a different way of returning from the
> innermost block (or any labelled block). "last" almost works, except
> it's specific to loops, at least in Perl 5 semantics. I keep thinking
> of "ret" as a little "return", but that's mostly a placeholder in
> my mind. I've g
> : > I wonder if we can possibly get the Rubyesque leaving out of
> : > endpoints by saying something like 1..!10.
> :
> : Similarly: 1 >..< 10 == 2..9
> There's also an issue of what (1..10) - 1 would or should
> mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
> mean (2..10)?
>
> A
> So despite the beauty of
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads square
> brackets too heavily.
What about using colon thus:
@a [:+] @b
or other character after the opening bracket, so long as that
character is not valid as the initial character
> hash ^[op] hash
> ...
> array ^[op] scalar
ie, generally:
term ^[op] term
> what to do if @a, @b in @a ^[op] @b have different length
> what to do if %a, %b in %a ^[op] %b have not the same set of keys
> what to do in %a ^[op] @a
>
> [what to do] resolved by hash property :
I'd exp
> > %a ^:union[op] %b
> >
> > %a :foo[op]:bar %b
>
> I think that any operators over 10 characters should
> be banished, and replaced with functions.
I'd agree with that. In fact probably anything over 4,
and even 4 is seriously pushing it.
I'll clarify that I am talking here about using
> > union:
> > intersection :
>
> How would this work for hashes with differing properties?
>
> %a ^is strict_keys;
> %b ^is no_strict_keys;
>
> What would happen?
That's one reason why I suggested control of this sort
of thing should be a property of the operation, not of
the operands.
--
ra
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection.
> temp sub infix:^[] is force_hash_to_intersect ;
Right. A property used as you suggest is effectively
an adverb applied at op definition rather than use.
> maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of
> length 3 ;
Right. It's quite plausible that one would want to be
> > 1) Need a definite syntax for hypers
> > ^[op] and <>
> > have been most seriously proposed -- something that keeps a
> > bracketed syntax, but solves ambiguity issues.
>
> hm. What was wrong with just '^' again?
Right. I didn't have a problem with ^ in the first place.
But...
A ^ prefix
> > A ^ prefix visually interferes a lot more
>
> I know it clutters up things a bit, that's my very argument; that
> ^[ ] clutters up things even *more*. especially, with use of arrays:
>
> @array[1,2,3] ^[+=] @array[4,5,6];
>
> bleah.
>
> @array[1,2,3] ^+= @array[4,5,6];
>
> Not much of a i
from the outside and makes
it the topic.
On its own this was no big deal, but it got
me thinking.
The key thing I realized was that (naming)
the invocant of a method involves something
very like (naming) the topic of a method,
and ultimately a sub and other constructs.
Thus it seems that wha
> After all, there's gotta be some advantage to
> being the Fearless Leader...
>
> Larry
Thousands will cry for the blood of the Perl 6
design team. As Leader, you can draw their ire.
Because you are Fearless, you won't mind...
--
ralph
> people on the list who can't be bothered to read
> the documentation for their own keyboard IO system.
Most of this discussion seems to focus on keyboarding.
But that's of little consequence. This will always be
spotted before it does much harm and will affect just
one person and their software
> > (naming) the invocant of a method involves
> > something very like (naming) the topic
>
> Generally, there's no conceptual link...
other than
> The similarity is that both are implicit
> parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of dec
> relatively few subroutines need access
> to the upscope topic.
Well, this is a central issue. What are
the real percentages going to be here?
Just how often will one type the likes
of
-> is given($foo is topic) { ... }
rather than
-> $foo: { ... }
?
My imagination su
> > My imagination suggests to me that in a
> > typical short perl 6 script
>
> That's some imagination you've got there! ;-)
:>
> My estimate (based on the -- not inconsiderable --
> code base of my own modules) is closer to 5%.
Your estimate of what oth
> Can currying include the given topic? Can
> I do something like:
>
> $foo = &bar.assuming( _ => 0)
>
> or whatever the latest syntax is?
Oops. More clearly:
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
--
ralph
> Will there be some shorter-hand way to say these?
> [list comprehensions]
(bb clarified that this is about hash slicing.)
>From A2:
RFC 201: Hash Slicing
...Concise list comprehensions will require
some other syntax within the subscript...
And
There are many ways we could re
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
> In your article at perl.com you describes
> various ways and situations when perl
> creates a topic and this is described as
> perl making the following binding on my behalf:
>
Damian:
> ["it" will be passed to about 5% of subs,
> regardless of whether the context is your
> 10 line scripts or my large modules]
If the syntax for passing "it" to a sub
remains as verbose as it currently is,
you are probably right that "it" won't
be used to achieve brevity! I think it's
a
1 - 100 of 138 matches
Mail list logo
