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
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
l core?
I have a paper on that ;-)
As soon as my brain arrives back in my native timezone, I'll will be putting
forward an RFC (one of many) on modularizing C along the lines of my
Text::Autoformat::form subroutine.
Damian
with a
clean slate and fix the things that are broken, or that could be designed
better with hindsight. Backwards compatibily was to be fed to the lions.
If that isn't the case, I'll be unsubscribing immediately -- if Perl 6
is to be a mere exercise in featuritis, I'm not interested.
Damian
holding the floor (though, like Nat, I'm
entirely confident they won't sway Larry's vote :-)
This discussion does raise an important point (probably OT for this
newsgroup): we must ensure that Perl 5 and Perl 6 *can* co-exist easily.
Damian
PS: Probably best to ignore most of what
ce for some operators
I had a paper on that.
The solution (which I with RFC RSN) is to provide a simple mechanism for
generating higher-order functions.
The one I proposed in the switch statement paper
(http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt) was
the __ meta-variable. Used in
bad final
state (or return value) into an exception. It does *not* offer a last
chance to monkey with the return value!
Damian
to a module can't simply be
> whether it's a system call or not, you must use something that takes
> into account the hindrance and the payoff.
Amen!
Damian
> >Also read Damien Conway's "Object Oriented Perl" if you want to go further.
>
> Unlike the famous title by Hesse, in this case that would be spelled
> DamiAn, actually. :-)
Yes, I'm named after a leper, not the AntiChrist ;-)
>
> In perl5,
>
> /(??{ $FOO })/
>
> delays the interpolation of $FOO, so as to be able to have
> recursively defined regexps.
Of course, that example might in itself be sufficient reason
to completely redesign the regex syntax!
Damian
PS: I'll prob
> Let me reiterate my view of pragmas. They can warp the language any
> way you please, as long as they don't impact other modules. I wouldn't
> even mind if someone wrote a pragma that lets you program Perl in Latin.
Now you're just being silly!
;-)
Damianus
> Formats out of core
> Switch statement
>
> Anyone want to put their name next to them?
Me.
Damian
s to the previous proposal in mind.
The current proposal is at:
http://www.csse.monash.edu.au/~damian/Perl/want.proposal
But, by all means, send me any further suggestions.
Damian
> > It was Damian's, no?
>
> I bet he has a paper on it.
http://www.csse.monash.edu.au/~damian/Perl/want.proposal
:-)
Damian
the context mechanism which I will RFC RSN
when I propose the new want() built-in to replace wantarray().
Damian
; if it wants an array, it tells you whether you were called in
> list context or not.
It should just be want() because I intend it to do *much* more :-)
> I will RFCify this within the next few days (unless someone
> can shoot it down right now).
http://www.csse.monash.edu.au/~d
something not entirely dissimilar
for the purpose of teaching:
use Training::Wheels;
or:
no Weird::Stuff;
Hm. I feel a paper coming on...
Damian
es of
two countries told me they were using Parse::RecDescent. SCARY!
Damian
that since it was mentioned that there was a debate on the issue
> some time ago).
Intending to RFC a proposal for that too...
Dear Mum and Dad,
Having a wonderful time on perl6-language.
Please send more tuits!
Damian
I have an RFC coming on this.
(I know, I know, I keep promising, but none appear.
I'll unload the first 10 or so later today, the gods willing)
Damian
his would be really cool.
I'll have a proposal out later today or tomorrow.
But others ought to consider putting one in too.
Damian
(in fewer chars even :-)...
$user = 'nwiger';
sub whois ($user) {
# ...
}
Damian
with $self automatically supplied)
One of my many RFCs will include a proposal for a $SELF variable along
those lines.
Damian
> > Please, please, *PLEASE* read through Damian's fine paper on this
> > entire matter before rendering judgment.
>
> URL?
http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt
Damian
ht out of my...err...fingers!
Although, of course, it will be $ME in line with the usual practice of
SHOUTING OUT MAGIC VARIABLES.
Damian
> Damian Conway wrote:
> > http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt
>
> Curried operators might be a nice way of generalizing the switch
> syntax. When we write:
I'm just about to post an RFC proposing exactly that (albeit with a
{$ME}
sub one {$ME}
sub obj {$ME}
sub TheObjectThatThisMethodWasInvokedOn { $ME }
# and later
sub shout {
self->set_name(uc this->get_name);
}
Of course, these particular subroutines might be a good (and easy)
target for inlining optimization.
Damian
Bible.
There's only one Larry.
We're just fortunate that he's a sufficiently large value of one.
Damian
semi-finite list. It is further proposed that operations on
> > such lists also be carried out lazily.
>
> This would be nice, but I think should be folded into something more
> general, like tieable first-class iterators. I'm still trying to pull
> my thoughts together on this one, but lazy lists could be a special
> case of iterators.
I have an RFC coming on that :-)
Damian
case 3 { print "three"; odds }
case 4 { print "three"; evens }
case __%2!=0{ odds }
case __%2==0{ evens }
}
Damian
{ print "that's odd" }
> case __%2==0{ print "that's even" }
> }
Damian
rror (even if you redefine operators so it should work!)
It *does* have a different (and stupid) meaning in C, but let's not go there.
Damian
x < $y.
I very much like Icon's failure model, but I was loathe to try and
graft it wholesale onto Perl 6. Doing it properly would require a
substantial rethink of the exception mechanism, flow control, the
nature of scalars, undef, etc., etc.
In the end I concluded that simple DWIMity on multiway comparisons
was enough.
But don't let that stop you counter-proposing the fuller mechanism. :-)
Damian
be the
> switch statement. "case" is simply a rename of "elsif" whose first
> occurrence in a block simply pretends to follow "if (0) {}".
If that's the consensus, let's just have elsif.
But I don't think that's the consensus.
I appreciate your comments, but I certainly intend to push ahead with
the proposed syntax -- as I proposed it. A very large number of people
like it as it is. If I'm wrong, let Larry kill it.
Damian
hat I suspect that we'll
just cheat and say that only pure assignment *doesn't curry*,
so you have to write:
my $summer = $sum += __;
$root->traverse( $summer );
Or for the truly damned in the audience:
$root->traverse( my $sum = $sum += __ );
Bwah-ha-ha-ha!
Damian
y, what I meant was that, you can bind trailing arguments, just by omitting
them. Non-trailing arguments have to be bound explicitly with an __.
Damian
gt;
> Why only the right operand? What's wrong with @a[..1]?
>
> Of course then
> @negodds = grep { $_%2 } (..-1);
> needs to start at the top and work down, but that seems OK...
Possible. I'll add it in as a speculation and let Larry veto it :-)
Damian
*isn't* obvious without
understanding. One might just as readily assume that comparison against
an array disjunctively distributes the comparison across the elements.
Of course, that way lies superpositions!
Sigh. We clearly differ irreconcilably on this issue. I suggest that you
counter-propose your version of case and we move on. Larry may well not like
either! ;-)
Damian
or (like "in") so that you can
> write:
>
> if ($x in [ 1, 2, 3 ]) ...
if ( grep $x==$_, (1,2,3) ) ...
Be nice if it would short-circuit in a boolean context though!
Damian
me}; # hashref context
Damian
> >Another one for my wish list: deep copying support built in. A devil
> >inside me thinks this should be a new assignment
> >operator. Damian? Sounds like this is up your alley. I want to do a
> >sanity check before taking up RFC space.
>
>
t is typed (my Date $object), then want() will be able to detect the
difference.
Damian
e new thing, or something of the sort.
Thinking about it, it should get a reference to the original and return a
reference to the new value.
Damian
> I *really* like this idea. There should also be a default CLONE for
> the majority of classes that just want ordinary deep copying on
> whatever object representation they're using.
UNIVERSAL::CLONE.
Damian
-)
Rather than continue to argue the details, why don't people post some
examples of code where they feel these lazy lists might be useful, and
let's see if there aren't already good alternatives.
Damian
eant to write it that way, but my brain has a mind of its own sometimes!)
A __ only "poisons" an expression/sub call if it is a direct operand/argument.
So:
atan($pi/__)
is:
atan( sub{$pi/$_[0]} );
whereas:
atan2($pi,__)
is:
sub{ atan2($pi,$_[0]) };
I'll make it clearer in version 2 of the RFC.
Damian
> The solution is simple: return hashes instead of lists.
I still think returning lists *or* hashrefs according to context gives
the same benefits *plus* backwards compatibility.
Damian
kage MyClass;
sub STRING {...}
sub NUMBER {...}
sub BOOLEAN {...}
H. Maybe even:
sub op+ {...}
sub op* {...}
sub op<=> {...}
#etc.
Shades of C++! ;-)
Damian
PS: This would tie in very nicely with my forthcoming multimethods proposal.
ent sounds fine to me. (It actually fits in
> very well with functional programming which avoids assignment.)
>
> If that rule is modified by an explicit subroutine prototype that
> establishes a curry context then I think we can make this stuff
> work.
Okay. I'll try that in the next version of the RFC.
Damian
Okay. I'll rework the proposal with the consensus syntax.
Damian
I concur with Mike. If we *have* to have a prefix (and I *still* prefer
a naked __, gumble, grumble, pout), then I'd certainly rather ^ that &.
What we *really* need are some more types of brackets:
$range = Ç__È < ÇvalÈ && ÇvalÈ < Ç__È;
;-)
Damian
ean.
> :) I promised Kirrily that I'd race you in the RFC count...
That's hardly fair on you: I can just pull any crazy idea out of my head
whereas *you* have to be able to implement yours! :-)
Damian
> What I'm planning to RFC is a simple format() built-in (probably
> in a pragma) very similar to the form() subroutine described in:
http://www.csse.monash.edu.au/~damian/TPC/2000/Autoformat/paper.html
Damian
> It definitely is, since formats do things that can't be done in modules.
Such as???
> If they yank formats out (which is just dandy by me) that means
> that some means of providing format's functionality needs has to
> be designed in.
I'm working on it.
Damian
...and as for matching regexen against streams, I have a more general
proposal for matching against subroutines that should allow for that
as a special case.
Damian
> Can anyone come up with a good example when you'd want to use both these
> parameters at the same time?
Second "foo" after the last "bar":
index $text, "foo", index($text,"bar",0,-1), 2);
Damian
nt to say:
> $num1 == $num2 works
> $string1 == $string2 works
> $string1 eq $string2 works
> $num1 == works
> $num1 eq breaks?
No, this last one still works.
Damian
uality to DWIM. I.e. are these the same (for some
reasonable value of "same").
And "dog"=="cat" is not a reasonable value of "same".
Damian
; >thrown in. That needs to be taken into account when putting
> >together the RFC for it, if someone even does.
>
> I don't want it to go undocumented; I can write an RFC since I
> started the thread, or Damian can write it since he brought up
> clone
osing something similar in my
general revamp of Perl OO (RFCs galore, probably next week).
Damian
index's
third arg which specifies the *first* character from which to search)
Damian
> Anyway, There is at least one case where you need this true value: if
> the file accidently is empty (or equivalent). I've had that happen.
>
> A true value indicates that the file is indeed valid Perl.
So is an empty file! :-)
Damian
> On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote:
>
> > > A true value indicates that the file is indeed valid Perl.
> >
> >So is an empty file! :-)
>
> That is precisely the problem. You won't get a syntax erro
{foo} and @{foo} and %{foo}
>
> In fact, this seems built-in if we follow the same var conventions. We
> can make ^ bind to {} as tightly as we need.
That would be the right solution. And of course one could use the {} anywhere
necessary or desirable:
my $sin_deg = sin(180*^{_}/$pi);
Damian
> And there's no argument about having anonymous, positional, and named
> placeholders in the redraft...?
There's *always* arguments! ;-)
Personally, if we have positional placeholders I don't see the need
for named ones too. But I'm willing to be convinced.
Damian
> If there's a warning if a require'd or use'd file is empty, that's more
> than good enough for me.
Already added to V2 of the RFC.
Damian
magic is retained for m?...?, I
would suggest that raw ?...? could beneficially disappear.
Damian
> It strikes me that this is very fragile and limited (unless I
> misunderstand, which is quite possible).
We've thrashed out a much more comprehensive proposal, which I'll
post this morning.
Damian
> Damian Conway <[EMAIL PROTECTED]> writes:
> >Operator overloading is scheduled to be revamped.
>
> While I remember - it would be good if overload mechansim
> could be extended to cover && and || as well as & and |
> with the class
ever becomes undef:
$sum = { defined $_[0] or last; $_[0]+$_[1] } 0, @numbers;
> Also you haven't specified if the arguments to reduce are evaluated
> lazily.
Good point. They should definitely be Virtuous. :-)
Damian
Please.
What if I want to overload && and || so that they help built an expression
tree, rather than immediately evaluating?
Damian
> I have often wondered whether a language could allow user-defined
> operators. The fact that none have done it should be a clue :-) I guess
> it's getting too incestuous with the lexer.
User-defined operators are a can of rattle-snakes that I *seriously*
recommend we don't open.
Damian
me I'm finished
everything will be done...in constant time!
Damian
day = "today is " . date(); # reasonable to expect date string
my $tomorrow = date()->{DoY} + 1; # reasonable to expect hash ref
Damian
incr})
- ($USA{gdp}*$USA{gdp_incr})/($USA{pop}*$USA{pop_incr})
);
Surely not?
Operator overloading can certainly be abused (hey, I'm building a career
on that! ;-), but it can also significantly *improve* the maintainability
of code, when used correctly.
In other words: it's just like *every* other feature of Perl.
Damian
_[1] }
>
> Pretty ugly.
>
> And for the N case, it gets even uglier. So reduce should be able
> to supply the next N-1 defined() values.
$def_sum = reduce { $_[0]+$_[1] } grep {defined} @numbers;
Damian
> I'm looking forward to the upcoming writeup :-).
I'm thinking of recanting the whole RFC! :-)
Damian
> Seems to me that while putting hooks in the core to allow this sort
> of thing might be worthwhile, infinite lists are not likely to be
> commonly used and so probably should go into a module.
Agreed. I hereby bequeath the rewrite to someone else.
Damian
sub enervate (?$) : lvalue { $_[0] }
And then:
non_lazy( a(), enervate(b()), c() );
Damian
data in a database for use
> later (persistent objects)
See also: the Class::Classless module.
Damian
Why is that more blech?
Because it's "heavy".
However, if Dan assures me that objects will have lower overheads
in Perl 6, I will happily withdraw my "blech".
:-)
Damian
> We may be able to fake it with source filters and parser abuse, though.
I'm intending to write RFCs on revamping source filters, and also on
run-time access to the parse tree. Just as soon as I grow those two
extra hands so I can run that second keyboard in parallel.
Damian
> in Perl 5 it used to fail.
But how would it know whether a particular AUTOLOAD can handle the requested
method without calling that AUTOLOAD and seeing what it returns? Oh, I get
it: it *would* call every AUTOLOAD it found until one of them returned
something? If so, the RFC ought to explain this explicitly.
Damian
is a poor perl parser to do?
Ignore the prototype unless $fooA and $fooB are typed lexicals.
I.e. act just like it does now.
Damian
e (plural whatzit).
>
> I think this is too limiting.
>
> Depending upon the context reduce should return undef, an empty list,
> or other empty plural whatzit.
H. I need to see more debate on this before I decide what to propose
in the next version of the RFC.
Damian
> By writing @sum = reduce __+__ 0, @numbers
> you deal elegantly with both cases.
>
> NOTE: I find this trick very elegant. I wish it were my trick,
> instead of Damian's...
Damian wishes it were Damian's, but is sure it's at least a few hundred
years old :-)
Damian
tal, ^x+^y ), [], @a };
More and more I lean towards a scalar-only reduce.
Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
multidimensionals.
Damian
ant will be available
via multimethods, when I get around to writing that RFC.
Damian
1 - 100 of 1296 matches
Mail list logo
