lement this particular
operation by forcing a sub call through a reference, if the metamodel
is implemented in Perl 6. It's the only way we've defined to
defeat the .foo dispatcher so far, from a language point of view.
(Though simply calling .meta could also be construed as cheating,
I guess. Or at least an authorization of cheating on your behalf.)
Larry
ed thought. It's just when you said "an optimization
completes" I heard "an optimization commits", which implied that an
optimization could also roll back if it needed to.
Larry
all else fails,
some kind of log file maybe. On the other hand, if you aren't ready
to deal with warnings on stderr, maybe you shouldn't be running an
OS that supports it...
Larry
ne from the named zone, it wouldn't help here, since the call syntax
is implicitly buried in the implementation of "for". So we have to
distinguish it on the formal end, and currently Pair is the way to do that.
Larry
t ordering, and also to make
: :ascendant the :canonical ordering (since it makes MI sane, I mean how
: could you go wrong).
:
: Of course all this can change if @Larry decides differently :)
It has been a long-standing desire of $Larry to head that direction,
so unless any(@Larry) complain, that
e are mixing OO
interface with OO implementation, and we've already discovered in
Perl 5 that that's a Bad Idea. Interfaces between organisms are
cleaner when their innards stay in and their outtards stay out.
Larry
On Tue, Jul 19, 2005 at 02:21:44PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
: > > Users of the class includes people subclassing the class, so to them
: > > they need to be able to use $.month_0 and $.month, even though there
: > > is no "has $.month_0" declared
We somehow seem to have the situation where :: is simultaneously
trying to be a leading sigil, a trailing sigil, and a separator.
Larry
gation. Am I right?
Yes, presuming the delegator doesn't want to capture control again after
the delegation. But delegation is just syntactic sugar anyway, so
if you want control back you should just write it that way explicitly
and the tailcall disappears.
Larry
aults.
It's likely that the leftmost-wins rule applies only to binding,
not assignment.
Larry
atch.
* Don't need to topicalize self any more.
* .foo can (again) always be the topic without warnings.
Have at it...
Larry
On Thu, Jul 21, 2005 at 02:29:33PM -0600, Paul Seamons wrote:
: On Thursday 21 July 2005 12:48 pm, Larry Wall wrote:
: > * Don't need to topicalize self any more.
: >
: > * .foo can (again) always be the topic without warnings.
:
: Thank you.
:
: Do the following exist the
On Thu, Jul 21, 2005 at 05:15:34PM -0400, Stevan Little wrote:
: Larry,
:
: This means that Roles are now first-class-ish things. Meaning they
: cannot just simply be composed into classes since now we have to keep a
: table of elements which are private to a Role.
Well, we've kinda
On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
: On 7/21/05, Larry Wall <[EMAIL PROTECTED]> wrote:
: > Have at it...
:
: The only thing I immediately don't like is the use of the normal identifier
: character "_" to indicate the "specialness&
On Thu, Jul 21, 2005 at 10:17:13PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Larry Wall wrote:
: >has $x; # private rw, no accessors, not virtual, name lexically
: >scoped
: >
: >has $_x; # private rw, rw _x accessor, not virtual, name class scoped
:
: Ev
On Thu, Jul 21, 2005 at 11:58:41AM -0300, Adriano Ferreira wrote:
: Larry said:
: > So I guess I agree that .tailcall is probably just a bad synonym for
"return".
:
: But is there any other case where we need an explicit tail call with "goto"?
I suppose that depends o
f caller probably want to skip the middleman anyway, and even more uses
of "want".
It's the debugger that wishes the tail-call optimization didn't exist...
Larry
nguish
$?SELF.foo()
$?SELF._foo()
on the call end. And the _ has the advantage of being *perceived* as
part of the name. The problem with
$?SELF.:foo()
is that people see that as a .: operator on the foo method.
Larry
On Fri, Jul 22, 2005 at 12:53:45AM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall <[EMAIL PROTECTED]> wrote:
: > $x is visible only in the rest of the lexical scope. In contrast,
: > $_y would presumably still be visible if the class were reopened.
:
: This strikes me
let people say Any explicitly if they really want to suppress autothreading.
Otherwise conditionals and switches are going to behave oddly in the
presence of "accidental" junctions.
Alternately we could try to distinguish explicit pairs from generated
pairs, and require explicit pairs (or * marked generated pairs) to
transition to the named zone.
Larry
but we're still trying to understand what that means.
As you say, whatever we end up with does have to be extensible,
since we don't know all the "places" we'll want ten years from now.
It seems to me that the more places we can come up with now, though,
the less likely we are to have collisions later, unless our categories
are artificial. That tends to argue for separating out VM from OS,
and maybe COMPUTER, and NET, unless you think that NET =:= COMPUTER.
Larry
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:
: On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
: > I dunno. I'm inclined to say that it should default to Item|Pair, and
: > let people say Any explicitly if they really want to suppress autothreading.
:
interface. But this is one of the standard OO paradoxes, and we're
hoping roles are the way out of it. (Or to be less precise and more
accurate, we're hoping it's the way to sweep the problem under N
carpets where N is greater than 0 most of the time.)
Larry
ijus is asking. We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to -> $x {...}. Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions. (And if that's the wrong way to think about it,
please tell us why.)
Larry
for Least Surprise, since No Surprise
is not really attainable here.
Larry
le will in fact confuse them...
Larry
ll not entirely sure I believe the "not-yet-bound-ness" of
Pairs is all that different from the not-yet-bound-ness of Junctions
to the extent that a different type level is warranted. I guess I
still think there ought to be a way of marking Pairs on the call end
as to whether they're intended for named args or not, without warping
the whole top-level type system to that end.
Larry
would
go back to one-level deref, not all levels.
Larry
e an error?
:
: (FWIW, I favour option 2.)
Why shouldn't it do option 3, which is to work like in Perl 5?
It should only be an error if $arrayref is declared with a type
inconsistent with 42. Assignment goes to the container, not the
current contents of that container.
Larry
Except that you've rebound the container. Hmm, maybe the original
binding is an error.
Larry
me this year: "Be strict now--we can always relax it later."
Of course, I shall probably violate that myself when I get around to
answering Autrijus on return type checking...
Larry
the
: > code can use a defined guard.)
:
: I don't know if returning the printed string is the right approach, but
: would returning '$string but true' avoid the semipredicate problem?
I don't see any reason to return the string at all. It's almost never
wanted, and you can always use .= or monkey but.
Larry
On Sat, Jul 30, 2005 at 05:17:29PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: Larry Wall wrote:
: > Except that you've rebound the container. Hmm, maybe the original
: > binding is an error.
:
: what about:
:
: sub foo (Array $arrayref) {...}
:
: my @array = ;
:
you can omit the parens:
(zip @odd; @even)
just as in subscripts the semicolon separates multiple dimensions:
@[EMAIL PROTECTED]; @b]
Larry
ef" should be exactly equivalent to
: > "$undef.chars". In fact, I think it is: "chars $undef" is just the
: > indirect object form.
:
: Didn't $Larry rule that method calls on undef return undef, for the
: same reason array and hash subscripting does?
Um, by def
ric subscripts. Certainly Lisp's extensible car/cdr notation
is the wrong way to do it, but cdddr is certainly shorter than
$pair.value.value.value
But maybe that's worth being dehuffmanized like that...
Larry
to assume that the Apocalypses are primarily
intended to be entertaining rather than factual. :-)
Larry
: > that aren't declared in 'Class'?
:
: class(Foo) instance methods will be for 'Foo', and the class methods
: will be for ::Class.
:
: The current metamodel hacks this in a kind of ugly way, but that is how
: I am seeing it.
I'm not sure if Class is really a class or just a role containing
the interface to bootstrap a class instance using the meatclass, er,
I mean, the metaclass. The abstract parts of a class that overlie
the package are rather, um, abstract.
Larry
re are still places where we
can use junctions as type constraints, but there are no junctional
base types because they can't always fit into a type lattice. A type
junction just implies autothreading on the constraint checks, but
we won't try to reason with type junctions.
Larry
On Wed, Aug 10, 2005 at 10:47:47AM +0200, Juerd wrote:
: Larry Wall skribis 2005-08-09 16:19 (-0700):
: > So either something in the context tells us what "Foo" means, or
: > it will be taken as a list operator that hasn't been declared yet.
:
: Is there, by the w
And maybe that's the real difference between the
class object and the metaclass object. And maybe we can reason
about objects of type IO without worrying about the definedness,
if all classes already include their own personal undef.
Larry
ideals don't exist
anyway, so that's okay. Which seems like another good reason for
classes to be considered fancy forms of undef...
I guess a class would be kind of like the spotlight that comes up
on one of the stage entrances in anticipation of an actor being
instantiated there. :-)
Larry
On Thu, Aug 11, 2005 at 01:34:34AM +0800, Autrijus Tang wrote:
: On Wed, Aug 10, 2005 at 10:25:05AM -0700, Larry Wall wrote:
: > I'll have to think about the rest of your proposal, but I was suddenly
: > struck with the thought that our "platonic" Class objects are real
On Thu, Aug 11, 2005 at 01:24:11AM +0800, Autrijus Tang wrote:
: On Wed, Aug 10, 2005 at 10:12:45AM -0700, Larry Wall wrote:
: > We can get away with this in Perl 6 because bindings to positionals
: > happen lazily. So all we have to check for syntactically is that we
: > don't hav
s and hash keys though.
But anyway, if we assume sets are values rather than containers,
they don't really need a sigil. (The problem with treating sets as
containers is that you can't do set theory on them. When you add to
a set, it is in fact a *different* set, and should have a different
identity.)
Larry
somewhere.
These days I'm just wondering where we'll stop. :-)
Larry
is implicitly "constant"?
But maybe this would be illegal:
sub foo($a, ?$b = 42) {
$b //= 2; # compile-time error
}
foo(1);
on the theory that the = of the default construct is the same special
case as the = in
my $b is constant = 42;
Larry
de
to support that mode.
Larry
On Wed, Aug 10, 2005 at 11:48:16PM +0200, TSa wrote:
: Only that ?$b is not marked is constant? Strange that is.
Straight out of the apocalypse--parameters default to constant.
Larry
do_something; $skip.do_something; # ...
}
Arguably that's just locating the type near the "my" again, though the
"my" is implicit in the signature in this case.
Larry
nsuccessful) IO or Dog or whatever, so that you don't have to play
games with junctions to get undef into typed variables. In other
words, $spot is not successful, but that can be either because we
tried and failed, or because we haven't tried yet. That's the
unification I'm looking at.
Larry
On Fri, Aug 12, 2005 at 01:43:43AM +0800, Autrijus Tang wrote:
: On Wed, Aug 10, 2005 at 12:41:17PM -0700, Larry Wall wrote:
: > : If yes, what does it desugar to?
: > :
: > : my $pi is constant := 3;
: > : my $pi is constant ::= 3;
: >
: > In this case it desugars to
:
self needn't remember it. On the
other hand, hashes behaving like mutable sets need to remember their
comparison operator if it is not the default.
Larry
On Fri, Aug 12, 2005 at 04:30:09PM +0200, TSa wrote:
: HaloO,
:
: Larry Wall wrote:
: >[..] but since sets are
: >immutable values,
:
: Does that imply they travel in $vars and are a subtype
: of Value?
I believe so.
: Is Undef of Set the Set::Empty?
I don't think so. The empty
On Thu, Aug 11, 2005 at 09:52:18PM -0700, Ashley Winters wrote:
: On 8/11/05, Larry Wall <[EMAIL PROTECTED]> wrote:
: > So either we have to bifurcate the concept into "temporarily constant"
: > and "permanently constant", or we force people to distinguish wi
comes ubiquitous, but
the conservative way forward is to disallow writes in the function body
for now. But you're right that the caller doesn't care which way that's
done.
: Enjoy my silence for the next two weeks.
: I'll be offline at least that long.
Have the appropriate amount of fun. :-)
Larry
it looks susupiciously like a type signature. Maybe it should be written:
my Fight %hash :(Dog,Cat);
or even
my %hash :(Dog,Cat --> Fight);
Larry
On Tue, Aug 16, 2005 at 01:33:56AM +0800, Autrijus Tang wrote:
: On Mon, Aug 15, 2005 at 08:19:38AM -0700, Larry Wall wrote:
: > I think the distinction is still useful to document that there are
: > still unbound types. What we need to emphasize is that a role can be
: > used as a
conds to represent them. I'm personally rooting
for everyone to abandon leap seconds for civil time. Civil leap
adjustments really ought to be scheduled more than six months in
advance. Once a century would be about right.
But POSIX stretchy seconds must die.
Larry
stinction that a class is a
valid dispatcher while a role is not. This is mostly a declarative
distinction to keep it straight in people's heads. But as with many
other things in Perl, if you use an X as a Y, it'll behave like one,
and so we try to make it easy for a role to "autovivify" itself in
a class context.
Larry
On Mon, Aug 15, 2005 at 04:41:03PM -0400, Mark Reed wrote:
: On 2005-08-15 13:56, "Larry Wall" <[EMAIL PROTECTED]> wrote:
: > Perl 6 will natively think of dates as number of floating point TAI
: > seconds from the year 2000. You can build any kind of date interface
: >
On Tue, Aug 16, 2005 at 01:18:58PM +1200, Sam Vilain wrote:
: On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote:
: > : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0
: > : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of
: >
to be
滞謀 stop, stagnate / plot, strategem
滞矛 stop, stagnate / halberd, lance, spear
滞夢 stop, stagnate / dream
滞霧 stop, stagnate / mist, fog
I'm sure we could find something meaningful in there. ^_^
Larry
On Tue, Aug 16, 2005 at 10:24:41AM -0500, Dave Rolsky wrote:
: On Mon, 15 Aug 2005, Larry Wall wrote:
:
: >But the best part is that if we abandon UTC leap seconds for civil time,
: >we don't have to remember leap seconds going forward, only backward from
: >2000.
:
: So you want
for object types like Num, then we might even
end up with Num == NaN, albeit with different exception information
hidden inside. Num is "not yet defined", whereas NaN is "tried to
convert 'hello' to number at inflate line 2" or some such.
Larry
On Tue, Aug 16, 2005 at 10:00:14AM -0700, Larry Wall wrote:
: If we go with class names being the undefined prototypical values,
: and if we assume that NaN is an "unthrown exception" variant of
: the undefined value for object types like Num, then we might even
: end up with Num == N
aters...
Larry
onstant $pi = 3;
or
constant Num pi = 3;
or if you like, even
constant π = 3;
Larry
least for people
who aren't used to seeing methods hanging off of literals.
Larry
contexts other than inside a
: method or a class composition block. At least none that I can think of.
If there are more they will become obvious as we go along. $? variables
that scope lexically are probably just "temp" or "let" variables in
the Perl grammar, so they won't be hard to monkey with if we need to.
Larry
or is different. But even if that were
allowed, you also may not declare two attributes that generate an
accessor of the same name.
Larry
submethods, I see them like this:
:
: submethod foo () { ... }
:
: is really ..
:
: submethod foo () {
: next METHOD unless $?SELF ~~ $?CLASS;
: }
:
: At least that is how larry explained to me about a month ago.
Can't use ~~ for that, since ~~ implies "does", which is not
On Thu, Aug 18, 2005 at 02:40:12AM +0800, Autrijus Tang wrote:
: On Wed, Aug 17, 2005 at 11:37:26AM -0700, Larry Wall wrote:
: > On Tue, Aug 16, 2005 at 05:25:40PM -0400, Roger Hale wrote:
: > : 1.e5# all of these...
: > : 1._e5 #
: > : 1._0e5 #
: >
On Thu, Aug 18, 2005 at 12:02:53AM +0800, Autrijus Tang wrote:
: On Wed, Aug 17, 2005 at 08:47:18AM -0700, Larry Wall wrote:
: > : >That could be made to work by defining constant to mean you can assign
: > : >to it if it's undefined. But then it gets a little harder to reason
:
r it's
already figured out how to thread. A lot of optimizations might want
that bare entry point as well.
This does imply that the "next METHOD" of a submethod is outside that
bare entry point, of course. That's what your flag is emulating.
Larry
On Wed, Aug 17, 2005 at 09:37:08PM +, Luke Palmer wrote:
: On 8/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
: > You could still reason about it if you can determine what the initial
: > value is going to be. But certainly that's not a guarantee, which
: > is one of t
tal.
: and
: 2. a NaN at runtime if you ignore the warning.
In this case it shouldn't get even that far since you'll get a fatal
error that says you tried to pass a positional list to a non-positional
parameter. + isn't a synonym for ?.
Larry
of life is that, to get anywhere you're not, you have to move...
Larry
ction we make for defaults in signatures: if you pass
undef as an argument, it doesn't trigger default setting.)
In other words, you could desugar
sub foo ($a = 1) {...}
to
sub foo ($a) {
$a = 1 unless exists $a;
...
}
Larry
On Fri, Aug 19, 2005 at 01:15:23AM +0800, Autrijus Tang wrote:
: On Thu, Aug 18, 2005 at 10:09:16AM -0700, Larry Wall wrote:
: > In other words, you could desugar
: >
: > sub foo ($a = 1) {...}
: >
: > to
: >
: > sub foo ($a) {
: >
lowed to monkey with the
symbol table is when you're compiling, so deletions could just fall into
that category. The compiler has to be able to depend on its symbols
not going away once it's done.
Larry
On Fri, Aug 19, 2005 at 01:36:30AM +0800, Autrijus Tang wrote:
: On Thu, Aug 18, 2005 at 10:26:00AM -0700, Larry Wall wrote:
: > Sure. Though it probably also wants to stay as metadata associated
: > with the signature, since part of the reason for putting it in
: > the signature in
d get the colon next to the
name and have better visual correspondence with the :foo(), syntax,
and maybe even allow adverbs to include an optional sigil on the front.
On the other hand, then people would want to write $:foo in the body,
and that won't do. So nevermind. Stick with :$foo for that.
Larry
ribute)
syntax though, unless we say that any twigil forces named argument passing,
or otherwise just force it to work. Though with BUILD we've basically
said already that all arguments must be passed +$: (required name) form.
Maybe it can be made to work.
Larry
ECTED]); # Just Works
Presumably we need that funny list type anyway to collect named vs
positionals vs slurpies at compile time, so all we need to do is
expose that type via arglist() or whatever we call it. Maybe it's just
my @args := ArgList.new(1, 2, 3, :foo('bar') <== @slurpme);
Doesn't have to be Huffshort.
Larry
On Fri, Aug 19, 2005 at 08:39:24AM -0700, Larry Wall wrote:
: Actually, that's an argument that : is in a different class than the regex
: quantifiers, and required named should be
:
: sub bar (+$:key)
:
: as I speculated earlier. Maybe we just force that to bind to $key instead
: of
< ()]
which gives
[[5,6], 8, [3]]
I'd expect, maybe with a warning on 3 + undef, unless we default to
the identity value trait for + instead of undef.
Larry
On Sat, Aug 20, 2005 at 12:27:23PM +0300, Yuval Kogman wrote:
: On Fri, Aug 19, 2005 at 21:29:11 -0700, Larry Wall wrote:
:
: > Basically, unaries don't have to worry about reconciling different shapes.
: > They just recurse as much as is "reasonable", whatever that is
l OUTER down to one MY and
just use OUTER.findsym('$x') if that's what we mean. But then we
get bad interactions if someone says
FOO.findsym('$x')
on a class that defines its own findsym method. Or maybe that's
a feature. Or maybe only pseudo classes that resolve to MY variants
have a findsym method. ENOCAFFEINE.
Larry
I do.
I think the simplest thing is to say that you can't bind to the name
of the slurpy hash. You give a name to it so that you can refer to it
inside, but that name is not visible to binding. (We could probably
say the same thing for other slurpy types, I suspect--especially if
it would simplify the binding code.)
Larry
On Fri, Aug 19, 2005 at 06:42:04PM +0300, Yuval Kogman wrote:
: On Fri, Aug 19, 2005 at 08:27:38 -0700, Larry Wall wrote:
:
: > Plus I still think it's a really bad idea to allow intermixing of
: > positionals and named. We could allow named at the beginning or end
: > bu
terface. Also, we'd
have to look at how these things degrade in partially specified stubs:
sub mystery { :x($), +:y(Dog @ where Beagle) }
It looks like it could get messy. Er, messier.
Larry
oing to mandate it in the base language unless we see
some really good uses for it. In general we should encourage outer
classes to share with inner classes via lexical scoping rather than
package scoping, I expect.
Larry
s by putting curlies around them:
my( $s, $t ); $s = { "value t is $t" }; $t = "xyz"; print $s();
Currently we also require the de-lazifying context to supply a
postfix .() marker, but possibly that could be assumed in a string
or numeric context.
I really don't see much benefit in making it easier than that.
Larry
e
them from the environment when we "use" them, since child processes
may want the same value. If we weed out values from the slurpy
hash, we force environmental hashes to be passed some other way.
Whether that's a feature or not depends on whether you view such an
"environment" as default values for named parameter bindings.
Larry
ally casting between strings and numbers.
Larry
On Tue, Aug 23, 2005 at 11:03:52AM +0300, Yuval Kogman wrote:
: On Mon, Aug 22, 2005 at 13:25:57 -0700, Larry Wall wrote:
: > On Tue, Aug 23, 2005 at 04:09:29AM +0800, Yiyi Hu wrote:
: > : my( $s, $t ); $s = "value t is $t"; $t = "xyz"; print $s;
: > : in perl 5, it w
On Wed, Aug 24, 2005 at 12:43:46AM +0300, Yuval Kogman wrote:
: On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
: > On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
: > : "10" == "10"; # dispatches to Str, due to better match
: >
: > Nope,
assignment will work the same in Perl 6 as it was in Perl 5,
so it's not the solution for you problem.
Larry
On Fri, Sep 02, 2005 at 05:56:39PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: multi foo ($a) {...}
: multi foo ($a, $b) {...}
:
: say &foo.arity;
: # die? warn and return 0? warn and return undef? return 1|2?
How 'bout undef but 1..2? :-)
Larry
801 - 900 of 3168 matches
Mail list logo
