Re: run-once code
At 10:16 PM 1/13/2004 -0700, Luke Palmer wrote:
David Storrs writes:
Given this code:
if ( some_expensive_lookup_function() = $MAX_RECORDS ) {
mark_that_we_have_reached_max_records();
return;
}
After I enter that block once, I never want to evaluate the condition
again--I want the code to completely disappear from the bytecode (or,
at least, be jumped around). How would I do that in Perl 6?
Hmm...
my $max_reached;
sub mark_that_we_have_reached_max_records() {
$max_reached = 1;
}
If you use a hint in Perl6 to tell Parrot that $max_reached needs
to be a native type you'll probably get near C-speed conditional tests with
the JIT. (The JIT is many x faster than current Perl5 conditionals, but the
reason we don't rave about it more often is that languages like Perl6
lose a lot of what the JIT provides since we have to create most variables
as PMCs)
I think Perl6 will allow a hint like so:
my int $max_reached;
The important thing is that $max_reached is used simply as a conditional,
and you don't pass it to a routine or otherwise use it in a way to cause it
to be
promoted to a PMC (which is much heavier than a native). Currently the back-end
compiler (imcc) doesn't coerce native types to a PMC, but it will eventually.
If you use a hint, and simply set and test the conditional, the compiler should
be able to allocate the conditional as a pure integer register, test it,
and skip the
PMC promotion.
Then your worry about getting the test removed from the bytecode would
be needless as you'd probably only waste a couple of JITed CPU cycles.
-Melvin
Re: run-once code
At 09:31 AM 1/14/2004 -0800, David Storrs wrote: On Wed, Jan 14, 2004 at 10:59:52AM -0500, Melvin Smith wrote: I think Perl6 will allow a hint like so: my int $max_reached; The important thing is that $max_reached is used simply as a conditional, and you don't pass it to a routine or otherwise use it in a way to cause it to be promoted to a PMC What uses would cause it to be promoted to a PMC? Any use that doesn't allow a native type. Currently: passing it to a non-prototyped routine or storing it into a hash/list might trigger this. It depends on how well the optimizer handles hints. Since the optimizer could decide it only needs to create a temporary PMC for the uses in question, but leave the base variable as a native. If the optimizer is too aggressive it might decide that it is less expensive to just declare it as a PMC, so that is where we have to decide how serious we take hints. :) If the hint we are talking about becomes a directive, then the compiler just does what it is told. Any expression needing a coercion will get a temporary created, but all simple uses of $max_reached (increment, evaluation, conditional tests) will still work with a native int register, and this is probably what you want in this case. On the flip side, for a standard declaration: my $max_reached; (no hint) it should be possible with data-dependency analysis to decide $max_reached should be a native, without the hint. We shall see. -Melvin
Re: Archive tarball?
At 09:25 AM 1/8/2004 -0600, Jonathan Scott Duff wrote: On Thu, Jan 08, 2004 at 07:48:46AM -0700, Luke Palmer wrote: If worse comes to worst, you can always ask me. I manage to keep the largest amount of the language in my head with the most time available to answer questions :-) Oh no, now *everybody* will be asking you stuff. :-) Are we taking periodic backups of Luke? =) -Melvin
Re: This week's summary
At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Knowing Piers, I would guess: optimistic. :) -Melvin
Re: This week's summary
At 09:30 PM 1/5/2004 +, Piers Cawley wrote: Melvin Smith [EMAIL PROTECTED] writes: At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: people's salaries will depend on Parrot. I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? Knowing Piers, I would guess: optimistic. :) Have we met? You're right though. Unless you count our chats on IRC, no. I can deduce that much from IRC and summaries. We do read them, you know. :) -Melvin
RE: This week's summary
Poor guy, I just told him the same thing off-list. Well I come to think of it, I guess that makes me an old fogey too. -Melvin Dan Sugalski [EMAIL PROTECTED] 09/15/2003 11:39 AM To: Brent Dax [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:RE: This week's summary On Mon, 15 Sep 2003, Brent Dax wrote: Piers Cawley: # Welcome to this week's Perl 6 Summary. And what better way could there # be of spending the morning of your 36th birthday than by reading # through a bunch of old messages in a couple of mailing lists and # boiling them down into a summary? Happy birthday, Piers. Enjoy *that*. ;^) Just don't tell him that he's twice your age. (Which, come to think of it, I am as well... :) Pondering an Old Fogey Moment, Dan
Re: The Perl 6 Summary
Piers, Regarding your Perl6 Essentials summary: Or, he can write code for IMCC using Parrot Intermediate Language (known as PIR for reasons that aren't entirely clear even to one who has been watching the mailing list since the Parrot project started) I suppose noone has much read the README in languages/imcc PIR is what I named the IMCC language and you are correct in your quote, but I've frequently seen people wondering where the name came from. It isn't really an overlay, it is a compiler with an optimizer and register allocator which just happens to emit PASM. If you have Steven Muchnicks book (spelling?) you will notice it is common to name intermediate languages as something with IR in it (MIR, LIR, HIR). Hope that answers your trivia. I suppose I could have provided some more explanation (I haven't read the book yet) but as the original author of IMCC PIR, I wasn't even contacted out of courtesy to write the chapter and was informed after the book was finished. :/ This has been a major stumbling block for me in getting back the motivation to help with Parrot again. -Melvin
Re: of Mops, jit and perl6
At 10:23 AM 7/30/2002 +0200, Leopold Toetsch wrote: Dan Sugalski wrote: Just out of curiosity, I presume the (rather abysmal) perl 6 numbers We have already the same Mops as perl5, but additionaly 2.3 seconds overhead. Just running the byte code is as fast as perl5. Without jit, mops.p6 performs at 0.8 Mops. While I don't mind worrying about the compile time numbers, it is probably way, way too early to be placing any value on MOPS numbers. We just barely got a compiler patched together with gum and tape before TPC and the code generated is t-t-t-terrible. Some of it is Sean's frontend and some is my backend. Toss in the fact that the VM still unoptimized in many areas and we basically have a LOT of work cut out for us. So lets archive these numbers, and see how much we can improve on them and not get too depressed. :) [Both the front and back end compilers are apt to be rewritten anyway] -Melvin
Re: of Mops, jit and perl6
At 07:57 PM 7/29/2002 -0700, Sean O'Rourke wrote: On Mon, 29 Jul 2002, Dan Sugalski wrote: Just out of curiosity, I presume the (rather abysmal) perl 6 numbers include time to generate the assembly and assemble it--have you tried running the generated code by itself as a test? (At the moment, the assembler's rather slow) It's mostly the parser that's slow, not the assembler (about a second's worth of startup time to load the grammar and do a bunch of The assembler _is_ still slow. It is faster than it was, but slow nonetheless, and unacceptable for on the fly assembly. Also, IMCC is to blame for some of the poor quality of the generated code. Eventually it will do proper loop invariant optimization among other things. Things can only get better from here. -Melvin
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
At 12:00 PM 7/22/2002 +0100, Nicholas Clark wrote: On Mon, Jul 22, 2002 at 11:21:09AM +0100, Graham Barr wrote: On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: Sean O'Rourke [EMAIL PROTECTED] wrote: languages/perl6/README sort of hides it, but it does say that If you have Perl = 5.005_03, $a += 3 may fail to parse. I guess we can upgrade that to if you have 5.6, you lose. I notice that DBI no longer supports Perl releases 5.6. Seems enough people are happy that 5.005 is obsolete. I am not sure I agree with that. I have been met with a lot of resistance from users todo the same with my modules. Some even still want 5.004, but thats asking too much IMO. In October 2000 I believed that 5.005 maintenance *is* important for the acceptance of perl6, and I still do now: I agree with this, and until there is a formal discussion and announcement I'm still assuming the minimum for Parrot is 5.005 (_03). At some point we will have bootstrapped Parrot and its languages enough that we can start writing _with_ Parrot, so then all you will need to build is the Parrot VM. That'll be fun. :) -Melvin
%MY (was What's MY.line?)
At 01:08 PM 7/11/2002 -0700, Ashley Winters wrote:
On Thursday 11 July 2002 11:47 am, Chip Salzenberg wrote:
According to Dan Sugalski:
At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
3a. If so, how can one distinguish among the e.g. many Cmy $foo
variables declared within the current function?
One pad per block, rather than per sub.
I just remembered why I thought that woundn't work: BEGIN is a block.
my $x = 1;
BEGIN { %MY::{'$y'} = \$x }
print $y;
Even worse, you should be able to modify lexicals even outside your scope.
sub violate_me {
caller(1).MY{'$y'} := caller(1).MY{'$x'};# hypothetical syntax
}
{
my $x = 1;
my $y; # Might be able to BEGIN { violate_me() } instead
violate_me();
print $y;
}
This reminds me why I don't use Perl4 'local' anymore.
And now we have even uglier ways to write poor code. :)
The only real use I can see of %MY is debugging. If people are going
to take handles to pads and modify lexicals in closures, continuations
and routines from the outside, it probably means that the item needs to
be a class.
And side effects like I call you, you modify me invisibly seems
more like taking dangerous drugs than programming.
Yep, I warned you about calling that routine, now look what it did to
your brains.
-Melvin
Re: What's MY.line?
At 04:24 PM 7/10/2002 +0100, [EMAIL PROTECTED] wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
3. Is C%MY intended to reflect the PAD?
Yes.
Hey! How's this for a scary thought:
$continuation.the_pad
I'll get my coat.
Hah, good try!
I think this would be easy for Parrot. A continuation object will
have all of its context encapsulated already, including the lexical pad
stack.
Assuming the existence of this mystical beast, it could work like:
%continuation.the_pad{'$foo'}
-Melvin
Re: Apoc 5 questions/comments
At 10:21 PM 6/9/2002 +1000, Damian Conway wrote: Richard Nuttall wrote: Grammar::Python, Grammar::Ruby, Grammar::PHP ? I should imagine that the first two at least would be very likely, given that we wish both of those languages to run on top of Parrot. Given that by the time Parrot is beefy enough for people to start working on compilers for it (wait... it is already beefy enough!! ;)) I doubt you will see the real implementation of Python or Ruby done with Grammar:: as they will be racing the Perl guys to get there. And, since both of those languages are a heck of a lot simpler to write a compiler for, they will probably beat us there, not that this bothers me, it'll be good for everyone involved. Given that Python and Ruby have different semantics than Perl, there is more involved than just rejigging a grammar. You still have to get that parse tree down to some representation to hand to the backend compiler. I suppose that part means we have to expose the semantic rules somewhere for these module writers to access, or they have to emit straight Parrot instructions, which will spell y-u-c-k-y. I'm hoping we end up with an intermediate compiler that all the languages can target; one that is a step up from Parrot which will do optimization, reg allocation and a ton of other nasty stuff that language implementors will be happy to punt on. -Melvin
Parrot IR 0.0.2
Cross-posted to p6l and cardinal. Parrot Intermediate Compiler (or Intermediate Representation) See parrot/languages/imcc Just another round of commits, supporting more directives and instructions. Correctly handling indexed use of strings ala: str[0] = A ch = str[0] Will have this working for the rest of the types soon, and still nudging Dan to allow keyed access with the Ix registers. Also added saveall/restoreall for easy subroutine writing until the compiler is smart enough to detect register usage and take care of it itself. Added the concat operator '.' for strings only, so as not to be confused with '+' $S1 = Foo . $S2 Finally added 'new' and 'end' end will now be implicitly inserted after the call to the first routine (lacking a .start directive), so you should put your main routine first. Fixed a couple of bugs in the register allocator to not graph color identifiers that were never used. Updated sample.imc. Did I mention its easier to write in IR than Parrot? :) -Melvin
Re: Accessor methods ?
At 06:11 PM 5/16/2002 -0400, Aaron Sherman wrote: On Thu, 2002-05-16 at 16:07, Mike Lambert wrote: There're three stages: 1. compile time -- When a module or program is byte-coded 2. load time -- When byte-code is loaded off of disk 3. run time -- When the program begins to execute There are complexities, but you get the idea. Load time, I assume is also when BEGIN executes. In this model, you only ever inline at load time ***OR*** when the compiler is attempting to produce a self-contained byte-code executable I don't think load time inlining is going to be within Parrot's spec. -Melvin
Re: Loop controls
At 11:44 AM 5/1/2002 -0500, Allison Randal wrote: On Wed, May 01, 2002 at 04:22:29PM +1000, Damian Conway wrote: NAME Acme::Don't - The opposite of `do' DESCRIPTION ... Note that the code in the `don't' block must be syntactically valid Perl. This is an important feature: you get the accelerated performance of not actually executing the code, without sacrificing the security of compile-time syntax checking. Um... I know it's scary, but I can actually imagine using this (or something like this) in development. I'll occasionally work on a section of code I'm not ready to integrate yet. It would be nice to be able to syntax check it without uncommenting and re-commenting the whole thing. :) Doesn't if(0) do the job? :) -Melvin
Eliza RFC
Now that Clint has Eliza running on Parrot, I propose that from henceforth, Eliza shall field all newbie questions and take responsibility of the FAQ. Eliza should also field discussions concerning why we don't add new keywords such as elloopo; if you can convince Eliza, then the proposal shall be forwarded to Larry. . Including stackops.pasm Including alpha.pasm Including dumpstack.pasm Including tokenize.pasm Including basicvar.pasm Including basic.pasm Including instructions.pasm Including expr.pasm 4239 lines Ready LOAD eliza.bas Got and processing LOAD eliza.bas LOADING eliza.bas...DONE Ready RUN Got and processing RUN Please wait, initializing...(This will take a minute) I am Eliza, the Computer Psychiatrist Why have you requested this session? i want elloopo WHAT WOULD IT MEAN TO YOU IF YOU GOT ELLOOPO i would crush the rest of you DO YOU FEEL INTENSE PSYCHOLOGICAL STRESS? possibly WHAT DOES THAT SUGGEST TO YOU? that elloopo may be too important to me but i still want it I SEE. thank you please tell larry we need elloopo WE WERE DISCUSSING YOU NOT ME. we were DISCUSSING ELLOOPO! SYMBOL NAME TOO LONG: we were DISCUSSING ELLOOPO|1,1 Apparently this could be construed as convincing Eliza, I'm not sure though, I'll ask next session. -Melvin
Re: Defaulting params
At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
On Thu, 2002-04-11 at 14:34, Larry Wall wrote:
Miko O'Sullivan writes:
: Well, I had been hoping to appeal to the mathematical mindset of the
list,
: but there is a second reason for = in addition to / /=: it's simpler to
: understand. I just think that the potential Perl hackers will
understand =
: right away but will have to spin a lot of cycles to get / /=, and will
: meanwhile be wondering why not just =. I'm hoping to point out that = is
: both logically precise AND more marketable.
Leaving marketability aside for the moment, I don't buy the argument
that it's a feature for the user to be able to pass an undef past the
default. The primary purpose of the default is to guarantee the
semantics of the function, not to make life easier for the caller.
If that also happens, it's a nice side effect.
Hmmm... I have to disagree with you there.
Consider this bit of Perl5 which I've done in various forms:
sub nukeuser {
my $user = shift;
my $pwf = shift;
$pwf = '/etc/passwd' unless defined $pwf;
my $backup = _ ? shift _ : $pwf.bak;
my $do_backup = defined($backup);
...
}
Notice that we have two different types of defaulting here. The second
argument is the file to work on, and we set it to a reasonable default
if it is undefined for whatever reason. However, the third argument is
sensitive to undef vs no parameter. In the case of not getting a third
arguement, a reasonable default is set. If an argument is given, but it
is undef, no backup will be performed.
So we have undef and reallyundef? :)
We're not just makeing life easier for the caller. What we're doing is
extracting as much information from the arguments as possible (just as
many Perl functions do). With //=, there's simply some data thrown away.
In Perl6, this might be:
sub nukeuser ($user, $pwf //= 'passwd', $backup = $pwf.bak) {
my $do_backup = defined $backup;
...
}
[I don't know if you can use a parameter to default another parameter.
It would be nice, but I can see why you wouldn't.]
Without an = operator here, you would need to add another argument to
flag doing backups or not (not really the Perl Tao) or you would have to
do the argument processing manually, which sort of defeats the whole
point.
I would typically handle this with overloading the function instead.
Its definitely easier for the reader to understand that way, in my opinion.
Else your function prototypes become a language of their own.
I wish we would stick to simple semantics, allow overloading, allow
a single operator for a default argument, and follow the C++ style of
ambiguity resolution.
-Melvin
Re: I'll show you mine...
At 09:23 AM 4/10/2002 +0100, Piers Cawley wrote:
Okay, this is the beginnings of Scheme in Perl6. I'm sure there's
stuff I'm getting wrong. I've not written the parser yet for instance
Very nice! Quite a sample, maybe Larry/Damian can use this
in one of the next $(A,E)'s
my SchemeExpr $.value;
I haven't been keeping up in the back, I've a wedding bearing down on me.
What is the significance of the . in the declaration? I think I paid attention
enough to know a little about the unary dot but I'm still confused.
We are able to use .foo to mean self.foo, but I would assume foo would be
declared with my Foo $foo, not my Foo $.foo ?
method car { .value.key }
method cdr { .value.value }
Maybe its the C++ in me but why the use of the unary . inside methods
of the current class who's scope includes Cvalue already?
Isn't this like using Cthis in C++ from inside a non-static method?
I'll await your ruler on my knuckles, but overall; very impressed here.
-Melvin
Re: Unary dot
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Also there are issues when just assuming if m1() is a class method,
I call m2() as a class method because m2() may access instance
data that wouldn't exist if it were called staticly.
-Melvin
Re: Unary dot
At 07:40 PM 4/10/2002 +0100, Piers Cawley wrote:
Melvin Smith [EMAIL PROTECTED] writes:
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Um... don't you use factory methods? I know I do.
Sure I do, but it doesn't comprise more than 5% of the methods I call
on objects. And in C++ or Java, when I need a class method, I
specify it with the keyword 'static'. Along with it comes the restrictions
of not accessing instance data, etc. etc.
I will admit my applied usage of OOP is biased by the C++/Java
lense. :)
While I may be misunderstanding Perl6 syntax, I'm not misunderstanding
OOP, these are basic concepts to C++ and Java and how many
other languages; granted, I'll try to play catchup with reading the Apocs and
Exegeses over, but it appears from the discussion thread that people
are discussing class/instance method mixing as if this were a new
concept to OOP. My feeling is you ask yourself: What makes sense and what
does the compiler and runtime engine have to do based on the given
rules that we choose.
Its clear if invocant of foo() is the class, and not the instance, calling
an instance method from class scope without creating an object to work
with should either be disallowed, or analyzed to check whether it actually uses
instance data. I'd choose former which is what C++ and Java does.
-Melvin
Re: Unary dot
At 07:54 PM 4/10/2002 +0100, Piers Cawley wrote:
Graham Barr [EMAIL PROTECTED] writes:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
And anyone who says You don't will receive a good hard talking to
from me. Being able to declare private subroutines within classes is
really useful, witness:
class SchemeNumber is SchemeExpr {
my sub apply($self: $target, $rhs, block) {
if $is_rhs { $self.new(+ block( $target, $self.value )) }
else { $self.new(+ block( $self.value, $target )) }
}
method operator:+ { apply(*@_, {$^a + $^b}) }
method operator:* { apply(*@_, {$^a * $^b}) }
method operator:- { apply(*@_, {$^a * $^b}) }
method operator:/ { apply(*@_, {$^a * $^b}) }
method is_number { 1 }
}
Yes, I know there's several different ways I could do it, but this
approach feels right.
I agree, however you passed in the invocant so there is no
ambiguity in your case.
Calling a class method off of an object, I've found use for.
Calling an instance method from a class invocant scope doesn't
make sense to me which is what I _think_ Graham's example
was implying.
I suppose this would be akin to:
if(typeof(self) is 'class') {
...
}
else { # instance
...
}
I think that would be just plain bad design, but I'd be happy if someone
showed me a use for it. :)
-Melvin
Re: Unary dot
At 08:04 AM 4/11/2002 +1000, Damian Conway wrote: And welcome back to where we started! ;-) Wow there is a lot of blood on the ground here. Must have been messy... :) Of course, the problem is then: what should the name of this topicalizer variable be? The main options are: $self $me $I $this $invocant $object $obj And frankly, that's a very minor issue. Someone (i.e. Larry) should just pick one and then we can all move on. I'm waiting for Larry to say, We have decided to use $me, $myself and $i. -Melvin
Re: Unary dot
At 04:01 PM 4/10/2002 -0600, Luke Palmer wrote: $.foo It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like Cis private as discussed. That or Cis static. I think the latter makes more sense. Or is there some reason this wouldn't work? I totally agree here. The common case is going to make code look ugly with $.foo everywhere. Please don't let this come into being. :( I think it is arguable that a closure is a class for a subroutine object, and in subs we will still use my $foo for lexicals. However we must remember in class scope to use $.foo for the default, instance variable, and a normal $foo for the less typical static or class variables. Yucky. Reserve the ugly syntax for the less common case. Plase. -Melvin
Re: classes, interfaces, properties and 'is'
At 07:12 AM 4/5/2002 +1000, Damian Conway wrote:
Melvin Smith wrote:
More generally, it also depends whether you think of out-of-band properties as
nouns or adjectives. For example:
class Toaster is silver is shiny is hot is little {...}
vs:
After rereading the example, this one bugs me.
This is compile time, and should be an inline property.
I see the potential for another Perl 'non-warning' bug, where
someone typed:
class Appliance {
mucho lines of code...
}
class Toaster is appliance {
}
This trivial example would of course be spottable to all but the blindest
programmer, but what about the more conceivable...
class ToasterException is MyExceptionLibinHungarianNotationBurntBread
{
}
Oops, the exception is really MyExceptionLibInHungarianNotationBurntBread
but Perl6 wouldn't complain, right? It creates a property.
It scares me to be able to _declare_ a new attribute with the same operator
that I typically use to _inherit_ an existing class or property.
Why not make 'is' a little tidier; require us to declare attributes inline, and
let us tag _objects_ (not classes) at runtime with different notation?
-Melvin
classes, interfaces, properties and 'is'
Reading Apoc and Exeg 4 I liked most everything. It has already been said many times how Perl6 is finally getting features the OO guys have been wanting forever, so I won't state the obvious again, but I would like to propose an alternate keyword... 1) In Perl6 we can tag metadata properties to an object using the 'is' keyword. 2) Also, in Perl6 we can derive a new class from an ancestor using 'is'. 3) Thirdly, we can specify that the class is an 'interface'. From my understanding 'interface' is a keyword here. Fair enough. I'd simply like to propose using 'has' for properties for 2 reasons: 1) The above is, to me, fuzzy to use it for all 3 of the cases. 2) 'has' is more intuitive for saying This object _has_ this property. Then, 'is' means something more tangible to me, such as the item IS a Bird, or the item IS the Client interface. I guess its all about linguistics, but thats what we are here for. My personal feeling is the use of the keyword 'interface' is optional just for clarity; I don't really care if we differentiate between a true object and an interface but that gets off subject a bit. If this has already been discussed, I wasn't paying attention. :) -Melvin
Re: classes, interfaces, properties and 'is'
At 07:12 AM 4/5/2002 +1000, Damian Conway wrote: Melvin Smith wrote: 1) In Perl6 we can tag metadata properties to an object using the 'is' keyword. Err, no. We can add properties to a *class* using Cis. To tag objects (which are run-time phenomena) we'd use Cbut. Oops, ok this was my misunderstanding, and answers one of my concerns. 2) Also, in Perl6 we can derive a new class from an ancestor using 'is'. Correct. 3) Thirdly, we can specify that the class is an 'interface'. From my understanding 'interface' is a keyword here. Fair enough. No. Cinterface is a standard property that can be applied to classes. So it's really just an instance of usage (1). I'd simply like to propose using 'has' for properties for 2 reasons: 1) The above is, to me, fuzzy to use it for all 3 of the cases. Only two cases. 2) 'has' is more intuitive for saying This object _has_ this property. Sure, but Cis is never applied to objects. Object properties are specified by creating attributes and methods. The redundancy of class and object properties being specified 2 different ways was what bugged me but this was because of my misreading (read: light browsing ;) ) of the last Apoc/Exeg, I s'pose. Yep. And linguistically (in English at least) we say is both when describing copulative relationships (like inheritance) and when ascribing adjectival properties to classes. So Perl 6 does too. Well, is a in the former, to be specific; but is is close enough. -Melvin
Re: Nested whens?
At 07:50 AM 4/3/2002 -0800, Larry Wall wrote: Piers Cawley writes: : Just a thought, I assume that something like the following will be legal: : Yeah, it's not good style; I should really be doing : : $msg.dispatch_to($self) For some people (OO purists), switch statements are message dispatches anyway; I think your style is fine. -Melvin
Re: Re: RFC: new logical operator
At 09:47 AM 2/21/2002 -0500, [EMAIL PROTECTED] wrote: Randal L. Schwartz [EMAIL PROTECTED] wrote: Sam No, but is syntactically equivalent to and in English. It Sam just implies that the second condition is not generally what Sam you'd expect if the first was true. Randal Maybe in the interest of huffman encoding, we could make Randal it even_though. :) Or we could compromise on despite. But (sigh) when I first looked at this proposal, I thought, Now what the heck is he trying to say that 'and' doesn't cover? Is it really syntactic sugar if it's confusing at first glance? Syntactic maple syrup? -Melvin
Re: Perl6/Parrot status
Steve Fink [EMAIL PROTECTED] To: Ask Bjoern Hansen [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] 02/07/2002 12:01 Subject: Re: Perl6/Parrot status PM anyway. Every time I've talked to him recently, he's complained 'perl just has too f*cking many ways of doing things. How can anyone ever figure out which one to use?' Cough cough. Hack. Cough. Choke. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
RE: Perl6 -- what is in a name?
At 01:52 PM 1/28/2002 -0600, Garrett Goebel wrote: From: Brent Dax [mailto:[EMAIL PROTECTED]] Aaron Sherman: # # I think the first guy that gets hired to maintain Perl6 code, # and think hey, I know Perl, no sweat will disagree with # you. I disagree. He'll see stuff he doesn't understand and try to consult perldoc on it, at which point he'll realize that he's working with Perl 6. Then he'll run out, get Camel IV, read it, and go back to work. Programmer is working with a better version of language, program is fixed, and ORA made fifty bucks. Everybody's happy. :^) Perhaps. Or perhaps he'll be like our company's lead C++ developers. They liked Perl4 well enough for a certain problem domain, saw some Perl5 code... and have tried to stay away from it ever since. Perl6 isn't going to make everyone happy. I have a hard time believing those C++ guys are really Perl lovers; I'ver never spoken to a Perl fan that didn't have dreams of a making the language even better than it already is; better OO in Perl, etc. Maybe they just have a huge unwieldy Perl4 app they don't wish to port. -Melvin
Re: Apoc4: The loop keyword
At 11:40 AM 1/25/2002 -0600, Jonathan Scott Duff wrote: On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote: On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: What we're cleaning up is the ickiness of having things declared outside the braces be lexical to the braces. *That's* hard to explain to beginners. But it's handy. And that was, until now, what mattered with Perl. No, handiness still matters with Perl. It's just that the balance has tipped a wee bit towards the consistency/regularity/simplicity/whatever side of the scale. Besides no one has commented on Steve Fink's (I think it was him) idea to store the result of the most recently executed conditional in $?. I kinda like that idea myself. It makes mnemonic sense. I like the $? idea, and it could probably be optimized away. -Melvin
Re: need help making auction
At 01:39 PM 1/23/2002 -0800, frank crowley wrote: see attached file. = frank crowley What is it that you wanted us to see? -Melvin
Re: need help making auction
At 01:43 PM 1/23/2002 -0800, you wrote: i need help on making it into an auction that will work. Ok I thought so. You might try [EMAIL PROTECTED] for some beginner tips but I doubt you want to submit a whole script, maybe rephrase your stuff into specific problems you are having. Good luck, -Melvin
Re: Some Apocalypse 4 exception handling questions.
At 02:25 PM 1/23/2002 -0800, Glenn Linderman wrote:
Melvin Smith wrote:
I'm not comfortable with this sort of concept. Typically inheritance is
going to either take the base implementation or _replace_ the
implementation.
The replacement can decide to {call|ignore} the base method.
I think you just said the same thing I did. To be more explicit, using
the terminology you seem to want to use, I'll point out that I was only
talking about the case of an inherited method, not a _replacement_
method. In other words, when you inherit a method, you are taking the
base implementation for that method. But if you replace a method, you
are not inheriting that method, but rather replacing it; yes, the
replacement method may choose to call the base implementation's method
as part of the replacement implementation. When you replace a method,
you have 2 subroutines, the base implementation, and the replacement
implementation, but when you inherit a method, you have only 1
subroutine, which may be called 2 different ways.
After re-reading your piece by itself I see we did say the same thing.
The confusion set in when I read 'Me's' post inline with yours.
If you wouldn't want the base implementation to be ignore there is usually
some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
sure.
I'm not sure either. In fact, I'm not sure what you mean by this
sentence at all. If it matters, please rephrase it, so we can talk more
about it.
Referring to final, private, etc. modifiers that you can use in C++/Java
whenever you don't want someone reimplementing or overriding something.
Will there be such a thing in Perl6?
I think this is meant more for Me (not me) than you.
-Melvin
Re: Some Apocalypse 4 exception handling questions.
At 05:01 PM 1/23/2002 -0600, Jonathan Scott Duff wrote: On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote: Final seems to be a way of sealing off a class or method from future inheritance. Generally, the arguments I've seen on OO lists seem to indicate that regardless of how omniscient the original designer is, someone will get an idea for a useful subclass for the class or method, but run into the problem of not being able to extend it because of the superclass implementor's choice to make it final. Hence, final seems to be a concept that is rather un-Perl-ish. Hmm. It would be un-Perl-ish to not provide a mechanism for the fascist to implement final if they wanted it. Which leads me to wonder if a way unfolds from the syntax already revealed or if we have to wait for the OOP-Apocalypse to see how to put our PRE conditions on the isa mechanism. I agree totally. Ive never bought into arguments about why available, non-default behavior is so oppressive. Else use strict would have to go. :) Glenn's point is correct about these mechanisms - when you don't have access to source code, it can be frustrating, but I think its the availability of source + the design decision of the author, not the keyword that is the problem. -Melvin
Night of the Living Lexical (sequel to Apoc4: The loop keyword)
At 12:32 PM 1/21/2002 -0500, Michael G Schwern wrote:
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: while( my $line = FILE ) {
: ...
: }
That still works fine--it's just that $line lives on after the while.
This creeping lexical leakage bothers me. While it might make the
lives on, ... creeping lexical, I feel the same way, we must find some
way to kill these... :)
-Melvin
RE: Night of the Living Lexical (sequel to Apoc4: The loop keywor d)
At 03:02 PM 1/21/2002 -0500, you wrote:
Why all the fuss? Often, you would *want* to access that lexical after the
loop terminates, for instance to check how it terminated.
Why would you want to check it when the condition is typically boolean?
while( my $line = FILE ) {
I think many people just expect it to work the other way. If I recall, C++
originally worked this way (at least some compilers) and went the
other way.
-Melvin
RE: Night of the Living Lexical (sequel to Apoc4: The loop keywor d)
At 03:14 PM 1/21/2002 -0500, Melvin Smith wrote:
At 03:02 PM 1/21/2002 -0500, you wrote:
Why all the fuss? Often, you would *want* to access that lexical after the
loop terminates, for instance to check how it terminated.
Why would you want to check it when the condition is typically boolean?
while( my $line = FILE ) {
Well let me rephrase, I see what you mean. (If a terminating condition
was met inside the loop then you might check it); what I meant was
the typical situation is the while not EOF or while still MUNCHING.
-Melvin
Re: Apoc4: The loop keyword
At 12:50 PM 1/21/2002 -0800, Larry Wall wrote: In most other languages, you wouldn't even have the opportunity to put a declaration into the conditional. You'd have to say something like: I grudgingly agree here. Where did this shorthand come from anyway? The first time I ever used it was C++ for() loops, but I'm sure it has roots older than that. I guess Perl took shorthand to the next level so C++ arguments wouldn't work here, *sniff*! -Melvin
Re: Night of the Living Lexical (sequel to Apoc4: The loop keyword)
At 04:12 PM 1/21/2002 -0500, Uri Guttman wrote: MS lives on, ... creeping lexical, I feel the same way, we must find some MS way to kill these... :) well, larry looks at it differently and what he said on the cruise makes Well we had a go, but our kung fu powers were no match for Larry's. -Melvin
