On 7/14/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Certainly. The problem is that there are too many viable alternatives,
> and half of everyone hates half of the alternatives.
>
> You will know I'm no longer a benevolent dictator when I start to enjoy
> watching people squirm every time I chang
On Wed, 13 Jul 2005, Ingo Blechschmidt wrote:
no, if I understood Larry correctly, you can of course write a nice
grammar-modifying module, but other modules you use() still use
Perl 6's standard grammar. E.g.:
Ah, then of course I would have never expected things to be different at
all.
I
Larry Wall <[EMAIL PROTECTED]> writes:
> On Tue, Jul 12, 2005 at 08:48:41PM +0300, Gaal Yahas wrote:
> : I propose to throw away the filesystem coupling, and map from a more
> : general name of the bit of code we are requiring to a more general
> : description of which instance of it we actually g
Aankhen skribis 2005-07-14 12:39 (+0530):
> Well, you've certainly got everyone flustered enough that they'll be
> overjoyed even if you pick the alternative they hated the most... :-)
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to t
On 7/14/05, Juerd <[EMAIL PROTECTED]> wrote:
> It's just a Solomon judgement situation. That can work out well, but I
> really hate when it's forced and used to test patience.
If Juerd is right about this being a solomonian situation, let me just
give up my baby to the other woman by saying:
* "I
If this were a straw poll, I'd say...
1. Meaning of $_
.method should mean $_.method always. Making it into a runtime
error is extremely awkward; a compile-time error with detailed
explanataion is acceptable but suboptimal.
2. Topicalization of $?SELF
Neutral on this -- I can a
On 7/14/05, Sam Vilain <[EMAIL PROTECTED]> wrote:
> Of course it will be entirely possible to layer support for this sort of
> thing atop any DBI interface;
Exactly my point. Please be so kind as to implement your ideas in a
DBI extension. Time and community will prove whether you are right by
us
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: "Manhattan distance is
better".
Damian writes:
> Similarly, since the number of potential variants is the Cartes
On Wed, 13 Jul 2005, Juerd wrote:
> Dave Whipp skribis 2005-07-13 8:44 (-0700):
> > > Within a method or submethod, C<.method> only works when C<$_ =:=
> > > $?SELF>.
> > >C<.method> is perfectly legal on *any* topic anywhere that $?SELF
> > >doesn't exist.
> > Just to be clear, this includes an
On Thu, Jul 14, 2005 at 11:09:40AM +0100, Piers Cawley wrote:
: So long as there's some way of asking the garbage collector for everything in
: the live set so you can grep through them I'm sure you're right. Because
almost
: everything is extensible at runtime a class is going to need some way of
On Thu, Jul 14, 2005 at 09:19:29AM +0800, Autrijus Tang wrote:
: Within perl 5, there is an extremely easy way to write that, namely
: coderef in @INC that provides line-based filtering:
:
: http://search.cpan.org/dist/Acme-use-strict-with-pride/pride.pm
:
: Are we to discontinue use of [EMAI
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote:
> On 7/14/05, Juerd <[EMAIL PROTECTED]> wrote:
> > It's just a Solomon judgement situation. That can work out well, but I
> > really hate when it's forced and used to test patience.
>
> If Juerd is right about this being a solomonian situ
Nathan Gray skribis 2005-07-14 12:55 (-0400):
> Autrijus joked? about $?.method once (instead of ./method), in case we
> need any more bad alternatives for $?SELF.method. But I also trust
> @larry, or %larry, or even $larry, to make a decent choice that will
> serve the community well.
Would this
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of "current class" for submethods
: currently is:
:
: From inside another method or submethod:
:
: - a submethod should only be called from the class which defines it.
This doesn't sound right to me
On Thu, Jul 14, 2005 at 03:27:53PM +1200, Sam Vilain wrote:
: Can I present an alternative way of viewing them, which I don't think
: contradicts with what I've understood of them so far from the
: Apocalypses and Synopses documents.
:
: First a couple of definitions;
:
: A "runtime class" is a
On Thu, Jul 14, 2005 at 12:14:57PM -0600, John Williams wrote:
: Actually I took his question to be:
:
: If I explicitly name my invocant in the method signature, does that give
: the compiler enough assurance that I'm not going to use .method to mean
: $?SELF.method, and it will allow me to safel
Larry,
Thanks for the detailed reply. Just a few more questions and I think I
can get this into the metamodel :)
On Jul 14, 2005, at 3:40 PM, Larry Wall wrote:
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of "current class" for submethods
:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
say
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: > A submethod is simply a method that says "These
: >aren't the droids you're looking for" if you call it via either SMD
: >or MMD dispatch and the first invocant isn't of the exact run-time
: >type of the lexical class. In other wor
Larry,
Thanks much, this all makes sense. :)
Thanks,
Stevan
On Jul 14, 2005, at 4:54 PM, Larry Wall wrote:
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: Now, the metamodel currently does not have MMD, and I think "next
: METHOD" is not as relevant in SMD. So would it make
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
> On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
> : So long as .foo (pretty please) means $_.foo all the time (with sugar on
> : top?).
>
> It means that all the time, but only when unambiguous. If you say
If .method alwa
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
> On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
> : So long as .foo (pretty please) means $_.foo all the time (with sugar on
> : top?).
>
> It means that all the time, but only when unambiguous. If you say
>
> use dot;
Larry Wall skribis 2005-07-14 13:39 (-0700):
> On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
> : So long as .foo (pretty please) means $_.foo all the time (with sugar on
> : top?).
> It means that all the time, but only when unambiguous.
Thus it never means $?SELF.foo without $_ bei
Yuval Kogman skribis 2005-07-15 1:09 (+0300):
> > use dot;
> If we have pragmas for the 99 Perl6's that every wacko wants to
> have, we won't have any readability.
> The syntax needs to be consistent and useful, even at the price of
> some danger.
Agreed.
> I don't want to be using a languag
Haskell has this very nice consistency I'll diverge into perl
terms...
The 'Show' role provides consistent stringification semantics for
any type that does the role. It can even 'derive' the role, getting
a method autogenerated.
The 'Ord' role provides semantics for ordered types. A typical
s
I'd like to document the optimization pipeline thing I brought up in
the hackathon...
The intent is to plan how to balance throughput with responsiveness
for a language that has such a broad range of dynamic to static
typing as Perl 6 will is.
With such behavior the amount of optimization you can
Luke wrote:
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: "Manhattan distance is
better".
That was never my *argument*, merely my statement-of-position. ;
Yuval Kogman wrote:
- optimizers stack on top of each other
- the output of each one is executable
- optimizers work in a coroutine, and are preemptable
- optimizers are small
- optimizers operate with a certain section of code in mind
> ...
Optimizers
There may be some tie-in with STM here too, where a particular
optimization doesn't commit if the optimization gives up in the middle,
or is preempted before it gets done. But maybe it's all done with
cooperative multitasking. (But maybe STM is how they cooperate...)
Just a half-baked thought.
On Thu, Jul 14, 2005 at 06:06:24PM -0700, Dave Whipp wrote:
: Yuval Kogman wrote:
:
: > - optimizers stack on top of each other
: > - the output of each one is executable
: > - optimizers work in a coroutine, and are preemptable
: > - optimizers are small
: > - optimizers opera
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote:
> On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
> > On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
> > : So long as .foo (pretty please) means $_.foo all the time (with sugar on
> > : top?).
> >
> > It means th
On Fri, Jul 15, 2005 at 02:38:22AM +0300, Yuval Kogman wrote:
> As I see it == is the generic comparison, and 'eq' is == with
> coercing parameters (in Haskell it'd be
> eq :: (Show a) => a -> a -> Bool or so... Isn't that lovely?)
There is a new generic comparison operator known as ~~.
The dispa
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote:
> Nathan Gray skribis 2005-07-14 12:55 (-0400):
> > Autrijus joked? about $?.method once (instead of ./method), in case we
> > need any more bad alternatives for $?SELF.method. But I also trust
> > @larry, or %larry, or even $larry, to make a
33 matches
Mail list logo
