Multmethods by arg-value
I was reading the Partially Memorized Functions thread, and the thought
came to mind that what we really need, is to define a different
implementation of the method for a specific value of the arg. Something
like:
sub days_in_month( Str $month, Int $year )
{
...
}
sub days_in_month( Str $month is value{ rx:i/feb[ruary]?/ }, Int $year ) is
cached
{
...
}
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: Usage of \[oxdb]
I think that solves all the problems we're having. We change \c to have more flexible meanings, with \0o, \0x, \0d, \0b, \o, \x as shortcuts. Boom, we're done. Thanks! How far can we go with this \c thing? How about: print \c[72, 101, 108, 108, 111]; will that print Hello? Dave.
RE: purge: opposite of grep
Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote:
SUMMARY
Proposal for the purge command as the opposite of grep in
the same way that unless is the opposite of if.
I like it.
But reading it reminded me of another common thing I do
with grep: partitioning a list into equivalence classes.
a simple case:
@pass = grep {$_-ok} @candidates;
@fail = grep {! $_-ok} @candidates;
This could perhaps be expessed as:
(@pass, @fail) = unzip { $_-ok } @candidates;
A more general mechanism might be:
%results = partition
{ $_-pass ? pass : $_-fail ? fail : unknown }
@canditates;
print pass: @{%results{pass}};
print fail: @{%results{fail}};
print unknown: @{%results{unknown}};
Dave.
Primitive Vs Object types
Every primitive type has an associated object type, whose name differs only by capitalized first letter. A few posts back, Larry mentioned that perhaps similar things should look different: this may be a good case to apply this principle. Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. I worry that this could cause very obscure bugs: made worse by the invisibility of the difference between primitive and object types. I would propose that, at the very least, users should be required to Cuse primitives qw(int) before using such things. Furthermore, I can't help feeling that it would be better to use the lower-case versions for the common-case: the object-types (and rename the pimitives to something like C_prim_int32, or Cint is primitive). I am hopeful that the optimiser will be sufficiently clever to notice the obvious cases where a primitive can be used, so why distract the user? Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Primitive Vs Object types
Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? I was sure up until the time that I read your reply :). Why? I guess its a case of ass/u/me; plus reading other people's assumptions (e.g. Michael Lazzaro's initial Chapter, at cog.cognitivity.com/perl6/val.html). If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? Dave.
RE: Primitive Vs Object types
Dan Sugalski [mailto:dan;sidhe.org] wrote: At 8:24 PM -0800 11/6/02, David Whipp wrote: If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? The big difference is there's no way you can ever truly get a primitive type in perl 6. (At least so primitive that you can't hang properties off it) I hope I'm not being stupid here, but isn't that a lack-of difference. Michael has just confirmed that 'It has been stated multiple times that primitive types can't take runtime properties or other object-like features', so now I'm confused. Here's a list of things that ints/Ints might do, and my previous understanding of if they can: int Int 1 store 32-bit number YY 2 store larger number NY 3 store undef NY 4 have properties NY 5 be junctions NY It appears that you're saying that (4) is incorrect; and if this is wrong, then (3) is probably wrong too. I wouldn't be surprised if this means that (5) is wrong also, so this would just leave (2): Ints are bigger than ints. My original proposal still stands: represent these differences as a (compile-time) property, not a new type. Failing that, use typenames that are more distinctive (e.g. BigInt, or int32). Dave.
RE: Primitive Boolean type?
David Wheeler [mailto:david;wheeler.net] wrote:
The problem with this is that you have explicitly introduced true and
false into the language, and have therefore destroyed the utility of
context:
my boolean $bool = 0; # False.
my $foo = ''; # False context.
if ($foo eq $bool) {
# Oops!
}
If I am not mistaken, we already have explicitly introduced
true and false into the language:
my $bar = 0 but true;
my $bas = 0 but false;
A boolean type is therefore not quite as big a stretch as
you imply.
But we still have to deal with the expression issue:
if ($bar eq $bas) {} # true
if (?$bar eq ?$bas) {} # false
my $bool = true;
if ($bool eq $bar) {} # ???
Presumably, there exist rules for implicit casting when
comparing objects of different types. If we have a rule
that says that if either operand is a boolean, then both
are compared as booleans, then things would work just
fine (except the the things I haven't considered ;-)).
The question of what is Ctrue is really an implementation
issue. It could be a superposition of all true values; or it
could just be a predefined value, that has some special magic
associated with it. Perhaps its just a keyword, whose context
determines whether it is a value, or a property.
Dave.
RE: [RFC] Perl6 Operator List, Take 5
Larry Wall [mailto:larry;wall.org] wrote: : unary (postfix) operators: :... - [maybe] same as ..Inf [Damian votes Yes] I wonder if we can possibly get the Rubyesque leaving out of endpoints by saying something like 1..!10. Perhaps we could use the less-than symbol: 1 .. 10 Similarly: 1 .. 10 == 2..9 Dave.
RE: Perl6 Operator List, Damian's take
Luke Palmer [mailto:fibonaci;babylonia.flatirons.org] wrote:
for x | y - $x is rw | $y {
$x += $y
}
This superposition stuff is getting to me: I had a double-take,
wondering why we were iterating with superpositions (Bitops
never entered my mind). Did the C; ever officially change
to C| as the low-precidence list composer?
Dave.
ps. for readability, I think most situations require parenthesis
round these mega-lists.
RE: Character Properties
Jonathan Scott Duff wrote: Ok, how about this: Is there a reason Inot to? Or should I not go there? Off hand, it sounds expensive. I don't see a way to only let the people who use it incur the penalty, but my vision isn't the best in the world. It should be possible to define the bookmark methods on the basic string class to rebless the object onto a more powerful subclass. This way, there is no overhead until the extra information is actually attached. (bless, not copy, because there may be other references to the string). Dave.
RE: Indeterminate math
Mark J. Reed wrote:
I realize the above is mathematically simplistic. The
real reason y = x/0 returns an error is because no matter what
value you assign to y, you aren't going to get x back via multiplying
y by 0.
Well, that may be true in math; but there's no reason why it has to be
true in Perl6 (using the Math::Perverse module?)
Imagine
$b = 7 / 0
$b = undef but DivZero(7) but Overload('*' = sub ($rhs) { $rhs==0 ? 7 :
})
print $b * 0
7
print $b * 2 * 0
14
I.e. you can use a runtime property to remember the value that was
divided by zero. I'm not sure what the correct syntax is to make that
really clean: hopefully the DivZero property could do the Overload.
Dave.
RE: Lukasiewiczian logic (was Indeterminate math)
it looks like Lukasiewiczian NULL is just the nifty NULL that SQL has, and the nifty ways that it affects logical and aggregate operations. Actually, something I wouldn't mind seeing in other languages -- I can't say if perl is one of those, but if it can be provided by expansion, that would be neato. Looks like the X value of the 4 (or 9) state logics that ASIC designers use. I use Perl to do ASIC testbenches and stuff: so I'll probably be constructing something similar (and hopefully I'll have some nice bitwise and/or operators available: I use bitwise and | frequently; though I can accept that the majority of Perl users don't). Maybe I'll implement Verilog as a Parrot language. Dave.
RE: Private contracts?
Michael G Schwern [EMAIL PROTECTED] wrote:
I can see too many problems with that technique, I think one was
already mentioned where subclasses can unintentionally weaken
preconditions to the point of eliminating them.
Which is, of course, why we OR them, yet AND the postconditions
It is perfectly valid for an implementation to say I can meet the
post-condition, no matter what input you give me i.e. it can
eliminate the precondition, but not the postcondition. As code:
class Math is interface {
method sqrt (int $x) {
PRE { $x = 0 }
POST { sqrt($x) * sqrt($x) == $x }
}
}
class KnowsAboutComplex is Math
{
method sqrt (int $x) {
PRE { TRUE }
# calc result, possibly complex
}
}
Of course, KnowsAboutComplex would be invalid if the
interface had required the result to be a Real.
Dave.
RE: Interfaces
Michael Lazzaro wrote: What if a subclass adds extra, optional arguments to a method, is that ok? This is the scariest question, I think... In theory, yes, there are lots of potential interfaces that would benefit from optional extensions, I've made a few. In strict terms, though, they violate the whole idea of common, invariant interface, so I never know if what I've done is Acceptable, or a Shameful Hack... anyone care to make a case either way on this one? I don't think that the addition of an optional parameter violates any substitution principle: users of the base-class interface couldn't use the extra params (because they're not in the interface); but a user of the derived-class's interface can use the extra power (because they are in that interface). A derived class is always allowed to add things (thus, you can weaken preconditions, stengthen postconditions, add extra methods, return a more specific result, ...; but you can't strengthen a precondtion, nor weaken a postcondition, etc.) On a slightly different note, if we have interfaces then I'd really like to follow the Eiffel model: features such as renaming methods in the derived class may seem a bit strange; but they can be useful if you have have name-conflicts with multiple inheritance. Oh yes, and we need to make sure DBC stuff is part of the interface, not the implementation. Dave.
RE: Security model for Perl with good support in Parrot (Safe/Opc ode etc.)
Kv Org [mailto:[EMAIL PROTECTED]] wrote I believe Perl6 needs a facility to run compartmented code (object-oriented and module-loading) that is tagged as to its permissions and owner ID. The goal would be to let such code use harmful actions only by calling permitteed outside functions that implement permission checks before calling potentially harmful code. I'm not an expert in this area, but I think that a capabilities based model is probably better than compartments. The model would be that a program starts with a set of capabilities; and then any code that it calls (or thread that it starts) would inherit these capabilies -- a function call (or thread start) could explicity deny some capabilities to the code that it calls; also, a function could return additional capabilities to the caller. Capabilities could be stored as a hash in the %MY pad. The capability to add stuff to that hash would, of course, be highly restricted. A capability is probably just an object: any module can define any number of capabilities; but only it (not its subclasses) has the right to create instances of that capability (which it can then return to a requesting caller). When a function later trys to use a protected method, that method would check that its Ccaller has an appropriate capability Dave.
RE: Paren madness (was Re: Regex query)
It seems that the fundamental problem is the dichotomy between a scalar, and a list of 1 elem. Thus, we want $a = 7 to DWIM, whether I mean a list, or a scalar. Seems to me that the best way to solve a dichotomy is to declare it to not to be one: a scalar *IS* a list of one element. The only thing that needs to go is the inappropriate casting in numeric context. This leads to a second clarification, which has bothered me wrt perl6: the purpose of sigils. If everything is an object, and objects are $ things, then why have sigils? I think the answer is that the sigil defines the default interface (skin?) on an object. So, $a = 7; a = 7; both create identical objects; but the interface to these objects is different. so +$a == 7, while +@a is 1. Next: $b = 7, 6, 5 b = 7, 6, 5 Again, both create identical objects, under different interfaces. But now we have a problem with +$b: what should this mean? To be consistant with +$a (above), I would suggest that it simply returns the sum of its elements (i.e. +(1,2,3) == 6). Dave.
RE: Paren madness (was Re: Regex query)
From: Jonathan Scott Duff $b = 7, 6, 5 b = 7, 6, 5 Again, both create identical objects, under different interfaces. But now we have a problem with +$b: what should this mean? To be consistant with +$a (above), I would suggest that it simply returns the sum of its elements (i.e. +(1,2,3) == 6). Makes no sense to me. if $b and b are identical objects then what kind of objects are they? Are the commas list constructors? If so, then why wouldn't +$b == 3? $a = 10; $b = 7,6,5; $c = $a + $b; # what happens here? Is $c == 28? Anyway, this is most bizarre. My little perl 5 brain can't intuit. $a and a are not objects, they are variables. Variables provide access to objects. $a and a are different kinds of variables: when you view an object though a $ variable, it DWIMs like a scalar; when you view it through an variable, it DWIMs like a list. In numeric context, a $ variable obtains its value via a .NUMBER method. In the same context, an variable uses the .LENGTH method In both caes, the underlying object would have both .NUMBER and ..LENGTH methods. The only difference would be that the sigil defines different mappings between the calling context, and the method that returns the value. And thinking about your example, above, the value of $a + $b is probably 10; for the same reason as 3+foo is 3. If you're using -w then, of course, you also get the warning that argument [7,6,5] is not numeric in add at As others have said, we need Larry to look at all the various issues and proposals ... and then to chop the baby in half. Dave.
RE: Regex query
Larry wrote: : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) This kind of clever magic always makes me nervous: it introduces subtle bug potentials. (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false () == 0 # true? As someone who regularly writes code generators -- and even as someone who occasionally edits code without thinking straight, I am certain that I will, on occasion, introduce bugs through this mechanism. If the [] list-ref composers are to remain, there seems no good reason to add a redundant behaviour to parentheses. Or am I missing something? Dave.
RE: XS in Perl 6
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote: I'm thinking XS thoughts because we're going to need a few external things at SOME point It would be so nice if Perl 6's XS was part of the language, rather than an external pre-processor. [ some interesting stuff] Thoughts? Its good to start thinking about this early; but should we be thinking Parrot's XS; not Perl 6's? Parrot has to solve the problem of binding multiple languages together within a unified framework: Ruby calls a python method, passing a Perl object as a parameter. I would hope that the solution to that challenge will be sufficiently powerful to solve the problem of describing/generating an interface to C, C++, Java, Eiffel, and INTERCAL. Given that parrot will solve it in a language-neutral way, I am not sure that we should focus an a Perl6 XS, rather than an external pre-processor. We may want a Perl6 module that hides the complexity of the Parrot stuff; but that depends on how complex the Parrot stuff turns out to be. Dave.
RE: @array = %hash
Steffen Mueller
%hash4 = (Something, mixing, pairs = and, scalars);
1 23 4 5
Perl5 says Odd number of elements in hash assignment at -e line 1.
And Perl6 should, too.
Hmm, I rather like the idea of thinking of a %foo variable as a set, not a
map: a map is a set of pairs; with an equivalence class based on the first
of the pair. But I'm not sure if that way of thinking can work in Perl6. if
%set_of_ints is assigned a set of ints, it should return a list of ints, not
a list of pairs. But if it's a map with some DWIM for assignment from lists
of ints, then it would return a list of pairs. Perhaps I need declarations
like:
my %foo is set; # a set: $foo{bar} returns a boolean
my %foo is set(int); # set of ints
my %foo is hash; #default
my %foo is hash(int, any); # hash whose keys must be ints
my %foo is hash(string is equiv_class{lc $^a}, any); # case insensitive
string keys
I've just reviewed A2: it doesn't seem to say much about this stuff.
Dave.
RE: @array = %hash
Piers Cawley wrote: Maybe we should just say 'sod it' and implement the entire Smalltalk Collection hierarchy and have done with it? Sets, bags, hashes (dictionaries for the Smalltalker), whatever, all have their uses... I'm not sure if you were being facetious, but I do think all the functionality of these should exist: how many times do we have to explain, to newbies, the perl idioms for using hashes as sets? Collections boil down to two basic properties: ordered/unordered and duplicates/unique. We only have c% and c available for 4 combinations; and perl uses these to indicate the underlying implementation (sans ties), and the type of key. Seems to me that we will either end up using c$ (objects) for most collections; or we'll be creative in our use of properties for and %. Dave.
RE: rule, rx and sub
Thom Boyer [mailto:[EMAIL PROTECTED]] wrote:
sub while (bool $test, body);
sub while (test, body);
But neither of these really works.
The first would imply that the test is evaluated only once
(and that once is
before 'sub while' is even called). That'd be useless.
It seems to me that this can be thought of as analagous, in a strange kind
of way, to hyper-operator things. Thus:
sub while (bool $^test, body)
{
return unless $^test;
body;
redo;
}
Dave.
RE: Autovivi
Luke Palmer wrote:
Since variables are copy-on-write, you get the speed of
pass-by-reference with the mutability of pass-by-value,
which is what everyone wants. If you have this, why would
you want to do enforced const reference? That's not
rhetorical; I'm actually curious.
One reason I can think of would be if you had multiple
threads, and you wanted to poll a pass-by-reference
shared value inside the sub:
sub wait_for_done ( $done is shared )
{
return if $done;
sleep 1;
redo;
}
Dave.
Use of regular expressions on non-strings
I'm wondering if Perl6's new regex can be applied to non-string things. I seem to recall A5 mentioning something about strings tied to array implementations; but I'm wanting something a little more powerful. A bit of context: I use Perl for verification of big complex ASICs. We run a simulation and get a waveform database (stores values of each signal over time). We can then perform queries on that database to check verious properties. Example: I want to find any occasions where the bus is requested twice in a row, without an intervening grant signal. Its a fairly simple query to implement; but it is, in fact , a regular expresssions. So I would like to write (pseudo-code): my violations = ($waveform_database =~ m:any/ bus_request not bus_grant* bus_request and not bus_grant /); I can think of a number of ways of implementing this (one is to first create a string by iterating the database and mapping each signal to a bit in the [ascii?] value of a character, and then defining character classes -- though I'd not want to lose the timestamps); but will Perl6 make my life any easier when I write the module? I'm not trying to implement a full CTL* formal property checker; just something that lets me run queries on an existing simulation trace (which is an object). Ultimately, it would be nice to define an entire protocol as a grammer -- the signal trace either conforms, or doesn't (in which case I get the violations). Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Brent Dax wrote:
$href = hash { %hash }; #B
Why the curlies? if Chash is a function (ctor), then surely these should
be parentheses. In this context, parentheses are optional, so this could be
written
$href = hash %hash;
Dave.
A5: thread safety of matching
As always, most of it is great. so only the niggles get discussed. On page 7, the following example is given: $oldpos = pos $string; $string =~ m/... ( .pos == $oldpos ) .../; This implies that match position is associated with the string. This worries me. If 2 threads are matching on the same string (intuitively safe, because matching is a read-only operation) then both threads may both attempt to set ..pos. This would be unfortunate. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
A5: hypotheticals outside regexen
Page 13 tells use about Clet decls. But it also says that the topic must
be a regex. Whilst it explains that this isn't really a problem, I'm not
sure that it justifies it. So perhaps someone can clarify why this
(hypothetical) code in not a reasonable generalization:
our $foo = 0;
sub do_something
{
let $foo = $foo + 1;
# stuff ...
commit();
}
sub commit
{
fail if rand 0.3;
}
for 1..10
{
do_something()
CATCH { default {} }
}
print $foo\n; # expect a value of around 7
Dave.
A5: a few simple questions
First, a slight clarification: if I say:
m:w/ %foo := [ (\w+) = (\w+) [ , (\w+) ]* ] /
does this give me a hash of arrays? (i.e. is the rhs of a hash processed as
a scalar context)
When I look at this, I see a common pattern: the join/split concept. It
feels like there should be a standard assertion:
m:w/ %foo := [ (\w+) = split , (w+) ] /
..
Another useful assertion might the the long form of m,n repeat count:
m:w/ list := (\w+) repeat grep { even } 0..Inf ] /
to match an even number of words.
And a question about m,n (I think something similar came up a few weeks
ago): why isn't it m..n, i.e. a list of the numbers of matches allowed.
This seems to be the only place in perl6 where a list of numbers, as a
range, isn't constructed using the .. operator.
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: Accessor methods ?
Damian Conway [mailto:[EMAIL PROTECTED]] wrote: .bar is the auto-created accessor for $.bar, so they should do the same thing, no? Presumably, but perhaps not quite as fast. Assuming some subclass has not overridden .bar() Dave.
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
what about
while (do_something_with_side_effects_and_check_still_ok()) {
I presume we don't want to do look-ahead here.
Yes, I think he was saying exactly that we will do look-ahead
here. we don't guarantee order of evaluation is exactly saying
that, no?
As the he refered to, let me be absolutely clear that I am
*not* suggesting any type of look-ahead here. I was specifically
talking about the Cforeach loop, where Perl is expected to
implement the iterator. In a Cwhile loop, the programmer
controls the iterator, and would be surprised by a loop-ahead.
The implication is that we can only provide advanced PRE_LAST
style blocks (or their equiv.) on the Cforeach loop. The fact
that they are impossible on the Cwhile loop should not
constrain our thinking for the Cforeach loop.
Dave.
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
Miko O'Sullivan wrote:
Just checking here: is PRE_LAST a separate and non-mutually exclusive
concept from LAST? I.e., would this make sense:
foreach arr - $i {
PRE_LAST {print before last loop\n}
LAST {print after last loop\n}
print $i\n;
}
If so, wouldn't look-aheads still result in chaos and
confusion for tied arrays?
Under the hypothetical PRE_LAST block, I'd expect your code to
make sense.
It it too much to ask, of the creator of a tied array, to implement
their code in such a way that *reading* an element of that array
does not have significant side-effects?
If one is doing object oriented programming, then the concept
of substitutability requires that I can use a subclass anywhere
that I can use the base class. When I use an array, I expect
to be able to read elements from it, at random, without
breaking it. If a tied array does not permit me to read
its elements without worrying about hideous side effects,
then it is not an array.
If not, then I'd definitely disagree: to me, for's and
while's are just different flavors of loop and should
behave the same in every way possible.
The great things about things that are different, is that
they are permitted to differ. Cwhile and Cforeach are
not synonyms. They have distinct characters.
To me, the concept of PRE_LAST makes sense in the context of
Cforeach, and is easy to implement. In the case of a Cwhile,
or Cloop loop, the concept may still make sense: but the
details of the semantics need careful consideration. There's
a great danger of analysis-paralysis if we cogitate on the
difficult case. So perhaps we can first seek agreement on
the easy case.
Dave.
RE: Loop controls
Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote: Sorry, I thought I'd expressed agreement at some point. I like the else\s+(if|while|for|loop) construct very much, and I think the programmers of the world would like it too. I know a some people have issues with where's the if but it's no worse than where's the semicolon or where's the filehandle closed. Is this the same as saying that Celse can be followed by *any* statement? If not, then we would need user-defined control statements (a property on a sub?) that can be used in the else context. Also, if bare statements are allowed after an Celse, what about elsewhere? (no pun intended) Dave.
RE: Loop controls
Damian Conway wrote:
BUGS
Unlikely, since it doesn't actually do anything. However,
bug reports and other feedback are most welcome.
Bug:
don't { die } unless .error;
doesn't DWIM (though the current behavour, do nothing, is
logically correct).
Dave.
RE: Unary dot
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?
I would expect the the m2() call would use the invocant of m1.
If m1 is a called as a class method, then m2 would, also.
If every object has a Cclass method (Cref?), then you could
always call class-methods as class.m2().
Dave.
RE: Unary dot
Mark J. Reed wrote On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. Wouldn't that be the current topic's class? Dave.
RE: Unary dot
Piers Cawley 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 ? [...] Yes, I know there's several different ways I could do it, but this approach feels right. I think this comes does to huffmann encoding: which things are common, and which are less common. This probably depends on what you are doing (what paradigm you are following), so its really a question about the nature of perl. The things I've heard people wanting to do are: call method on current topic call method on current invocant call class method on invocant's class call private subroutine defined in current class call global subroutine The following syntaxes have been seen: foo() .foo() ..foo() ## rejected because .. is different binary op class.foo() FooClass.foo() ::foo() Package::foo() $foo() $_.foo() I see 2 partionings: * by scope: topic, self, named package, global * by invocant: instance, class, none My suggested resolutions: By Scope: global/ named package use the existing Foo::bar syntax; Topic uses unary . syntax; self uses nothing By invocant: infer from current invocant/topic; use foo() for no invocant Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ::foo() = ::foo() Bar::bar() = Bar::bar() class.foo() = ref($self)-foo() .class.foo() = ref($_)-foo() foo(self) = foo($self-self) = $self-self-foo() This assumes that Cclass and Cself are defined in UNIVERSAL Dave.
RE: Unary dot
Melvin Smith wrote
I think that would be just plain bad design, but I'd be happy
if someone showed me a use for it. :)
well, I've been known to do
sub UNIVERSAL::debug
{
my $self = shift;
my $msg = _;
eval {$self=$self-name} if ref($self);
my $timestamp = ...;
my $caller = ...;
print DEBUG [$timestamp] '$self' $caller: $msg\n;
}
sub UNIVERSAL::debugf { shift-debug(sprintf _) }
which can then be called as:
$class-debug(hello);
or
$self-debugf(world, %d, 42);
or even
hello-debug(world);
You are right. This is just plain bad design. But it can be useful.
Dave.
RE: Tree Transformations (was: Perl6 Macros)
Luke Palmer [mailto:[EMAIL PROTECTED]] wrote: Then the macro would not recieve 4 as the second argument, rather 2*6/3 in syntax tree form. Would the macro have to do its own constant folding? I hope not. So how could it check whether this thing was an integer? How could it differentiate that from pow(2.718, 2 * 6 / 5) ? Or would any constant folding take place before it was passed to the macro? For some reason, I am reminded of Microsoft's Intentional Programming reseach project. That system worked by allowing transformers to be coded against a graph representation of the software. I seem to recall that they had a pattern match against the graph the determine when to invoke a transform; and that the patterns were re-evaluated after every transform. Sounds a bit too heavy-weight for a run-time compiled language like perl I think we could achieve similar results by defining the the sequence of steps in compilation/interpretation; and allowing a transform to include code at every step. If each step is a tree-traversal, then you'd have hooks for pre- in- and post- order evaluation. Dave. p.s. the concept of transforms seems like a much better idea than that of macros. For one thing, it doesn't require any new syntax!
RE: rethinking printf
printf %d hash is $(%foo.string), $bar ;
no ambiguity and no confusion.
This would be nice, if scalar things use '$'. But:
perl5: printf %d is $foo{bar}, $baz;
perl6: printf %d is $(%foo{bar}), $baz;
Not so nice.
Dave.
RE: PMCs, setting, and suchlike things [forward from p6-internals]
In a related matter, computer languages with Symbolic Mathematics capabilities, like Mapple, let you explicitly demand where do you want the operation to take place. This could be done naturally in perl6 using the colon meta-operator: my $plain = $c - $d : Math::Complex # 3.0 + 0i sqrt(2 : Math::Integers) # - exception or not-a-number Not a bad idea,. I beleive that the perl6 adjective operator (for functions) will be a semicolon, not a colon. I'm not sure how it is planned to apply it to operators. Its also plausable to use properties: my $plain2 is Math::Complex = $c - $d. That would require overloading the '-' operator based on return type; and could get a bit nasty. Dave.
RE: Apoc 4: The skip keyword
switch(...) {
case 1: ...;
nobreak; /* intentional fall-through */
case 2: ...;
break;
case 3: ...;
}
Does anyone agree that `nobreak' reads much better than `skip'?
skip was uncomfortable when I read it (I at first took it to mean
skip over the following rather than skip to the following), but
I find nobreak also a bit strange. How about proceed?
If we mean fall-through, why invent a new term? Why not use the
intent: Cfall_through?
Dave
RE: Some Apocalypse 4 exception handling questions.
Peter Haworth [mailto:[EMAIL PROTECTED]] wrote: This is all very sensible, and I completely agree with it. However, don't we need some restrictions on what can go in PRE and POST blocks to ensure that they are still valid in inherited methods? There's another issue: sometimes we don't want to inherit PRE conditions. DBC allows a derived method to strengthen (add) post-conditions; but to weaken (remove) preconditions. I haven't (yet) seen how this weakening would be accomplished. Perhaps the mechanism that controls inheritance of preconditions may have a more general applicability? Dave.
RE: [dha@panix.com: Re: ^=~]
Piers Cawley [mailto:[EMAIL PROTECTED]] wrote:
Damian Conway [EMAIL PROTECTED] writes:
I suppose this discussion also raises the vexed question
whether ??:: can also be put out to pasture in favour of:
$val = if $x { 1 } else { 2 };
I like that idea.
Only if you can also do:
if $x { $x } else { $y } = 'foo';
But that looks really scary.
Its not really of nasty as it looks (IMHO). If we can have an
lvalue context for evaluation of expressions, then I can't
see any real problem.
We already have the possibility of evaluating a sub in
lvalue context. This is disabled unless the sub has the
lvalue property. Is there any reason why non-sub blocks
shouldn't have this enabled, by default.
Dave.
RE: catching warnings
In light of Apo4, I thought I'd re-ask this question. Is the following still
the approved idiom, or will we have a nice little /[A-Z]+/ thingie:
sub foo
{
temp $SIG{__WARN__} = sub {
warn $(timestamp) $@\n
}
warn hello
}
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: Apoc4: The loop keyword
Graham Barr wrote:
But I have lost count of the number
of times I have wanted to do
if ((my $foo = bar()) eq 'foo') {
...
}
if ($foo eq 'bar') {
...
}
To be contrasted with:
while (my($k, $v) = each %h1)
{
...
}
while (my($k, $v) = each %h2) # error?
{
...
}
Of course, there's an alternative now, using for, -, and pairs.
Dave.
Apo4: PRE, POST
Apo4, when introducing POST, mentions that there is a corresponding PRE block for design-by-contract programmers. However, I see the POST block being used as a finalize; and thus allowing (encouraging?) it to have side effects. I can't help feeling that contract/assertion checking should not have side effects. Furthermore, there should be options to turn off PRE/POST processing for higher performance. Perhaps we'll learn more about contracts (inc. invariants, inheritance) in a later apo? Will we still use the Class::Contract module? Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
catching warnings
Perl6 is going to introduce a non-resumable throw/catch mechanism to replace
die/$@. (I assume that die will be synonymous with throw, for
compatibility.)
But what about warnings? I frequently find myself wanting to catch
warnings (e.g. to add extra context around a library's use of undefined
value warning; or to die when a library issues a warning). Its possible to
hack this but, as far as I am aware, there is no clean mechanism for
resumable exceptions. Could perl6 add such a capability? I don't know what
the correct syntax would be, but the pseudo code might look like:
sub foo
{
try
{
$a = undef + 1 # replace this with something more interesting!
}
catch:warn
{
print $(datestamp): $@\n;
resume unless $::warn_count++ 10;
die warning-limit exceeded;
}
}
It doesn't have to be in the core language, but it would be nice if it was
easy to add as a module.
Dave.
RE: AOP
Aaron Sherman wrote:
All of this is still coming into focus for me, and I want to spend
more time reading the articles later, but for now I just wanted
to see if anyone else has been thinking these thoughts
I do like the idea of AOP; but I think the mechanism you suggest
are too clumsy. The particular weave that you are attempting is to
add before- and after- functions to a set of existing functions.
Ideally, this shold be imposed on the functions from outside.
Otherwise you are simply proposing an aternative syntax for
function calls within the sub body.
I'm thinking of a mechanism more like:
Class A;
sub foo { ... }
sub bar { ... }
Class B;
sub pre is before (A::foo, A::bar)
{
print about to enter $(caller.name)\n;
}
sub post is after (A::foo, A::bar)
{
print leaving $(caller.name)\n;
}
Class C;
sub another
{
...
}
another is after (A::foo, B::pre);
A good reflection mechanism makes it easy to write code that
finds all the methods on a class, so the requirement for a
list of method names is not onerous even when you want to
apply an after- function to all the methods of a class.
There are, of course, a number of issues to consider. Is
Ccaller the correct context for the woven function? What
order do multiple before/after functions get called in?
How do they interact with inheritance? Ideally, it should
be possible to write a precondition (assertion) checker
in a base class that is inheritied when its method is
overridden in a subclass
As you said, these are still early ideas.
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: the handiness of undef becoming NaN (when you want that)
More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
continue to work.
What is void plus one?
Can't we utilize the lazy arrays stuff to make all this work.
Out of the box, all entries could default to NaN. But its easy
to write
@a ^= 0;
to change this default. I'm sure this could be extended to work
with hashes. I'm not sure what the correct syntax is, though.
Dave.
Default values, was RE: the handiness of undef becoming NaN (when you want that)
Aaron Sherman wrote
On Mon, Oct 22, 2001 at 11:30:01AM -0700, David Whipp wrote:
More, someone has mentioned the %x{$_}++ feature, which
IMHO, MUST
continue to work.
What is void plus one?
Can't we utilize the lazy arrays stuff to make all this work.
Out of the box, all entries could default to NaN. But its easy
to write
@a ^= 0;
to change this default. I'm sure this could be extended to work
with hashes. I'm not sure what the correct syntax is, though.
Nope.
my @a;
@a ^= 0;
print @a
Are you saying that this should print an infinite number of zeros?
Quoting Larry on this subject (apocalypse 3, bottom of page 3): I
can think of other cans of worms this opens, and I'm quite certain
I'm too stupid to think of them all. Nevertheless, my gut feeling
is that we can make things work more like people expect rather
than less. And I was always a little bit jealous that REXX could
have arrays with default values. :-)
Dave.
RE: Default values, was RE: the handiness of undef becoming NaN (when you want that)
Aaron Sherman wrote Larry's hubris notwithstanding, I'd like to suggest that more, in this case means no, it prints nothing. This *must* be true, as you don't want: @a ^+ @b to always return an infinite list. You want it to produce a list with (as a3 suggested) length max(@a.length,@b.length) OK, now we've got this resolved, I'd like to return the focus back to the original point. @x ^= 0; @x[5]++; does not have problems with NaNs; and does not generate a warning with -w. My suggestion was to extend this to work with hashes, too. something like %x ^= $^_ = 0; or values %x ^= 0; Dave.
RE: Indenting
Well, as discussed briefly in an earlier thread, http:[EMAIL PROTECTED]/msg08514.html if we allow ! in function names, we can distinguish between the normal and in-place versions of functions without proliferating the number of keywords. chomp! $string; my $chomped_string = chomp $string; I've been trying to work out if there is a possible unification with assignment operators. Compare: $a.operator:+=(1); $a.chomp; Both modify their object. However, I think the issue my be more fundamental In fact, in most OOPLs, operations do modify their object while queries don't. A common strategy is to use a Cclone method when you want don't want to change the object of the operation. The use of decorations to distinguish uses of nouns is standard in perl culture ($@%). We don't currently use anything to distinguish verbs. I know it uses valuable characters, but adding Cchomp? to identify a query, and Cchomp! for an operation does not seem unreasonable. Unfortunately, the use of ! to mean modify_in_place is potentially ambiguous, because it is a unary operator. I would expect foo!$a to parse as foo(!$a), not (foo!)$a Another possibility would be use use C$a-chomp for operations and C$a.chomp for the query, but this doesn't help for the infix form. Obvious alternatives such as chomp= $a suffer the same flaw. Damian's suggestion of chomp: may be better, if I can teach my brain to scan it. I can't reach a conclusion in my own mind, so I thought I'd throw out my thoughts. Dave.
RE: Indenting
Is chomp? just a bad example, or is there some utility in asking if a string has already been chomped? The query is asking what the string would look like, if it were chomped. Dave.
RE: NaN semantics
So the imaginary numbers would be standard literals? Like $x=2+10i; Great idea, as well as sqrt(-1) returning 1i istead of raising the exception. BTW, I was thinking once that numeral literals like 4k or 10G (meaning 4*2**10, 10*2**30) would be very nice. What do you think? - RaFaL Pocztarski, [EMAIL PROTECTED] First this thread tells me that 123foo will be 123 in numeric context. Now I find myself wondering what 123indigo evaluates to! Dave.
RE: NaN semantics
First this thread tells me that 123foo will be 123 in numeric context. Now I find myself wondering what 123indigo evaluates to! It would evaluate to 123. If use complex is in effect, it would evaluate to 123i. At least that's the position I'm taking at the moment ;-) 123i unless of course we use nano prefix (postfix?), then it would be 0.00123i of course. ;) In which case 123foo is 123e-15 (femto). If we are going to have all these postfixes, then we would probably want invalid ones to evaluate to NaN instead of truncating them. We can always have a standard fn/method that strips the invalid characters off the end if the string: my $string = 1.23Ki4b2XXX. my $a = +string; # NaN my $b = +$string.numeric_prefix; # 1230 + 16i my $c = +$string.real_prefix;# 1230 my $d = +$string.integer_prefix; # 1 or some such thing. Dave.
RE: NaN semantics
Damian Conway wrote:
but I still have immense difficulty with the notion that:
$x == NaN
doesn't return true if $x contains NaN.
Anyone with a hardware background should have no difficulty with
this concept. All common HDLs have multi-valued logic systems,
including values like '0', '1' and 'x' (Some systems distinguish
9 different values!).
The language Verilog has 2 equality operators. The most common is
a == b, which returns false if a and/or b contains 'x'. But it
also provides a === b; which will return true if a and b are
identical (thus true if a and b are 'x').
The correct value of NaN == NaN should, of course, be NaN.
This value should exponentially spread through the code:
if ('cat' == 'dog')
{
$foo = 1
}
else
{
$foo = 0
}
assert($foo.isNaN); # true!
However, Perl6 is not a hardware simulator, so I have no expectation
that these semantics will be supported.
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: Math functions? (Particularly transcendental ones)
Uri Guttman we are planning automatic over/underflow to bigfloat. so there is no need for traps. they could be provided at the time of the conversion to big*. OK. But will Perl support signaling and non-signaling NANs?
RE: Anyone actually experienced with object inheritance?
Michael G Schwern wrote: Rather than stumbling around in the dark here, is anyone actually experienced with object inheritance? Any Self programmers out there? Someone that's actually used this technique often and understands what works and what does? Any books/articles to recommend? Its not quite the same thing, but Java does have the concept of anonymous classes (it names them 'inner' classes): Is Perl6 going to have a similar concept? Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Multiple classifications of an object
David L. Nicol wrote: The other standard solution is to add a Person has-a Employment_Status relationship, but that doesn't feel much better. It feels fine to me. Person has-a gender, person has-a job, it's more politically correct, even, than pigeonholing. You can even do dynamic multiple dispatch based on your has-a list, whatever it looks like. When I started this thread, I knew everyone would tell me that delegation is the answer: I included the note that I knew about that, but I guess the bias against MI is just too strong. My point was that, given that I want MI, that there is a simple modification the the language (though maybe not its implementation) that would save some programming effort. And I strive to be Lazy! When you tell me how simple delegation is, you are considering only the relationship itself. If I really want IS-A, and am forced to use HAS-A, then the mismatch results in added complexity (though not as much as when you use IS-A when you should use HAS-A) Consider, for example, the implementation of the Cisa method (in UNIVERSAL). Its easy to provide the additional predicate methods, but even easier not to have to. Then consider object creation and destruction. Even in Perl I need destructors because I usually implement a package-scope Cfind method for each class. Again, its not difficult to implement the house-keeping, but its easier not to have to. In my opinion, as long as we're checking object class with programmer code instead of automatic polymorphism, it doesn't make any difference. Checking an object's type is, in most cases, a seed around which complexity grows. Possibly more evil than Cgoto, definitely more evil than Cif, it is to be avoided in any non-trivial, high-level, code. (yes, I too am biased :) Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Multiple classifications of an object
Mark J. Reed wrote:
Okay, but now we're getting into the fundamental O-O model for
Perl. I guess that's fair game? You can certainly make the case
that prototype-based inheritance makes at least as much sense
as class-based inheritance for a dynamic language like Perl.
But that's a major implementation change and you have to be careful
to be sure that Perl stays Perl.
[...]
You could go the Python/JavaScript route and have methods just
be members that happen to contain code references, so
$obj.meth(@args) would be a synonym for $obj.{meth}.(@args)
(or $obj{meth}(@args) with the optional '.'s elided). But then
you're merging two namespaces that used to be distinct; e.g.
how do you provide an accessor function with the same name as
the scalar attribute it's protecting?
While I'm also fond of prototype-based inheritance, I think changing
the inhertiance model in Perl would be among the most radical
changes discussed so far. Not to say it's not doable, but I'm
wondering if it would be worth it or if it would really maintain the
language's fundamentally Perlish nature.
Good, this thread's found a much more productive path.
For the distinction between methods vs members, I don't think
we have to stray too far from perl-is-perl. Afterall, we already
know that foo is a function and $foo is a scalar. So from an
implementation perspective there's no problem giving methods
and members a separate namespace. Its just a syntax issue ;-).
We already have a sub keyword; and one of its parameters is
the name of the function. Allow that paramter to be a hard
reference to an object, and you've got a way of defining
object-level functions (members are objects):
sub $foo.{bar} { ... } #? === sub $foo.bar { ... } ?
To read the function associated, you can use a property sub:
$foo.{bar}.sub # returns the subroutine.
calling a property can pass a value, and parentheses are optional:
$foo.{bar}.sub { ... } # context says {} is subroutine composer
So the correspondance, foo $bar === $bar.foo, is maintained.
Now I just need to work out the meaning of sub $foo {}.
Dave.
Multiple classifications of an object
When you blass an object in Perl, you give it exactly one type. The @ISA variable allows that type to refer to many other classes as the inheritance tree. @ISA is a list, but ref($obj) isn't. This means that you sometimes have to create a lot of useless classes to work around this limitation. A simple example: Imagine you have a class Person. A Person can be Male or Female. Thats one set of subclasses. But a Person can also be Employed or Unemployed. So I might want to say bless $self, qw(Employed Male); In Perl5 I am forced to create 4 new classes: Employed_Male, Employed_Female, Unemployed_Male, Unemployed_Female. The combinatorial explosion can, well, explode! The other standard solution is to add a Person has-a Employment_Status relationship, but that doesn't feel much better. Its just another way of programming round a weakness in the object models of most mainstream languages Can anyone see any problems with making Cbless and Cref work with lists? Cisa is not effected. We might want some magic to ensure 'ref($foo) eq bar' still works as expected. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Multiple classifications of an object
Peter Scott wrote: What's wrong with multiple inheritance? You have to create a whole load of extra classes whose only purpose is to define a list of superclasses. Compare: bless $self, qw(Employed Male); with package Employed_Male; @ISA=qw(Employed Male); # multiple inheritance ... bless $self, Employed_Male; Allowing Cbless and Cref to use lists allows me to be slightly more Lazy. In bigger hierarchies, the benefits are greater because the number of possible leaf classes is greater. (Imagine Employed as subclasses of FullTime and PartTime; then add in race, ethnicity, ...) Some people would argue that these things are attributes, not base classes; but those same people would argue that multiple inheritance is bad. I'm not objecting to multiple inheritance: I just saying that its a waste of effort to create classes that don't add any new details. If the class that combines multiple superclasses adds unique behaviour/data to that combination, then multiple inheritance is the correct solution. When all you are doing is saying that an object has 2 classes then forcing the extra work is just a waste of time. Dave.
RE: suggested properties of operator results
From: Damian Conway [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 11, 2001 4:06 PM
To: [EMAIL PROTECTED]
Subject: Re: suggested properties of operator results
I think we will see n-ary comparisons allowed in Perl 6:
if ($x $y $z $foo) {...
but as special case syntactic sugar for the expANDed version:
if ($x $y $y $z $z $foo) {...
Oh, and with only single evaluation of each operand.
Does it do short-circuit evaluation, too?
Dave.
RE: Properties and stricture
Michael G Schwern [mailto:[EMAIL PROTECTED]] wrote: Of course, there's problems of order of definition. What happens if Bar.pm is loaded before Foo? Dunno. simple sematics can be defined. If we see a declaration: package Foo is encapulated; then we throw an error if the namespace, Foo, is not empty. At the end of the package (either EOF or a new package decl) then the namespace is sealed. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: what I meant about hungarian notation
Edward Peschko wrote:
As to what the combined
$bar[$foo]
would mean: that depends on what $bar contains.
I like visual clues to tell me
what type of variable
something is. And I disagree strongly with trying to
steamroller the language's
design paper-flat as much as I disagree with unnecessary
ornamentation.
So I'll take my '{}', thank you very much
But you are assuming thre are only 2 types of indexing scheme for
collections to which $bar might be a reference. In the OO world, I can
define all sorts of wierd things, some of which may be useful. Am I forced
to write $bar.index($foo) for anything other than hashes and arrays?
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: apo 2
is = typing, inheritance, etc.
has = composition, aggregation, etc.
True, but those are basic OO concepts, which don't neatly apply to
property-lists (a very old Lisp concept that Perl6 is adopting).
is does seem to imply an OO is-a relationship. So lets run
with it!
If $foo is an object of type INTEGER, then $foo.bit calls a
method that compares the numeric value against 0 and returns
1 if not zero.
If $foo is true, then its method $foo.bit is expected to return
1.
In OO terms, when you override the behaviour of your methods, you
are usually subclassing. So perhaps the declaration $foo is true
should literally mean: create an anonymous subclass derived from
$foo's class that overrides its .bit method to return 1; change
$foo's class to this new subclass Multiple is declarations
would simply stack up the subclasses.
If true is a class with a single method sub .bit { return 1 },
then the subclass of $foo is creating by copying true's methods.
So $foo is myClass simply means that we subclass $foo with a
clone of myClass. constant would be a class that overrides the
assignment operator.
On a slightly different note, I read that my Dog $foo doesn't
call a ctor. I do hope that my URL $name; ...; $name=www.foo.bar
does DWIM.
Dave.
p.s. I prefer to paint my bikeshed's true and false as .bool, not
.bit. In the hardware world, the distinction is important because
we often slip into negative logic.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
Dan Sugalski wrote At 12:19 PM 4/16/2001 -0700, Peter Scott wrote: Or were you espousing the notion that perl 6 programs should be able to contain sections of perl 5 code? That gives me strange palpitations. This is what I've been arguing against. Unless I misunderstand (and it wouldn't be the first time... :) this is what some folks are arguing for, and I very much don't want to go there. Not with perl 6.0.x, at least. But remember the libraries. Do we really want to rewrite all the modules on CPAN? I think the reason for mixing is that it should be possible to use a Perl5 library module with Perl6. And that opens all those cans of worms. We are going to have a mechanism to interface with multiple languages via an upgrated C interface mechanism. Can we find a mechanism for interfacing to Perl (5)? Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Larry's Apocalypse 1
John Porter wrote I'm sure you don't want to write "$a = new Integer '32'". Of course. That would be unbearably absurd. But how often do you have to write expressions that operate on three or more URLs? Or even two? How many perl instrinsics return URLs? How many perl intrinsics operate on URLs in any way? A related question is why we want to tie objects. Afterall, you can use methods on an object without ever tying it! HTF does tying have anything to do with the current thread? Since you ask so politely: Tying is a mechanism by which a programmer can make an object look like a built-in. This can be useful. I was looking at the "http:...' as a specific example of a general mechanism by which a programmer can make a class behave like a built-in wrt its ctor. I see this ability to define a new type of literal as being analagous to tying. They are both special cases of the general concept of using magic to hide the fact that you're using a class. Obviously they are very different in the specifics. You may be right that there are no useful literals other than strings, integers, reals and lists. OTOH, if we are going to construct a meta-language which supports multiple syntaxes, then it is very likely that each application-specific language would have its own literals. The question becomes whether perl itself should have this ability. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Larry's Apocalypse 1
James Mastros wrote: print $::OUT http://www.wall.org/~larry/index.html; Please, no! A URL isn't a /new/ type of literal, really. Either it's a wierd form of a literal list, or it's a wierd type of file name, so you should open() it. Or it's a self-quoting literal, like Packagename::. If you really want to be able to read from a URL in one line, let yourself do open(foo). But make opening a URL an explicit act. I agree that an implicit "open plus get" would be a bit much. However, I see nothing wrong with defining a new form of literal, especially if everything acts like an object. It would be nice to say: $mySite = http://www.foo.bar/text.html; and then $mySite-get(...); $mySite-post(...); even: $page = $mySite; $page = http://www.foo.bar/text.html; I could go further: If I'm reading a URL of type html then, after reading it, I should be able to say: $header = $page-head; $title = $page-title; etc. I think what I'm saying is that we shouldn't think in terms of strings unless a method is evaluated in a "string context". Until its reduced to a string, a literal (or any other value) should maintain its class. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Larry's Apocalypse 1
John Porter wrote: $mySite = http://www.foo.bar/text.html; Vs. $mySite = new URL 'http://www.foo.bar/text.html'; I am far from convinced. Simon Coxens wrote A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie The obvious reply is: "There's more than one way to do it" I have to agree that there's not a huge diference between the two ways of calling a constructor. I suppose the important thing is the distinction between class and type. In the latter case, I explicitly say "make be an object of class 'URL': use the constructor named 'new' with these args". The the implicit form, you are simply using 'http:...' as a factory that creates an object of a class that conforms to the expected type. I'm sure you don't want to write "$a = new Integer '32'". Sometimes there is value in omitting trivial syntactic details. A related question is why we want to tie objects. Afterall, you can use methods on an object without ever tying it! Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: Larry's Apocalypse 1
One-liners run on a Perl 6 binary should just be Perl 6 code. Do we really have to worry about backwards compatibility with one liners? Hmm... programs that have perl one-liners inside them might be troublesome. Why not: perl -e 'perl 5 one-liner' perl --cmd 'perl 6 one-liner' i.e. maintain the "-e" switch as a backward compatibility flag, with a new cmd line flag for perl 6. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
RE: What can we optimize (was Re: Schwartzian transforms)
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] I'm hoping to have this stage of optimization in perl. Off by default with a normal parse-and-go run (though certainly enableable if you want), on by default with the bytecode compiler. Don't forget about run-time information: You could mark candidates for optimisation at compile time then, at run time, if the size of the array is "big" then spend the time to see if you can optimise. I'm not sure how to define "big", but I'm sure that's solvable. Dave.
RE: Schwartzian transforms
From: Russ Allbery [mailto:[EMAIL PROTECTED]]
we can just flat-out say "We may optimize your
sort function"
I am strongly in favor of that approach. I see no reason to allow for
weird side effects in Perl 6.
Let me second the motion. "Allow optimisation" should be the default. A
programmer should, however, be able to say
sort sub :no_memoize { $global++ ; (($a*10+$b)%3)-1 } (1..10);
if they really want to. But make the programmer say "I am doing something
wierd", not the other way round.
Dave.
RE: A Warning on Meaningless Additions (Was: Re: A funny thing about e)
perl -le '$n=1; print "$n \t",((1 + (1/$n))** $n) while $n*=1.001' [...] When to throw away a result as meaningless is certainly an important piece of wisdom, I do not know any programming languages that do it for you -- issue a warning when you've overloaded your accuracy instead of merrily returning you your noise -- what do you think? What, exactly, would be warned against? In the case above, the interesting case is a floating point underflow. IEE754 defines a few ways to determine underflow and requires that a conforming implementation provide this status information. It additional defines the concept of a trap, which may optionally be implemented. So, if perl is to provide compliant floating point support, it should provide access to the floating point status info (in the standard, this is confusingly known as exception status). I feel there should also be either a pragma or a ctor that tells perl to throw exceptions on the IEE754 trap conditions. For completeness, this should also be available for integer arithmetic. (BTW, I think ADA provides this: I can't think of any other common languages that do) Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
