On Wed, 29 Aug 2001 16:26:59 -0500, David L. Nicol wrote:
>Bill J. Programmer publishes a class foo that is guaranteed to correctly
>blarg the frobniz, someone subclasses it and breaks the blarg function,
>that simply will not do!
>
>With a "final" it is no longer possible for the new class to id
On Thu, 30 Aug 2001, Damian Conway wrote:
>> 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 lexicall
> 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
On Thu, Aug 23, 2001 at 08:11:26PM -0400, Robert Spier wrote:
> How about something a little more explicit than XXX, like TODO or FIXME?
Some syntax-highlighting editors highlight "XXX". Let's use that feature.
And how can you get more explicit than XXX, anyway?
> > In function definitions, the
> For example, here is an event handler for a GUI:
>
> sub handle (Window $w, Event $e) : multi {
> log("Unknown event $($e->desc) called on window
$($w->name)");
> }
>
> sub handle (Window $w, CloseEvent $e) : multi {
> $w->close;
> }
>
>
On Thu, 30 Aug 2001, Simon Cozens wrote:
> That's not entirely relevant any more. Parrot has a semi-autonomous
> existence as a generic bytecode interpreter. We may be a long way
> from having a language spec, but we're pretty damned close to having
> a spec for the interpreter.
I look forward t
> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
ST> On Thu, 30 Aug 2001, Uri Guttman wrote:
>> we have very strong internal specs already that will support most
>> anything larry throws at us. stuff such as the op code loop, async
>> (file) i/o, events, etc, are all known to be neede
On Thu, Aug 30, 2001 at 01:40:15PM -0400, Sam Tregar wrote:
> What I've seen so far resembles a software CPU, which be analogy should be
> able to do anything from run Quake III to compile Java. Does that mean
> it's well-suited to compiling Perl?
The interpreter is highly unsuited to *compiling
On Thu, 30 Aug 2001, Simon Cozens wrote:
> I could spend a lot of time justifying it to you here and now, or I
> could spend the same time writing a detailed specification of the
> interpreter interface. I think, to be honest, it might be more
> productive for me to take the second option.
I agr
On Wed, 29 Aug 2001, Simon Cozens wrote:
> It's almost time to start coding, people, almost.
Not to be an ass, but is it? It seems like we're still a long way from
having a language spec.
-sam
On Thu, Aug 30, 2001 at 01:25:37PM -0400, Sam Tregar wrote:
> On Wed, 29 Aug 2001, Simon Cozens wrote:
> > It's almost time to start coding, people, almost.
> Not to be an ass, but is it?
Yes.
> It seems like we're still a long way from having a language spec.
That's not entirely relevant any
> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
ST> On Wed, 29 Aug 2001, Simon Cozens wrote:
>> It's almost time to start coding, people, almost.
ST> Not to be an ass, but is it? It seems like we're still a long way from
ST> having a language spec.
we have very strong internal spe
On Thu, 30 Aug 2001, Uri Guttman wrote:
> we have very strong internal specs already that will support most
> anything larry throws at us. stuff such as the op code loop, async
> (file) i/o, events, etc, are all known to be needed so we can code them
> now that the design is firming up. we have t
On Sun, 26 Aug 2001, Nathan Torkington wrote:
> We're about to have a tarball of basic interpreter source (no compiler
> yet, only an assembler). Dan's already run into portability problems,
> and once it comes out we're going to need to start working on the
> configuration and build system.
Co
> Because multimethods are inherently an OO technique.
>
You can say so, but I am not buying it very much.
> It doesn't. The multimethod consists of those variants that are currently
> loaded.
>
How do you define the currently loaded? If things are lazy loaded, the stuff
you expect has been
> > It doesn't. The multimethod consists of those variants that are currently
> > loaded.
> >
> How do you define the currently loaded?
Accessible in the program's symbol table and registered with the multimethod
dispatcher.
> >> 2) If there is mismatch on more than one
On Thu, Aug 30, 2001 at 06:34:31PM -0700, Hong Zhang wrote:
> > None of them. That's why Class::Multimethods doesn't use CLOS's awful
> > "left-most argument first" resolution mechanism.
>
> So what is the next step. How do you define the next most-matched methods.
Please look at how Class::Multi
Thinking about what Zhang was saying about multiple-dispatch not being
inherently OO. I think he's sort of right. Multiple-dispatch need
not be confined to method lookups.
foo();
foo($bar);
foo($baz);
foo($bar, $baz);
sub foo () : multi {
...
}
sub foo (Bar
Me wrote:
> I can imagine plausibly useful dispatch rulesets that do not involve
> comparing sums of inheritance distances. (Though this *is* all
> imagining as I haven't used multimethods/clos in about 10 years.)
>
> I would also imagine that others see that summing inheritance
> distances may
Hong Zhang wrote:
> 3) The multi dispatch is generally slow and complicated. Since it does
> not fit well with OO concept, it will just cause more confusion. Typically
> we use different solution for OO language vs procedure language.
In other words, how much do we want our language to set up f
Dan observed:
> I hadn't considered having it as a global thing, just because I can see
> class Foo wanting multimethods, and class Bar being fine with 'normal'
> class hierarchy walking, and class Baz deciding it wants the automatic
> redispatch form of method calling.
>
> We
Hong wrote:
> > Note that the handler that is selected depends on the *combination* of
> > the types of the two arguments. And that the dispatcher understands
> > the argument/parameter inheritance relationships and selects the most
> > specific handler for each combination. For examp
On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote:
> Access to the source code.
Already got that.
use Fcntl qw(:seek);
seek DATA, 0, SEEK_SET;
@code = ;
> We're going to be carrying it around, unless we
> strip it. We might as well put it to good use within err
On Friday 31 August 2001 01:13 am, Michael G Schwern wrote:
> On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote:
> > Access to the source code.
>
> Already got that.
Not if we don't have the source. Or perhaps this will be the way we do it.
Dunno. Perl Bytecode has a section fo
On Friday 31 August 2001 01:13 am, Brent Dax wrote:
> # -Original Message-
> # From: Dave Storrs [mailto:[EMAIL PROTECTED]]
> # I'd also like to be able to access information on the
> # particular perl that
> # is running this program...e.g., does it support 64-bit nums,
> # what is the
>
On Friday 31 August 2001 01:13 am, Brent Dax wrote:
> Cool--I'd suggest a special $*CODE filehandle, to match $*DATA (that
> isn't going away, is it?).
IIRC, $*DATA is going away, in favor of something a little more
Inline::File-ish - i.e., an arbitrary number of arbitrarily named
pseudohandles
# -Original Message-
# From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
# Sent: Thursday, August 30, 2001 10:13 PM
# To: Bryan C. Warnock
# Cc: [EMAIL PROTECTED]
# Subject: Re: Source/Program metadata from within a program
#
#
# On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock
> Thinking about what Zhang was saying about multiple-dispatch not being
> inherently OO. I think he's sort of right. Multiple-dispatch need
> not be confined to method lookups.
True, but that doesn't make it non-OO ;-)
> foo();
> foo($bar);
> foo($baz);
>
On Thu, Aug 30, 2001 at 10:52:27PM -0700, Brent Dax wrote:
> # Already got that.
> #
> # use Fcntl qw(:seek);
> # seek DATA, 0, SEEK_SET;
> # @code = ;
>
> IMHO, that's too hackish--just reading that doesn't make what you're
> doing obvious. An explicit $*CODE filehandle would make m
Many of Perl 5's global variables are becoming properties of various Perl 6
entities - $. and $/ for input filehandles, for instance.
There is still a large subset of global information that describes the
program itself - some of which has been called for removal (or at least
burial within som
On Fri, 31 Aug 2001, Bryan C. Warnock wrote:
> Access to the source code.
Particularly comments and POD.
I'd also like to be able to access information on the particular perl that
is running this program...e.g., does it support 64-bit nums, what is the
endianness of the native numbe
# -Original Message-
# From: Dave Storrs [mailto:[EMAIL PROTECTED]]
# Sent: Thursday, August 30, 2001 9:59 PM
# To: The Perl6 Language List
# Subject: Re: Source/Program metadata from within a program
#
# On Fri, 31 Aug 2001, Bryan C. Warnock wrote:
#
# > Access to the source code.
#
#
32 matches
Mail list logo
