usly C and C. That is, $foo
can only contain something like C.
Damian
mes
back as a superposition too. If that returned superposition is
true, the assignment proceeds.
Damian
to satisfy a
superpositional type is an interesting question. I suspect it *is*.
Damian
7;s a lexical ambiguity, which can be
> solved with whitespace
...and the longest token rule.
And, of course, it's no more ambiguous than the ~~ operator:
foo ~~ $bar # means: foo() ~~ $bar
# not: foo( ~ ~$bar )
Damian
was actually: 'Perl on New
Implementation Engine'.
;-)
Damian
cluded that
there will be a LAST block *and* a POST block. With the appropriate
semantics differences.
Damian
uot; exception in the current block
UNDOSpecialized form of CATCH.
Executes on non-"control" exception in the current
block
Damian
iant checking, but I believe it should be via a
property on the class declaration:
class Positive
is always { $.value > 0 }
is always { $.feelings =~ /optimistic/i }
is always { $.polarity eq '+' };
Damian
Larry pondered:
> Perhaps we shouldn't be using ; for this.
That has occurred to me on several occasions but, checking my pockets, I
find I'm fresh out of spare symbols to replace it with.
We could always use colon, of course ;-)
Damian
Simon wrote:
> Given hyperoperators, I wonder if we can actually drop map.
So:
@result = map { block } @data;
becomes:
@result = {block}^.(@data);
Hmmm.
Damian
lain that it's only allowed to be a "naked
singularity" within a C. Elsewhere it has to be decently shielded
by the "statement event horizon" of a pair of brackets.
;-)
Damian
> Damian> @result = {block}^.(@data);
>
> But "hyperdot sort hyperdot" doesn't roll off the tongue as easy as
> "map sort map"!
H. You could always overload binary - to implement the sort.
Then it would be:
hyper dot dash
> Damian was meant to be writing Parse::FastDescent and then
> Parse::Perl,but as we all know, he's a Very Busy Man.
Indeed.
But my 2002 Perl Foundation grant list those two modules (only!) as
deliverables. I'd say they'll be delivered -- probably by Christmas ;-)
Damian
ve. Very illuminating.
Damian
the original predicate is true
for that file. Then one could write:
if ( $file == all(writable, directory) ) { ...
as well as:
@readable = eigenstates(any(@file) == readable));
Bwah-ha-ha-ha!
Damian
gt; -^rwx; # $_ is readable, writable and executable
> > >
> > > ($size, $mod, $acc, $ichange) = -^sMAC;
>
> The use of a caret was to prevent decimation of the user's namespace,
But the syntax already has a meaning under the very popular RFC 23: Higher
Order Functions. :-(
Damian
ing is not adequate in the general
(and common) case.
> I'm not sure Filter is the best name for this. How about Filter::Transform
> or Filter::Simple?
Filter::Simple is much better. Thanks. :-)
Damian
l "Short" or "Long". That's why I
proposed RFC 93 (http://dev.perl.org/rfc/93.html) instead of a mechanism
such as you have suggested.
Damian
n to making the code
available for everyone's amusement. Bear in mind that this was written
by a much early version of me (about 0.27), way back in the last
millenium, before C++ was standardized and before there was an STL.
Surprisingly, it still compiles and runs under g++ 2.8.1.
Grab it from: http://www.csse.monash.edu.au/~damian/Perl6/Regex/Regex.tar.gz
Damian
char)) {
$input.$nextchar =~ m/$pattern/;
if ($@ =~ /fail/) { beep }
else { $input .= $nextchar }
}
Damian
of the perl guts; not even in modules -- like Switch --
that may appear to do so.
Damian
s of whether
> it's using the object interface with the overloaded =~ or the new
> behaviour of =~ with a sub lvalue.
Good point. I think at this stage we're violently agreeing with each other. ;-)
Damian
my $result = $real_abc->(@_);
>do_post_handler($result);
>return $result;
>}
is just:
pre abc {
my $real_abc = (caller(0))[10];
do_pre_handler(@_);
$_[-1] = $real_abc->(@_);
do_post_handler($_[-1]);
}
Damian
use of subs from
the non-OO.
> Wouldn't you want all the pre-handlers invoked all the way up? Even
> if you don't care about the results of those pre's which are
> conditions?
Not for methods. Methods don't need inherited pre-*handlers*, since you
can already "wrap" them simply by providing an overriding method (one that
delegates via SUPER::) in the derived class.
Damian
> That's now DWIM for me!!!
Setting aside the error in the RFC, the point is that this isn't the way
you use pre and post in an OO context. If you have a class with a
next_temp that only handles Celsius, then you *derive* a new class with
a new, polymorphic next_temp that handles the
> >Or, should we just implement usleep() and (for lack of a better name)
>
> snooze() is a better name ;-)
nap() is even better (shorter that sleep() :-)
Damian
> Speaking of contract names, is Damien about?
No, but when you summon the AntiChrist, I sometimes appear instead. ;-)
Damian
push @unresolved, $sub;
}
Or else it checks all the candidates and resolves only if there is exactly one
whose condition is satisfied, generating an "Ambiguous subroutine..." error
if more than one condition is fulfilled.
Damian
ose this also implies a C subroutine (C'd,
of course :-) within modules -- so that one can replace:
@EXPORT_OK = qw( only by request );
with:
autouse only{requested},
by {requested},
request {requested},
;
H. Tidy, but too tedious perhaps?
Damian
y if the package's C is still called,
when it's in effect. All too often I want the convenience of Exporter, but
I need to twiddle the import semantics too.
Damian
echanism on *any* block. For historical reasons, I suppose it should be
C, though I would much prefer a more generic name, such as
C.
Damian
f" ...
> scalar()
> }
> continue {
> close F;
> }
RFC 271 handles this. Your example would be:
sub readit {
open F, "< $f" ...
scalar()
}
post readit {
close F;
}
Damian
l, in conjunction with the C:
while (1) {
... # add to $text in complex ways
}
continue { $text .= "\n"; } # separate with newlines
always { $trycount++ }# count attempts (including last)
Damian
> Of course all of this has been discussed. (See
> http://archive.develooper.com/perl6-language-io%40perl.org/,
> especially RFCs 100 and 14.)
And is already available in a nearby parallel dimension:
http://www.yetanother.org/damian/Perl5+i/open.html
;-)
Damian
Surely that should be:
use Policy::O::Reilly; # really gonna miss that ' package separator ;-)
or
use Policy::Mongolian::Navy::Office::Procurement;
Next you'll be putting the month and day before the year in dates!
Damian
> : Hey, that would make "_ _ __" legal Perl code. Abigail, Abigail!
>
> Now we just need to make "... ___ ..." mean something exceptional.
Just download the Bleach.pm module from the CPAN.
It includes Morse.pm.
Damian
---cut---cu
> > You Americans and your non-ISO penchant for putting the specific before
> > the general. Surely that should be:
> >
> > use Policy::O::Reilly;
>
> I knew someone would argue that, but I didn't think it would
> be someone
> > Because you might have a wantarray situation that expects no values?
> >
> > () = whateveryouwant();
>
> I am sure that situation is handled by the 'want' RFC.
Yep. The most recent version is at:
http://www.yetanother.org/damian/
> >Hopefully the "something similar", I hope in Perl 6 we will able to
> >bury the "0 but true" workaround to the backyard on a moonless night :-)
>
> Especially since you don't need it. "0E0" and "0.", to name just t
@d" in Perl5
>3. Or the mystery meat behind Door #3
This one's still less-than-certain. Definitely either 1 or 3 though.
If option 3, it would be the equivalent of the Perl 5:
%c = map {($_=>undef)} @d;
Damian
ike the current "while ()" magic we all know and occasionally
> love. I'd expect $FOO.readln (or something less Pascalish) to do an
> explicit readline to a variable other than $_
$STDIN.next is the current plan.
Damian
> Doubtless Damian could come up with a way to view them as hashes...
Well, of course.
An iterator is neither pure state nor pure behaviour. It's an
inextricable commingling of the two. In other words: an object.
So they are *most naturally* viewed as hashes:
package
Larry's
Apocalypses. Every time he writes another piece of the design, I'll
be illustrating it in code.
> Damian, is the code ready for public consumption yet?
I'm waiting on any feedback from Nat and Larry (who I'm sure have nothing
*else* to do with their time! ;-) before
foo.{$k})
Code reference $foo->(@a) $foo(@a) (or $foo.(@a))
Array slice @foo[$n]
Hash slice @foo{$k}
Damian
ules and
add a single line to your program:
use Attribute::Handlers autotie => { Sorted => 'Tie::SortHash' };
Then you can write:
my %hash : Sorted;
or:
my %hash : Sorted({}, sub { $hash{$b} cmp $hash{$a}});
etc.
Damian
PS: Casey, if you'd like to
> Perhaps it's because the people who are capable of writing such a
> module, are the ones who don't need it. But, not everyone is a conway.
Immortality at last...I appear to have become a common noun. ;-)
Damian
> @bar{$foo}; # C
Syntax error
> %bar[$foo]; # D
Syntax error
Damian
set) property on the node reference would have returned C which
would undergo the usual boolean conversion in the C, and the usual
promotion to zero in the numerical context of the increment.
Anyway, a patch is winging it's way to Simon even as I type.
Thanks for pointing out the snafu, John.
Damian
n conversion in the
C, and the usual promotion to zero in the numerical context
of the increment.
The point is that (as in Perl 5) neither of these two cases of undef
promotion trigger a warning, so there was nothing to alert me to the
fact that the initialization of the value was redundant!
;-)
Damian
ules that create as many synonyms as you feel are
needed/necessary/required/essential/requisite/demanded/called for.
Indeed even in Perl 5 it would not be hard to write a module that let you:
use Keyword::Synonym 'are' => 'is', 'mv' => 'rename', 'become' => '=';
H. ;-)
Damian
And if all of the above is true, what does this do to the size of
> the internal representation of a scalar?
In the worst case, it adds a single pointer to it. But it's entirely
possible that properties would be stored centrally, in which case
there's no impact at all.
Damian
not, as it's quite possible that the property hash will
only be built on-demand.
Damian
quot;;
>
> you get nada, right?
Right.
> So... why the *$#$ is it getting into the loop?
>
> There has to be a method to print out the *contents* of $fh, not
> just the values.
print $fh.true; # Just the truth
print %{(+$fh).prop}; # All the value's properties
Damian
false value to it, then yes, that does count as action-at-a-distance
> and is probably a Bad Thing.
Yes. perhaps even a Very Bad Thing. ;-)
> However, if assigning to $Foo clears the eariler assertion of truth,
> then there's no problem.
Yep.
Damian
<http://www.yetanother.org/damian/diary_latest.html> explains why.
Please accept my apologies.
As my final word on the subject (for the present at least ;-), and in the
interest of trying to resolve some of the issues raised, let me once
more attempt to clearly summarize the intent and usage of
I thought the "truth" property was attached to the value, not to the
> variable. So if you assign a new value to that variable, the truth
> property is overwritten, too.
Yep.
Damian
Can 'undef' valued thingys have functions?
That's why I said "no" to the second.
If the second question was actually:
Can functions have properties?
Then the answer is, of course, "yes".
Damian
ty.
Er...yes...that's rather the point of the exercise: to be able to
polymorphically override the behaviour of properties by defining
methods.
Should we deprecate inheritance because the functionality of a working
program can be completely changed/broken by defining a derived method
that conflicts with an inherited method?
Damian
6 made that possible.
>
I guess that would be:
$ref = sub{my%k;%k{+pop}=\(@_);splice@_,$_,!%k{$_}for @_..0:-1;@_}.(@A,\@I);
>
> Maybe it already does and I haven't grokked that from the exegeses yet.
>
I'm pretty sure Exegesis II doesn't mention *that* particular technique ;-)
Damian
p://search.cpan.org/doc/MARCEL/Attribute-TieClasses-0.01/TieClasses.pm
for even more ideas.
Damian
ference to a slice in perl 5 yields the list of the references
> to the slice members. Is that the way it's going to be in perl 6?
I would suspect so, since a slice is a list, not an array.
But, of course, that wouldn't preclude a different syntax for generating
a cross-sectional view of an array.
Damian
s wait and see what he makes of that proposal.
> (note that this does away with
> the (+spot).bark syntax that some people feel is ugly):
That's been addressed in my latest proposal too.
Damian
Scott wrote:
> Would you also advocate separate declarative syntax for variable
> properties and value properties? That's where I think much confusion
> will be.
That's covered in my new proposal too.
Damian
ip'.
Except that it would be the object reference in $spot that had the run-time
property.
> MVA$spot.bark (+$spot).bark
> 000Error Error
> 001yip yip
> 010arf Error
> 011arf yip
> 100woofwoof
> 101woofwoof
> 110woofwoof
> 111woofwoof
>
> yes?
Yes.
Damian
actually want the possibility of that kind of namespace collision:
for polymorphism.
Damian
) {
...
}
else {
die $res.Reason;
}
Should, of course be:
die $res.Because
Damian
of:
1 until defined(getvalue()); return it;
You can already write:
1 until defined($_=getvalue()); return $_;
which doesn't seem a huge extra burden.
Or, if you worry about $_ pollution, use this:
{return $_ for grep{defined or redo} getval()}
Damian
oClass $self) {
return $self{const} || $self.prop{const}
}
Damian
ecause it only has the property at run-time.
Damian
statically
analyzable in general. Though static determinacy is obviously a
desirable thing, there are plenty of other B&D languages that offer it
in abundance. And the dynamic power that Perl would have to lose would not
compensate for the static benefits gained.
Damian
PS: Of course, as always, Larry's MMV on that ;-)
^^
Sorry, in my haste I missed that twist. You are, of course, correct.
> >> Oh, hrm. Shouldn't it be $a{test2}?
> > Yes. Or $a.{test}
>
> So "." isn't necessarily the "property" operator, then? OK.
> Time to spend more quality time with YACC. :(
Now there's an oxymoron, if ever I heard one. ;-)
Damian
; Hm, I thought Larry said you would need to use $() to interpolate
> a method call. So this would be
>
> $bar =~ /$($foo.colour)/;
That was not my understanding. At least not for (pseudo-)method calls.
But many things are still in flux and I may well have missed a meeting. ;-)
Damian
ot;$file.ext" is
> going to be common. But I do think the $() approach is clean and
> unambiguous
I agree wholeheartedly.
But it's not as *convenient* as "unadorned" interpolation.
Expecially if we expect method calls to be frequently interpolated.
Damian
the $() is easier than the current perl5 way to do it.
There we definitely do agree :-)
Damian
subscript is optional,
There is no arrow. Only dot.
And yes, it's optional anywhere the dot acts like a /\b/ boundary:
$ref.[1]can be $ref[1]
$ref.{a} can be $ref{a}
$ref.(@args)can be $ref(@args)
$ref.meth() CAN'T be$refmeth()
Disclaimer: Rules #1 and #2 apply to all of the above.
Damian
f the object referred to by $ref.
Damian
elf->{a} }
>
> (Did I get that syntax right ? probably not :)
Try this:
sub a(Foo $self) is rw { $self{a} } # or $self.{a}
Damian
Dave Whipp asks:
> Does it do short-circuit evaluation, too?
I would certainly expect it to, yes.
Damian
believe it's vitally important not to mix everything together syntactically
(or semantically!)
Damian
) {...
but as special case syntactic sugar for the expANDed version:
if ($x < $y && $y < $z && $z < $foo) {...
Oh, and with only single evaluation of each operand.
Damian
Simon asked:
> Are properties subscriptable? (Can the value of a property be a
> reference that can be dereferenced?)
Property values can be any scalar value, including array, hash, and code refs.
> Can properties have properties?
No, but their scalar values can.
Damian
t;.interestearned += $interestrate * .balance
>
>}
Larry doesn't favour using C thus, beause it introduces a sly
list context. That argument convinced me.
But there might well be another keyword for the same idea and that might tie
into switch statements too.
Damian
> Sounds sensible, and worth sending past Damian.
It's certainly not unreasonable, though it doesn't mesh perfectly with
Perl's OO model. The easy solution (available in Perl 5 too) is to
autogenerate the interim MI-ing classes as needed:
my $next = "a";
> > The downside is of course that I need to make a small stub for every
> > single function I want to delegate.
>
> Well, that's relatively simple to automate...
>
> Wasn't Damian working on something like this? I looked at his
> deleg
ote aspect.)
No. There will, I hope, be a mechanism for pre- and postfixing
subroutines, but not properties I think.
> So, to recap:
>
> $foo : bar;
>
> means bar is posted to $foo. $foo's value may change
> or stay the same. The return value may be $foo's, either
> before or after posting, or some other value. $foo's value
> may now have an attached bar postit.
You lost me here. Your ideas for properties are different from mine
(which may well, in turn, be different from Larry's).
Damian
> > Me:
> [$foo is bar] can change the value of $foo.
>
> > Damian:
> Yes. For example:
> my $foo is persistent;
>
> Could you explain this further please?
The programmer has specified a property named 'per
e HASH reference as ARRAY!
> Quandary #3: Should / will perl6 support polymorphic typing?
Probably. But that may require a more sophisticated type system than
most people would like to see (or implement!) in Perl.
Damian
his I'm not totaly sure, but it comes to my mind many modules
> uses notation like this to pass params i.e.
>
> someFunc ( -param1 => 'blah', param2 => 'xxx' .)
>
> Why not have %_ in our case we have the following elements :
http://dev.perl.org/rfc/128.html#Named_arguments
Damian
> Damian,
> You mentioned in E2 that the chomped property relies on the insep
> property of the filehandle (formerly $/). Can I extrapolate that
>$.
>$,
>$\
>$|
> will also be properties on filehandles? (How about
>
within expression n - the equivalent to 'default:'?
> given ( a() ) {
>print $^_; # No when clause? See #1
> }
$^_ isn't an alias for the C's expression.
It's a higher-order function placeholder
(see: http://www.yetanother.org/damian/Perl5+i/higheror
Larry, but I will now reproduce it here to
show my current thinking on the subject.
Damian
---cut---cut---cut---cut---cut--
It seems that my property concept is becoming a little chunky.
So let me try again...
Suppose variables and subroutines had
stant Counter" if $self.constant;
}
> # However, if I do
> #
> # %foo is constant = (a=>1, b=>$foo);
> #
> # are only the keys contant; or both the keys and values.
>
> Keys and values, I imagine.
Probably.
Damian
onsider (variable versus
> value, and hash versus array versus scalar versus filehandle), are
> properties that are meaningless for some section usable by the user?
I would expect so, but Larry's MMV.
Damian
reday scheduled for termination.
In Perl 6, the expression C<&foo> returns a reference to the C subroutine.
Damian
ver.bark_at($felix); # method sig checked at run-time
# (type of both not known till then)
One might also envisage a C pragma to require that
all lexicals be typed.
Damian
, item3, ..."
> }
I would expect so, though I'm not sure that would be the syntax.
> If it's not possible, I think it should be :)
I agree.
Damian
ariable used as a subroutine/method argument,
but it's a good idea.
Damian
> > I sure miss multi-dispatch.
http://dev.perl.org/rfc/256.html
Damian
er for each combination. For example, a MoveEvent sent to
a FixedWindow causes a beep, but a MoveEvent sent to any other type of
window is dispatched to the more-generic handle(Window $w, MoveEvent $e)
subroutine, which causes it to move.
Damian
> 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.
I'm sure if we asked Dan nicely, he'd consider hanging the dispatcher on
a lexically-scoped hook to make that possible ;-)
Damian
1 - 100 of 1244 matches
Mail list logo
