Re: CLOS multiple dispatch
Hong Zhang wrote: How do you define the currently loaded? If things are lazy loaded, the stuff you expect has been loaded may not have been loaded. We could load placeholders that go and load the bigger methods as needed, for instance. -- David Nicol 816.235.1187 do be do be do
Re: CLOS multiple dispatch
Me wrote:
I can imagine plausibly useful dispatch rulesets that do not involve
comparing sums of inheritance distances. (Though this *is* all
imagining as I haven't used multimethods/clos in about 10 years.)
I would also imagine that others see that summing inheritance
distances may not be the only intelligent way to pick among
candidates when a perfect fit is not available.
One stupid but simple system would be, take the best fit on
the first argument, then choose from among remaining variants for
second argument, repeat for all arguments.
Combined with an easy syntax for duplicating all possible calls
for purposes of matching on the second or nth argument, or at least
a tool for listing all the prototypes, for development purposes.
That could get ugly though.
dispatching a call with N typed arguments could be considered as
selecting a cell from a sparsely filled array in N-space. In keeping
with the idea of virtual tables, the N-block could be completely filled
at routine registration time. Which means we would need a prototype
language that says which cells in N-space to take. Maybe a parameter
to indicate match strength
or multiple prototypes for the same routine:
sub handle
(normal_window $w, resize_event $e)
(contrived_resizing_window $w, event $e)
{
$w-set_size(e-get_size);
};
combined with a shorthand for generating lots of available prototypes
sub handle
(*_window $w, kill_event $e)
{
$w-kill();
};
At some point during last year's discussions (possibly a year ago this
week, who knows) there was discussion of making the prototypes
match based on regular expression match against the names of the
types of the objects. That would be a mechanistic approach to
implicitly filling the N-block. I believe it was left out of rfc97
due to incompleteness of the specification.
Even if the dispatcher is the heart of multimethods, perhaps it
would be nice if it were convenient to replace the dispatcher
in whole or part.
If the dispatcher is drop-in replacable, what does its interface
look like? How much information is it allowed to gether from the
source code? Do we even want to support one specific one rather
than what we can do in '5 which is set up a special package
where multimethods live and have each one start off with its
dispatch routine?
multimethods::handle($w,$e);
--
David Nicol 816.235.1187
KAK OH CKA3AT what he said
Re: CLOS multiple dispatch
Hong Zhang wrote: 3) The multi dispatch is generally slow and complicated. Since it does not fit well with OO concept, it will just cause more confusion. Typically we use different solution for OO language vs procedure language. In other words, how much do we want our language to set up for us and how much do we want to do ourselves? -- David Nicol 816.235.1187 A long time ago, in a galaxy far far away...
notes from a stroustrup talk
This arrived as part of a mailing list that I suppose I opted into at some point: == More ++, Less C Standard template libraries, abstract classes and multiparadigm programming are keys to high-performance == Too much C++ code is just C. For example, people do class hierarchies in a very naive way. They think of a few implementation details that are common and they throw them into a base class. I have been preaching about this for nearly 15 years, and nobody listens. It's so much easier to make your own mistakes than to listen, lectured Bjarne Stroustrup, creator of the C++ language in his Tuesday, August 28, 2001 keynote at the Software Development East conference in Boston. Now head of ATT's Large-Scale Programming Research Department in Florham Park, New Jersey, Stroustrup continues his focus on efficient algorithms and high performance. The solution to the problem of overloaded base classes, said Stroustrup, is to write interfaces that are totally abstract. Writing code like this is a bit tedious because of the repetition, but if you have a concept, make it a class. This is one way to handle common state. Beginning his talk with a graph depicting the performance of linear algebra calculations programmed in C++ and Fortran, Stroustrup pointed out that, while beating Fortran at what it does best is difficult, it can be done. These are my semi-arm-waving comments on efficiency. Efficiency matters--not everywhere, but in embedded systems and performance numerics, which are areas that interest me, it does. What is slowing down C++ coders everywhere? First, too much reinvention of the wheel, he said. If you think you can build a matrix library, go ahead, but there are many already available. He also lambasted Smalltalk-style hierarchies and showed several code snippets explaining how to better manage resources. Say you acquire a resource and then you close it out at the end. What if you never get to the end? he asked rhetorically. OK, so you open a try block, catch the exception... But there is something fundamentally wrong with this solution. Your code has roughly doubled in size. You're better off creating a class with a destructor. Object-oriented programming, Stroustrup went on to say, is really just one of several paradigms C++ users have at their disposal. Multiparadigm programs that use OO, generic programming and data abstraction are powerful ways to achieve fast performance and power. If you were designing C++ today, would you do anything differently? an audience member asked. Undoubtedly, responded Stroustrup. Language design is a response to a set of problems you are facing at a point in time. I would want to support direct representation. I would not, however, build a high-level language and sacrifice efficiency. A lot of times, that question really is, 'Did you really mean to design something like Java but you couldn't?' and the answer is no. In terms of performance, C++ and Java don't mesh. I could make a similar statement about C#, but I won't. You also have to remember that I don't like proprietary languages. So how will C++ evolve over the next 10 years? Templated type definitions should be there, Stroustrup predicted. The main effort should be in standardizing some of the libraries. It's not going to be easy, but I see it as a language that maintains its emphasis on run-time efficiency. The area I'm most interested in is distributed computing. I don't see any real likelihood of changes in C++ for supporting Web development; that belongs in the area of libraries. Whether any such libraries can be standardized is a big question, though. I have my doubts. --Alexandra Weber Morales -- David Nicol 816.235.1187 A government of the p8a, by the p8a, and for the p8a.
Re: Expunge implicit @_ passing
Michael G Schwern wrote:
If you *really* wanted to write an optimized redirector, you'd
have the redirector eliminate itself.
sub foo {
my $method = $_[0]-{_foo} || $_[0]-can(_foo);
{
no warnings 'redefine';
*foo = $method;
}
goto $method;
}
:)
It's nice to see that someone looked at the import method in
Pollute::Persistent
At some point I came up with a list of Ways Life Would Improve
If Perl Had Tail-Recursion, or something like that. It largely
hinged on being able to access the calling context more aggressively
than returning a value back into it, was a side-effect of something
else, or required something else which had other beneficial effects.
Sorry about the vagueness
--
David Nicol 816.235.1187
A government of the p8a, by the p8a, and for the p8a.
Come and get me, Schwern
Michael G Schwern wrote: The idea that a class is either 'perfect' or 'complete' has to be the silliest, most arrogant thing I've ever heard! So, subsequent refinements have to use a has-a instead of an is-a relation in re: objects of the final class. Maybe the inclusion of this feature could lets certain nervous implementors get to sleep without worrying about getting blamed for things their objects did after they were out of their control. Java is, after all, all about giving guarantees of authenticity and whatnot. Bill J. Programmer publishes a class foo that is guaranteed to correctly blarg the frobniz, someone subclasses it and breaks the blarg function, that simply will not do! With a final it is no longer possible for the new class to identify itself as a foo. -- David Nicol 816.235.1187 A government of the p8a, by the p8a, and for the p8a.
Re: Per-object inheritance in core a red herring?
Dan Sugalski wrote: At 11:01 AM 7/10/2001 -0400, Adam Turoff wrote: And where's the guarantee that vtbls are per-object and not per-class? VTABLES ARE PER OBJECT. So mote it be. :) Dan What? Up until now it's been vtable-pointers are per-object.
Re: Per-object inheritance in core a red herring?
[EMAIL PROTECTED] wrote: On Fri, Jun 29, 2001 at 09:50:55AM -0400, Dan Sugalski wrote: Besides, there are languages that do this on a per-object basis all the time anyway (aren't there? I think there are) in which case it makes sense to yank it into the core interpreter, as it'll be supporting more than just perl. *bu* false logic. If you can do something via a core module, it is supported by Perl. Or does Perl not do CGI, web stuff, databases, etc...? Anyhow, Self is the only one I can think of. ALL THE FULL-TIME SELF PROGRAMMERS HERE, PLEASE RAISE THEIR HANDS! ;) Uh, C++ virtual methods can be overloaded on a per-object basis, not just a per-class basis, since the object drags around its virtual jump table with it wherever it goes, so the jump can get compiled into jump to the address that is offset bytes away from the start of the object that is doing the method which is pretty light, unless you've got dozens of virtual methods. In practice, they get overloaded in aggregate, but the constructors have to fill those values in, and they have names, and they can be explicitly altered, if you want to have one widget that frobs differently from all the other widgets you can set that up without devising another class. C++ I'm talking about here. -- David Nicol 816.235.1187 Perl was born in downtown Hell! -- Matt Youell
Re: Per-object inheritance in core a red herring?
[EMAIL PROTECTED] wrote:
Anyhow, if you want Perl 6 objects to be able to act as if they're in
their own class (ie. have their own methods, inheritance, etc...) how
are you going to do this without having the moral equivalent of a
stash associated with it? And if you can do something that saves
memory on object inheritance, why not apply it to class inheritance?
what if there was a core shortcut that hid the virtual methods -- the
selecte methods that are allowed to be overridden on a per-object basis
just like in C++
Without the core shortcut, you'd have:
package moderatable_fido;
sub new{
my $self = {};
$self-{sound} = \dobark;
bless $self;
};
sub dobark { print Woof!\n }
sub bark { goto {$_[0]-{sound}} }
incorporating such a declared virtual into Class::Object -- is it there
already?
--
David Nicol 816.235.1187
Perl was born in downtown Hell! -- Matt Youell
Re: Per-object inheritance in core a red herring?
Adam Turoff wrote: And what's the linguistic hook that allows C++ object-based inheritance? And where's the guarantee that vtbls are per-object and not per-class? Z. You're right, it might be a side effect of a particular implementation of virtual methods. But AIUI that implementation is universal. . g++ 2.95.2 apparently won't let me do it, d.virtmeth = gives me a compiler error vdem.cpp:43: taking the address of a bound member function vdem.cpp:43: to form a pointer to member function, say `demo::virtmeth' which seems to imply that g++ is using a per-class virt table, so I'm wrong. -- David Nicol 816.235.1187 Perl was born in downtown Hell! -- Matt Youell
Re: Per-object inheritance in core a red herring?
Adam Turoff wrote: On Tue, Jul 10, 2001 at 02:08:58AM -0500, David L. Nicol wrote: Uh, C++ virtual methods can be overloaded on a per-object basis, not just a per-class basis, since the object drags around its virtual jump table with it wherever it goes, so the jump can get compiled into jump to the address that is offset bytes away from the start of the object that is doing the method which is pretty light, unless you've got dozens of virtual methods. And what's the linguistic hook that allows C++ object-based inheritance? And where's the guarantee that vtbls are per-object and not per-class? Z. Apparently I was basing my statements on an incorrect understanding. According to a recent C++ reference, http://www.icce.rug.nl/docs/cplusplus/cplusplus16.html#l269 A common implementation is the following. An object containing virtual functions holds as its first data member a hidden field, pointing to an array of pointers holding the addresses of the virtual functions. It must be noted that this implementation is compiler-dependent, and is by no means dictated by the C++ ANSI definition. The table of addresses of virtual functions is shared by all objects of the class. It even may be the case that two classes share the same table. The overhead in terms of memory consumption is therefore: One extra pointer field per object, which points to: One table of pointers per (derived) class to address the virtual functions. At this time, I do not know if I actually worked with a compiler that implemented virtuals per-object, ot if I just thought that that was how it did it. Anyway, the scheme I described would be one way to do per-object method overloading. Letting the method that is supposed to be overridable on a per-object basis look up the object that is calling the method in a table keyed with object pointers might be lighter than keeping a field in every object -- it would depend what fraction of the objects of the type would get overloaded and how many would keep the default, and the memory vs. speed trade-off. I do not think the language needs additional cruft to support this; I think it would be better handled in the implementation of the accessor functions. Wait for better tieing and reimplement. -- David Nicol 816.235.1187
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
Matt Youell wrote:
What if you want multiple constructors with redundant code, et cetera --
there is flexibility.
You could get that same flexibility from a mandated new(). If you don't want
to support new, overload it so that it does nothing. Or maybe that could be
the default behavior. The major benefit being a code-supported (but not
enforced) preference that could be relied upon to exist.
So you're saying you would $@ to remain undefined after
$NewName=join('',map {${[a..z]}[rand 26]} 1..10);
eval \$Freshone = new $NewName;
What would $Freshone be? a blessed reference to undef?
--
David Nicol 816.235.1187
It's widely known that the 'F' in RTFM is silent. -- Olie
Re: http://www.ora.com/news/vhll_1299.html
Buddha Buck wrote: True, agreed, and admitted. So why can't a general purpose programming language be designed with XML-based syntax? Why can't a general-purpose programming language be augmented with XML for internal documentation purposes? Maybe the gcc back end could accept this new XML p-code. -- David Nicol 816.235.1187 Series EE bonds can be exchanged for Series HH savings bonds.
Re: You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either.
Jeremy Howard wrote: \ Perl 5 didn't need templates, because there wasn't compile-time typing. But with Perl 6 I want to send my compact array of integers to the same fast sum() function as my compact array of floats, and not have to wait while perl treats them both as old generic scalars. That means that my sum() function needs a typed parameter list. There seems to be at least two potential solutions: - Provide a type placeholder in the parameter list (a la C++ function templates) - Provide a type hierarchy for all types (a la Haskell) - (And that 3rd option that I haven't thought of yet...) I haven't been tricked into reading MJD's article yet, but might your third option be multiple functions with parameter-type-based dispatch? We can do that with perl 5, but it isn't automatic. I don't remember seeing either of these suggestions in the RFCs, but I might have forgotten since I occassionally fail all 361 of them in my head. A hierarchy of types is briefly referred to in RFC 4 but not really developed to deal with this issue: http://dev.perl.org/rfc/4.html Stuff about polymorphism and multiple dispatch was supposed to touch on these issues, bog only knows if it did or not. -- David Nicol 816.235.1187 Series EE bonds can be exchanged for Series HH savings bonds.
Re: Implied types, first try. Or Its amazing what you can do with potatoes
[EMAIL PROTECTED] wrote:
First off, I'm going to pound on one of my deceased horses a bit:
Why not drop the sigil on things with declared types?
Then $foo keeps its status as Perl's Magic Autoconverting Wondertype
and without it, we know we aren't dealing with the PMAW and we
won't make mistakes based on thinking that we are.
With it, we still have to remember what types things are declared
as, so it becomes meaningless.
Thanks for listening.
I'm pondering this being okay:
my Num$dec = 4.0;
my Int$int = $dec; # Num - Int okay since 4.0 truncates to 4
# with no(?) information lost
You have lost information. You have lost one digit of precision. That is
not
insignificant. Although that information is currently carried in STRING
types and not in FLOAT types.
You'd have to do an explicit typecast (syntax left as an exercise).
Given that most times when you try to use a reference as a string
you're making a mistake, this shouldn't be a big deal.
This would be a nice thing to have a pragmata for, what hash refs
stringify to.
Now, here's an example of something that might be really annoying to
get right. Let's say localtime() returns a hash in Perl 6 (sensible).
Let's also say that not only does it return the year, mday, hour, min,
sec, etc... as integers, it also returns things like the name of the
month, name of the day, etc...
my %time = localtime;
# Today is Monday, July 9, 2001
printf Today is %s, %s %d, %d, $time{qw(dow month mday year)};
What should the return signature of localtime look like? Obviously it
should return a hash, so that much checks out. But each of the keys
should be typed as well, String or Num. It would be really, really
annoying to have to set up the hash and all its keys just right so it
can accept the return value from localtime. Instead, perhaps Perl can
simply imply its type from the declaration:
my %time = localtime; # %time's type declaration is implied by
#localtime's return signature AT
#COMPILE TIME!
%time = gmtime; # ok, localtime and gmtime have the same
#signature.
$time{mday}++; # ok, $time{mday} is an Int
$time{mday} .= 'foofer' # *run-time error* Implicit $time{mday}
#Int - String cast ok for the string
#append, but trying to convert the
#String 10foofer back to an Int fails.
localtime would return a magic read-only hash reference. the dow lookup
would be deferred until printf needs it and no sooner. And if we don't
use %time again for anything else in the block, it doesn't even get
memoized.
my $foo;# *error* forgot to declare a type.
We could have Perl go through heroics to try and find $foo's first
assignment and imply a type from that, but I think that will rapidly
get Messy and Surprising.
my $foo;# PMAW
my int count; # an integer (maybe an automatic big-int)
...
count = int($foo); # redundant, it's implied, unless
# using strict of some kind
...
$foo = count; # legal too
if you insist that $ only means there's only one of this you have
made it completely meaningless. The scalar sigil should be dropped
from strongly typed variables.
--
David Nicol 816.235.1187
Perl was born in downtown Hell! -- Matt Youell
Re: Between-Opcode Callbacks
Jarkko Hietaniemi wrote:
...
This sounds like having also 'basic block' entry/exit opcodes. Hmmm.
BLB = block begin
BBB = basic block begin
SE = statement end
BBE = basic block end
BLE = block end
sub foo {
BLB
BBB
my ($a, $b) = @_;
SE
my $c = bar($a + $b);
SE
my $d = bar($a - $b);
SE
BBE
BLB
if (BBB $c $d BBE) {
BLB
my $e = $c * $d;
SE
return ($e + 1)/($e - 1);
SE
BLE
} else {
BLB
($c, $d) = ($d, $c);
SE
BLE
}
BBB
return ($c + $d)/($c - $d);
SE
BBE
BLE
}
do
s%([A-Z]+)([BE])%${\(($2 eq 'E')?'/':'')}$1%g
on that and you've almost got XML!
--
David Nicol 816.235.1187
Perl was born in downtown Hell! -- Matt Youell
Feeding potatoes to dead horses
Michael G Schwern wrote: I'm going to say you need sigils for this: print Hello, my name is $name\n; You're going to say this: print Hello, my name is $(name)\n; I actually prefer print Hello, my name is ,name,\n; or, the sigil is simply optional, and hello my name is $name still works. but that's neither here nor there. Guido apparently finds all variance from printf formatting confusing and unweildy. I said the horse was dead when I rode in on him. The real problem isn't [sig digs]. The real problem is how much this complicates the implicit typing rules. I'm going to have to play around a bit and see which way works best. I hope you're proposing that fatal errors on poor conversion is off by default. You'd have to do an explicit typecast (syntax left as an exercise). Given that most times when you try to use a reference as a string you're making a mistake, this shouldn't be a big deal. This would be a nice thing to have a pragmata for, what hash refs stringify to. Why? Example of use? I had a situation where I cared if refs were reffing the same object or not and interpolating them was actually handy. But there are other situations where it might be nice to have them expand to their keys, expand to their values, or expand to their perl5 arrayifications. So why not support all of them and defer the decision to the user. When in doubt, do everything. Now, here's an example of something that might be really annoying to get right. Let's say localtime() returns a hash in Perl 6 (sensible). snip localtime would return a magic read-only hash reference. snip I just picked localtime() as a sufficiently complicated example. I don't really want to discuss its interface here. See sigils above. Oh. I thought you were asking, would the interface would have to be fully described for the assignment to occur, and I said no, I don't think it would have to be. The real question: variables implying their types from function signatures... is it sane? it's backwards. Everyone else (C++, the polymorphic dispatch RFC) selects the function based on the signature required to satisfy the constraints of the required return type, and you want to imply the return type based on the function signature. It (variables implying their types from function signatures) could co-exist with multiple dispatches, for functions that only have one possible return type. And with a function that returns a well-defined packed structure with associated accessor methods, keeping that structure at an offset into a block scratchpad (instead of an array-of-references scratchpad) might be a cool optimization. You would give up dynamic function overloading, and a passle of other rarely used features you could look for and call off the optimizations if you see, or keep the parse around to rebuild the executable when the definitions are no longer current. At overload time, the code at the old address for the newly redefined routine is changed to cause the enclosing block to get rebuilt, that would be better than checking all the time. Every routine that is inlinable would need to maintain a list of where it was inlined, for this eventuality. --no-inlines could be one of those compiler promises. This crap is all probably patentable -- at times like this I'm glad I fucked up the IBM job interview in August, 1986 -- My brain! Mine! So, yeah, sure -- variable type implied from return type. There are some rocks around, so don't surf near them. my $foo;# *error* forgot to declare a type. We could have Perl go through heroics to try and find $foo's first assignment and imply a type from that, but I think that will rapidly get Messy and Surprising. my $foo;# PMAW PMAW? Perl's Magical Autoconverting Wondervariable. I introduced the abbreviation earlier in the post, while you were busy having a blind rage about me resurrecting my scheme to deprecate the scalar sigil. The draw of the PMAW is why we're all here (rather than outside in the heat, tinkering with our regenerative braking systems) in the first place. -- David Nicol 816.235.1187 Perl was born in downtown Hell! -- Matt Youell
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
Matt Youell wrote: Is there a standard? No. Does there need to be one? I don't see a need for it. What's wrong with something simple, like saying all classes have an implicit new() method that is overloadable? Is this really *that* complicated? Maybe I'm not getting the Big Picture. The problem is, where does this rule belong? Right now, the constructor is called Cnew is a cultural standard so strong that at least one highlighting code editor highlights it in Perl mode. Is this enforced? No. Why? What if you want multiple constructors with redundant code, et cetera -- there is flexibility. Selecting a group of standard class methods and insisting that a CPAN upload be compliant with the standard, more restrictive than What The Language Lets You Get Awat With -- that makes sense to me. Perhaps the maintainers of Class::* could converge on a standard API, including a standard name for what the class mechanism in use in a particular instance is. But would the game be worth the candle? -- David Nicol 816.235.1187
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
Matt Youell wrote: MI thing, but now it's sounding like a constructor bubbling scheme, like Ah, yes. I've had to deal with that problem several times in the past. The terminology was new to me, however. Has there been a proposed solution? Thanks, - Matt What's the problem again? I mean, really, any OO shop has it's local culture, of what the base classes are and so forth. We've got multiple possible working off-the-shelf inheritance systems that offer various levels of abstraction and various features. Is there a standard? No. Does there need to be one? I don't see a need for it. For introducing New Syntax For Perl Six, which is a game that is Really Tiresome Since The Suggestions Get Ignored Anyway, what do we want? A superset of all features available in all OO languages, with a clearly defined extension declaration system? Rewriting rules for new syntax, and a standardized shorthand that starts one off ahead of where one must now start off? -- David Nicol 816.235.1187 It's widely known that the 'F' in RTFM is silent. -- Olie
Re: Anyone actually experienced with object inheritance?
Hong Zhang wrote:
Say if you want Thread can be easily inserted into LinkedList,
you can write
public Thread extends Object implements Node {
...
}
or
public Thread extends Object, Node {
...
}
and don't bother to implement classic linked list node.
Hong
You could use a hasa relation as well, as long as the node object
has a link to the owner.
package ListableObject;
sub new {
my $O = new Object;
$O-addfield(node = Node::new({Ownedby= $O}));# or something like this
};
It would of course be easier to get wrong.
--
David Nicol 816.235.1187
It's widely known that the 'F' in RTFM is silent. -- Olie
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
Matt Youell wrote: Forgive my woeful ignorance Could someone define data aggregation by inheritance? From John's original mention I thought this was some oblique MI thing, but now it's sounding like a constructor bubbling scheme, like in C++, etc. I understood it to mean automatic constructor bubbling. Which is something all the various Class::Whatever modules provide, AFAIK. -- David Nicol 816.235.1187 And the cow threw up seven times, and said: Say it now and say it loud, I'm a cow and I am proud.
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
John Porter wrote:
Michael G Schwern wrote:
Give me data aggregation by inheritance
Oooh, now that would be useful.
Of course it would. That's why nearly every OO language (beside Perl)
has it.
package circular_list_node;
... # defines how the list_nodes do their quaint folk dances
package some_listable_datum;
@ISA = qw circular_list_node ;
sub new{
my $self = new circular_list_node;
...
That isn't data aggregation by inheritance?
--
David Nicol 816.235.1187
And the cow threw up seven times, and said:
Say it now and say it loud, I'm a cow and I am proud.
Re: Multiple classifications of an object
Garrett Goebel wrote: So every class has a vtable, which is a copy of its parents except for what is overridden within it, and a instance that wishes to deviate could make a local copy of its vtable and twiddle it. Why not just fall back to the ancestor(s) unless it provides its own. What good does flattening an instance accomplish that polymorphism doesn't? Dan S. says Vtables are much lower level than this but, what if they are used for method dispatch, the way C++ virtual methods work, on all objects, not just builtins? I thought that was the whole point of them. It is an internals issue though and anyone without a running system should shut up (which is, everyone but Simon Cozens at this point.) To respond to GG's question, it is a considered memory vs. speed tradeoff. The question is, is making the copy better than having an override list which is consulted before the dispatch. Which is an internals question too. Language list is for determining what the programmer interface looks like.
'We already have a sub keyword'
David Whipp wrote:
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 ;-).
David Whipp intoned, most echoey:
We already have a sub keyword; and one of its parameters is
the name of the function.
Yet when used to define a named function, sub does not appear to
return anything.
$Ref_to_foo = sub foo($$){print $_[0] was followed by $_[1]\n};
does not work, it must be written
$Ref_to_foo = *foo = sub ($$){print $_[0] was followed by $_[1]\n};
Yet another minor candidate for regularization.
--
David Nicol 816.235.1187
ftp://ftp.microsoft.com/developr/interix/gpl.txt
Re: Multiple classifications of an object
John Porter wrote: without any kind of data aggregation, as in most other OO languages, what else is there to inheritance but late binding of methods? Early checking of method name validity? -- David Nicol 816.235.1187 ftp://ftp.microsoft.com/developr/interix/gpl.txt
Re: Multiple classifications of an object (the ::: placeholder)
Dan Sugalski wrote:
Basically my preference, if we're going with a per-object .ISA with no
class ISA fallback, is for each object to be independent and not affect any
other object when its properties are messed with.
I'm straining to understand the subtle distinction btwn per-object ISA and
Creating A Class That Holds Only One Object And Blessing This Object Into
It
I think it has to do with what the object claims to be when queried.
The desired semantics could be obtained easily enough by relaxing the
isa() function's matching rules, and regularizing the names of the
extended classes.
$simplefoo = bless {}, 'foo';
$extendedfoo = {};
bless $extendedfoo, foo:::$extendedfoo; # yes, that's 3 colons
and rewrite isa() to return true if asked
$extendedfoo-isa('foo')?
Or maybe this magically occurs whenever you use a method of an instance
as an l-value?
*{$simplefoo.bark} = sub {print Shh. I have been hushed!\n};
(l-value syntax open for major rewriting)
The idea would be, by assigning to an instance's method, instead of
altering the
method for the whole class, you would copy the instance's vtable into a new
vtable, override the method entry in question. You could make another
equally skewed foo with the
bless (reference, blessed-reference)
syntax of bless, even if ref($skewedfoo) still returns 'foo' instead of
something
like 'foo:::0x80f5934'
--
David Nicol 816.235.1187
ftp://ftp.microsoft.com/developr/interix/gpl.txt
making variables or containers read-only
Mark J. Reed wrote: If I wanted to make a variable read-only, I would expect to do it by setting the read-only attribute on that variable, which I would further expect to do the same way I would set any other attribute at any other time. Orthogonality has its good points, even in Perl; you just shouldn't be afraid to veer off diagonally when it makes sense. I don't think close(var) makes sense. seal has been suggested. Currently nothing in perl enforces access besides lexical visibility rules. Lexical visibility makes it possible to create read-only types by tieing to classes where STORE is a no-op. Defining a read-only implementation is trivial. I'm experiencing Warnock's dilemma WRT my suggestion that the make-read-only operation, whatever it looks like, might return a coderef which could be run to unseal the variable/container, or might get not stored, indicating that the item is permanently read-only and can be optimized as such. As for read-only being an attribute, if attributes are compiler hints, how do we set something to be read-only then? And we can't unseal a r-o item without making a copy of it. -- David Nicol 816.235.1187 Many wealthy people are little more than janitors of their possessions. --Frank Lloyd Wright, architect (1867-1959)
Re: Embrace polymorphic builtins, for they are cool.
Now look at eval. When acting on a string, it compiles and runs it as code. When acting on a block, it traps any errors and prevents dying. You may be able to come up with some weak analogies between the two, but they're two different functionalities. i have nothing to add. you obviosly want to scrap eval-block for try. This is turning into a religious dispute. Different object, same action: ok Different object, different action: not ok close (IO) # closes an open stream, returns # true on success or false on failure, # sets $! on failure close (\$) # overwrites the ASSIGN method of the overly elaborate explaination snipped close. Closing a filehandle means you're no longer going to read and/or write to it (depending on how it was opened). Closing a variable means you're no longer going to write to it... but reading is ok. The analogy is there, but its not a particularly strong or obvious one, and there's the jarring difference that you can no longer read from a closed filehandle, but you can read from a closed variable. You've got to be careful with polymorphism and ensure that you've got strong analogous action in all cases. Not just because its clever or you like the name. This is not to say we shouldn't have polymorphic built-ins (we already have more than you might think) but they must be chosen with extreme care. So I take it that you object wholeheartedly to C++ Streams libraries using and for IO operations because even though there is never any confusion, since bitshifting file handles is silly, it is in your terms WRONG? I think the limited set of objects that close(filehandle) is defined on makes it a perfect candidate for overloading with something completely different, just like the bitshift operators were overloaded for file ops in C++. I will continue to use it as described in discussion of How Capabilities Might Work In This Context until whacked over the head with a better keyword. Some more counter-examples... un/pack() on a filehandle could compress and decompress the file! It might be perfectly logical if un/pack didn't already do something completely different. Some good examples... delete/exists work on both arrays and hashes. delete() completely removes an array/hash element, exists() checks to see if an array/hash element has been populated (even if its undefined). The details might start to diverge a bit, but the basic meaning doesn't change. Homogeneous operators are potentially confusing (just because English has homonyms doesn't mean its not confusing) but not all polymorphic functions are homonyms. Find the ones which retain their basic meaning across all their objects, those are the good ones. PS delete() and exists() are also polymorphic, as is reverse(), chomp(), chop(), goto() and die(). There are probably more, but I can't think of them, probably because they mesh so well we don't even think about it. You could consider functions which have default arguments as polymorphic, then there's lots and lots of polymorphism in Perl. But I digress. Great! So you agree that we need better polymorphism in prototype and dispatch of user-defined routines? -- David Nicol 816.235.1187 Signature closed for repaving
more slots in the glob, 'but', Re: 'is' and action at a distance
I had imagined the way things like $R = 0 but true would work is that the scalar would grow another couple of slots in it, which would be the conversion operators. Everything defaults to how it has worked in the past, but could be overridden. So the boolean value starts as default converter until it gets accessed, then the language figures out what the boolean value is and caches it until an assignment happens and clears the boolean (and other autoconverted) value. That allows booleans to get set to values other than perl 5 truth of the scalar contents. It also meshes well with alternate v-tables, although profusion of what can be done by multiplying the number of vtables and what is better done with a per-access check is a good case for some modeling and some algebra and some benchmarking on various platforms: Maybe we could have a slider in the performance tuning widget. But if the additional slots in the scalar are cleared at assignment, that is a very different sort of assignment to an item than a property such as will only hold integers or will only hold dogs or dog subtypes which does not vary and can be used by the compiler. I propose: use but to override the default intrascalarvalue conversions, such as $line = readline but true; or even better, $line = readline; $line = $line but boolean(is_section_end_markerp($line)); Although this second use begs the question, Why bother with combining types if you're going to override them? Maybe overriding is not such a good idea anyway? Are there really that many situations where having Truth autogenerated from number/text-string isn't confusing and bug-prone already? reserve is for compiler optimization hints: my $line is text; I have not read the earlier discussion in the thread I am adding this posting to, or the essays referred to by them. The above is/but distinction is something that I believe needs to be made, by any names, because without it there will be confusions
Re: tasty db data
Dan Sugalski wrote:
At 04:39 PM 6/12/2001 -0500, David L. Nicol wrote:
I appear to be suggesting that deferability be an add-on that causes some
rewriting to support itself, rather than an optimization to parse away
bothering with silly calculations that we will never see the results of.
That's fine, and we may end up going that route. I'd rather not, as it
either shoots the optimizer badly, or requires the generated bytecode to be
a lot more complex. (Basically requiring two code paths depending on
whether data's active or not)
If we know at compile time we don't have to generate the other one.
If the bytecode is late-rewritable we can put off generating the second
code path until we need it, although the pass to see if it is needed or
not still has to go in there.
I imagine the tasty module would allow any deferred datum to be designated
as from any of a number of mouth collections, each one associated with
a separate expensive data source -- i.e. SQL server -- they would have to
be marked as to if they had been swallowed, which means that expressions
containing them should be evaluated instead of further deferred.
Are deadlocks possible? Deadlock avoidance strategy would need to
be used if they are. When in doubt, swallow immediately.
Got to make the programmers worry about _something!_
Sure, but why this?
I don't understand the situation you want to optimize. I think a
programmer
who would write:
sub loiter_after_generating_a_value {
my scalar retval = do something_that_generates_a_value;
do_something_without_side_effects;
do_something_else_without_side_effects;
return retval;
}
deserves to have their code run slower than someone else who comments out
the two something elses or sticks a goto in to hop over them.
You are saying you want to support the situation where something_else used
to have an important side effect, but doesn't any more, and in that case
the compiler can just skip it?
Re: Multi-dimensional arrays and relational db data
Dan Sugalski wrote: I'm still trying to formulate a good set of rules on how I think active data should perform under optimization to pass on to Larry. Dan How about, Active data doesn't get optimized. Static data doesn't care if you access ir or not, and most data is static, is not burdened with magic that makes it send home a post card every time someone looks at it. If you're a camp counselor and one of your wards is such a neurotic, it is incumbent upon you to make a daily run to the post office. If all your kids are content to write postcards on tuesdays, you just have to go to the post office on tuesdays. -- David Nicol 816.235.1187 Signature closed for repaving
Re: Coupla Questions
Damian Conway wrote:
Graham wrote:
Now I may be wrong here, but I thought I remembered something about
.foo being the same as $_.foo
It's certainly a possibility.
In which case you could do
for (%database.$accountnumber) {
.interestearned += $interestrate * .balance
}
Larry doesn't favour using Cfor thus, beause it introduces a sly
list context. That argument convinced me.
But there might well be another keyword for the same idea and that might tie
into switch statements too.
Damian
The data working group settled on %_ for this, as I recall it was
a consensus without objection.
--
David Nicol 816.235.1187
Signature closed for repaving
deferred FETCH called tasty
I think I'm repeating what has been said already but here goes.
After sending this I'm breaking for a sandwich. :)
for database data, the problem domain is limited sensibly. We want
to defer as many lookups as possible, so they can be sent as a bunch
rather than sent one by one, and we would like this action to be hidden.
We can't simply tie in the perl5 sense, because tiedness does not persist
accross assignment. So we need to either modify Assignment to allow more
than
value to get assigned, or we need to pass around something -- a magic
coderef,
perhaps -- that can hold a deferred expression -- and define certain
criteria
that trigger the expedition of the deferred expressions. The unjamming.
We only mark the FETCHes that are worth deferring as special. We do this
by having a new kind of internal SV that tastes like an SV but really
refers
to a coderef, which will return the SV when it is run.
Perl5 scalars can hold codrefs, but the programmer needs to explicitly run
them.
All changes to data are done with The Assignment Operator, that
gives us one common point to twiddle when we twiddle things.
Assignment knows about these, umm, tasty variables and any expression
involving
a tasty returns a tasty -- another deferment -- instead of a scalar. Since
this is done by Assignment, the only way a side-effect could escape is if
the side-effect does not use the Assign interface.
so, a tasty variable holds a coderef which will return a scalar. The
implications
of Cuse tasty would be, all expressions which might have a tasty in them
get expanded to something like:
EXPR rewrites to: ( has_tasty(EXPR) ? bless(sub { EXPR },tasty) : EXPR )
The other side of the coin is a swallowing context, (Simon C. will refer
to
this as a gag reflex) which is, for database purposes, something that
triggers
all the deferred keys getting rolled up into a SQL query and the values
returned
inserted into the appropriate tasty vars so they become normal scalars
again,
either immediately or on next reference to them. I guess every tasty knows
what it is waiting for, and as soon as that data arrives a flag would be
set.
Conditions are swallowing contexts, as are output statements. Reaching a
tasty depth limit might also be a swallowing context.
Hope this has helped. I'm definitely going over to the Yello Sub on Main
street
and ordering a torpedo now.
Daniel S. Wilkerson wrote:
I think you could only delay function calls automatically like this if you
could ensure that they are truely functional. That is, their output must
depend only on the arugments given and must have no mutation
side-effects. It seems to me that this is hard to guarantee in Perl, even
for the compiler.
a compilation mode in which all expensive accesses get deferred until
--
David Nicol
The feet that kick out the jams must be defined.
tasty db data
Since I just proposed a new paradigm I'll try to apply it, before
darting down the hill and getting my sandwich.
Dan Sugalski wrote:
David L. Nicol [made an akward metaphor with data as summer campers]
That's less easy than you might think. Quick:
$bar = bar();
is $bar active or not?
$bar is active, as in perl's active data by default. It would be
tasty only if bar() returned a tasty value.
Or:
my $foo;
if ($bar) {
tie $foo, Bar;
}
how about then?
use of $bar as a conditional would trigger swallowing which would mean,
from the point of view of the mouth which held $bar in deferment, time
to compose and submit and wait for the large SQL query.
This is a considerably less simple problem than you (and *definitely* I)
might like. :(
I appear to be suggesting that deferability be an add-on that causes some
rewriting to support itself, rather than an optimization to parse away
bothering with silly calculations that we will never see the results of.
Got to make the programmers worry about _something!_
--
David Nicol 816.235.1187
It's all a crossword puzzle to me
Embrace polymorphic builtins, for they are cool.
Coming to Perl 5 from a C++ background, I was greatly
disappointed, while writing a persistent object base
class and consulting my new, flat-lying Blue Camel (Second
edition, this was 1996), that the following kind of thing
did not do what I wanted:
sub argle($){
print One argle: $_[0]\n;
}
sub argle($$){
print Two argles: $_[0],$_[1]\n;
}
sub argle($$$@){
print join(',',
Many argles: $_[0],
@_[1..($#_-1)],
$_[$#_]\n
);
}
It turned out, on inspection, that the prototyping mechanism
was for syntactic ease -- leave out the occasional sigil -- and
occasional error checking -- rather than for multiple dispatch, as
it is in C++. If you want multiple dispatch, you need to either
write a prototype that will accept all possible valid arguments, then
select from them after the named function has been called, or
somehow wrap your data modeling around some sort of interface object
which can have the appropriate package methods associated with it,
which really doesn't gain you much:
{
#LoggingObjects automatically subclass based on argument number:
my $LoggingObject = new LoggingObject qw/argle bargle whoosh/;
$LoggingObject-Print();# Correct one/two/many distinction!
}
Therefore, last year, when the perl 6 community suggestion period was
announced, I made sure to write a RFC describing a type-based
multiple dispatch mechanism.
But I'm digressing. What I want to talk about is overloaded builtins.
I recently suggested that Cclose be overloaded to make its argument,
when its argument is not a filehandle, become read-only. An objection
was made to this, on the grounds that homonymous operators are confusing,
with eval block and eval string being given as an example of something
that is confusing.
This post is intended to be a response to that objection.
Natural language contains many homonyms. This is rarely, outside of
dramatic plots, a problem, as there are other indicators, up to and
including requests for clarification, but generally context, to
guide us human beings as we apply our common sense to the great
questions of What Is Fair and What Is Right without taking wrong turns
or digressing into discussions of propagandistic trends in modern
journalism while dividing chocolate cake evenly among party guests.
Okay?
Ceval (string/block) is but one. Crequire (file name / version number)
is
another. Cdo might be considered another. There is discussion of
overloading
Clength(@) to do what beginners expect.
Those are the only ones we have right now. I am sure that the people
reading
this are about evenly divided between thinking Basta, no mas! and
agreeing
with what I am about to say.
Just as Websters has multiple entries for some words, with completely
different meanings, it is all right for a programming language to have
different meanings. Commonly used function names vary between different
programs, for instance.
I believe that multiple dispatch based on argument type is an important
feature of a general purpose programming language. With this in mind,
what better way to introduce the concept to the beginning programmer than
to have built-ins that do multiple dispatch based on argument type?
close (IO) # closes an open stream, returns
# true on success or false on failure,
# sets $! on failure
close (\$) # overwrites the ASSIGN method of the
# referenced object or container with
# a placeholder that inherits from
# Cwarn; returns a CODEREF that will
# cause, on run, the referent's ASSIGN
# method to be returned to the current
# method, or undef on failure. Sets
# $! on failure, to, for instance,
# $_[0]-NAME already read-only
Multiple dispatch based on argument type, gentlemen. C++ has it, and
C++ programmers miss it when writing in other languages. Few other
languages
dare to include argument types into the symbolic identifiers for their
code entry points.
In the land of More Than One Way, it is surprising that this important
way -- the mechanism behind, for example, the double-angle-bracket C++
streams library output syntax -- early-binding multiple dispatch based
on known argument type -- is missing.
--
David Nicol 816.235.1187
Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
Vijay Singh wrote: Just how much $foo can dance on the head of a dot operator The current Annals Of Improbable Research (http://www.improb.com) has a piece on applying modern physics to the age-old question, you know, about the boogieing angels. -- David Nicol 816.235.1187 Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
[EMAIL PROTECTED] wrote: You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ Taking lazy as far as we can, has anyone been thinking about a compilation mode in which all expensive accesses get deferred until there is a decision to be made? I know some functional languages (and Algol 68?) do this, when they can -- just stack up Things To Do until an output or a decision is required, then figure out just what is needed to generate or make the output/decision. How would this work in perl? We'd have to stop relying on side effects and well defined short-circuiting, for one -- or would we?
Re: Coupla Questions
Damian Conway wrote:
Graham asked:
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This is intended. I'm not sure Larry's decided the exact mechanism yet.
Hopefully, we'll get a with operator and everything:
with %database.$accountnumber {
.interestearned += $interestrate * .balance
}
anything short of that, in my opinion, is merely trading old ugly for
new ugly.
it is perl5 but...
~/perl/perl-5.7.1$ ./perl -le '%a=(1..10); print it; exists $a{1} and print
it'
2
--
David Nicol 816.235.1187
The toad doesn't know it has ten toes.
Re: 1 until defined(getvalue()); return $^d;
John Porter wrote:
Huh? What did I say?::
you said there would be no performance hit in rewriting
defined|exists to store the pointer to the thing that was
found to be defined or exist somewhere.
After looking at the source code for what might have been the
wrong part of /usr/src/perl/perl-5.6.1/Perlapi.c (or something
like that) I determined that adding this feature would cause
two writes to static variables per function invocation that found
something and one or perhaps zero writes per invocation that found
nothing.
These writes would dirty a code page, which might result in a stall
as the modification is propagated up from the CPU.
Since the rest of the variables local to that routine are declared
as registers, the routine (at least the one I looked at) currently
uses only the stack and registers, and very little of the stack.
There would be a slight performance hit, caused by the two extra
assignments. (one to zero the pointer on entry, one to set it on found.)
pp_exists, found in pp.c, is a wrapper for special cases
involving subroutines -- no comment on what
if (PL_op-op_private OPpEXISTS_SUB) {
is testing for --
and then is a wrapper for the three kinds of container lookup,
hv_exists_ent, av_exists, and avhv_exists_ent
I examined hv_exists_ent. Its arguments are
HV *hv, SV *keysv, U32 hash
which appear to be sufficent to describe the location of
an item, directly.
something like
struct IT_EXISTS_STASH_TYPE {
HV *hv;
SV *sv;
U32 hash;
}
should be sufficient for the
static IT_EXISTS_STASH_TYPE IT_exists;
definition which would have to appear somewhere.
I really don't know enough about perl 5 internals to go on; I
am certain that this feature is a no-brainer though and will try
to refrain from responding further about it
--
David Nicol 816.235.1187
Re: 1 until defined(getvalue()); return $^d;
John Porter wrote: David L. Nicol wrote: I really don't know enough about perl 5 internals to go on; I am certain that this feature is a no-brainer though Besides the fact which, how it might be added to perl5 does not say much about how it might be implemented in perl6. And it is perl6 we're talking about, right? Yes! Another reason to NOT write and submit a patch.
Re: Properties and stricture and capabilities
Michael G Schwern wrote: Symbol table manipulation will work as long as your mucking about doesn't alter the strict class's signature. ie. you can shove a code ref onto the symbol table as long as a stub for that method was defined at compile time. a read-only hash of any kind makes it more safe we could overload Cclose to make a hash read-only and return a coderef that can be run to make it r/w again (aka the capability) That would prevent further shoving of anything onto the symbol table without proper authorization as defined by holding the capability.
Re: 1 until defined(getvalue()); return $^d;
Since this thread made it into this week's Official Perl6 Summary,
here goes a defense of Cit as a shorthand for the thing that last
had Cdefined or Cexists queried of it.
It (by which I mean Cit, isn't this fun) would be a side-effect of
non-autovivifying queries. It allows redundant descents into arbitrarily
complex data structures to be optimized out.
A new bareword is too heavy an invasion of this idea into the language:
a new LNV is preferable. Cuse English could alias $^d and $^e to
C$DEFINED_TARGET and C$EXISTS_TARGET, respectively. Autoviv would be
deferred until ond of them gets assigned to.
Damian Conway wrote:
David wrote:
defined $thing and return $thing
Why not use the existing mechanism? Namely:
return $_ for grep{defined} $thing;
although meeting the specified criteria of looking $thing up
once, this is a confusing hack that might not save any cycles.
Setting up the Cfor construct and reassigning C$_ might be
longer than referring to a defined-specific magic variable.
which also scales rather nicely:
return $_ for grep{defined} $thing, $otherthing, $somethingelse;
This does not help in the case of a long, unrolled routine which is to
return the first sensible parse of something. Although with a
short-circuiting
grep this would work, and be a nice controlling abstraction too.
As for the original problem of:
1 until defined(getvalue()); return it;
You can already write:
1 until defined($_=getvalue()); return $_;
which doesn't seem a huge extra burden.
I want the assignment done behind-the-scenes, rather
than by explicit programmer action.
I hereby revise my proposal from a bareword to a Line Noise Variable,
so that this interesting but rarely used feature, like other similar ones,
for instance $?.
Re: 1 until defined(getvalue()); return $^d;
Simon Cozens wrote: Please don't try defending it or $^d in terms of efficiency; any variable that Perl has to keep track of magically takes a performance hit. Remember $`, $', and $? No, this datum is already known by defined() and exists() all I am suggesting is a name for the Perl API name for it. Well, it isn't currently in 5.6.1's bool Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen) function (contrary to what John Porter said) but adding it, as extended defined/exists that Only Gets Called When It Immediately And Obviously Precedes Use Of The Magic Variable, would save the later lookups. This is a Little thing that can just be thrown in and is nothing more than that. Making $', $`, and $ lexically scoped too could solve their performance hit issues too. They're convenient.
Re: Coupla Questions
Damian Conway wrote:
$ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
Re: Properties and stricture
Me wrote: [strict typing] Not a negative, but realize that many people find it of less value than the annoyances it brings with it (myself included) Michael, I don't know which is more impressive; the fact that use of a strictly typed language implies that a copy of you would land on the poor unsuspecting programmer's desk, or that you are self-deprecating enough to acknowledge that this would probably be an annoyance (at least in the first seconds or so prior to recognition of the rather cool magic involved). Me: Oh please. If it makes no sense one way, reparse. I had no trouble at all binding Michael's myself into many people and neither did you, unless someone has recently lobotomized you with a guitar pick. OTOH, you may have been making a point about strict syntax-based parsing, in which case I may be in a minority in misperceiving your post as the worst case of smartassery I've seen this month.
closed property ((was Re: $foo.Foun ((was Re: Properties and stricture
Me wrote:
I.Found your notion of a sealed off namespace
intriguing. I have no idea what it meant just yet;
I'm going to go read and think about it now.
I'll pitch some syntax:
# prevent modification to %reflexive:: like so:
package reflexive is closed;
# allow it like so:
%reflexive:: is not closed;
# determine its status like so:
unless (is closed %reflexive::) {
# add the subs
...
The above is modulo a new syntax for referring to a package's
symbol table.
What would be the limits on who or what would be allowed to open
a regular hash, that was made read-only by giving it a closed
property? This would need to be well defined. Possibly an
openswith property could be taken from a hash, before it is closed,
which could be invoked to open it again, by accessing the open
property while it is open.
my %SMERSH_agent_identities = sreadfile('identities/SMERSH.sd');
swallow(my $agent_list_mod_key = (is open %SMERSH_agent_identities);)
%SMERSH_agent_identities is closed;
Mallory can't defame a good agent by modifying this list of bad
agents without setting it to not closed, he can't do that without
getting the key, and the key has been swallowed (whatever that means.)
Even more compact would be the setting to closed returning the capability.
package reflexive;
# prevent modification to %reflexive:: like so:
my $opener = (%reflexive:: is closed);
# re-allow modification like so:
$opener;
--
David Nicol 816.235.1187
Keep Dan Sugalski away from my stuffed animals
Re: $foo.Foun (was Re: Properties and stricture)
Me wrote:
Question 1:
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
Right?
it is already detectable. from perldoc perlref:
Perl will raise an exception if you try to access
nonexistent fields. To avoid inconsistencies, always use
the fields::phash() function provided by the fields
pragma.
Although other discussion in the thread indicates that we may
be confusing properties and member fields.
as I understand it, .foo has been proposed to replace -{foo} and
we're talking about fields, not properties.
Property access has got to be something else. Last year's code pitched
to the perl6-data list generally used a colon for that; use of is as the
property assignment operator invites and suggests
$foun_status_of_foo = (is $foo foun);
to access the status of the foun property of foo, should such exist and be
defined
et cetera. Maybe there will be a distinction between notexist and notdef.
I know the
SQL people want an explicit unknown value.
And we're in blue sky territory for the stricture.
--
David Nicol 816.235.1187
Keep Dan Sugalski away from my stuffed animals
Re: Stacks, registers, and bytecode. (Oh, my!)
Hong Zhang wrote: based scheme itself. For example, an local variable is not used by any of the code, however an eval($s) may refer to it. So should optimizer eliminate the local? Hong mark blocks that have closures in them, in those, you can't throw any locals out. Otherwise, you can throw them out if youre not going to use them -- David Nicol 816.235.1187 [EMAIL PROTECTED] Obi-Wan taught me mysticism -- Luke Housego
my $howmany=wantarray; while($howmany--){push @R,onemore};
having wantarray return the number of items needed, or -1 for all of them, would work very nicely for user-written partial returners. Did anyone RFC that? -- David Nicol 816.235.1187 [EMAIL PROTECTED] DWIM before autovivify unless strict
Re: what I meant about hungarian notation
Me wrote:
It was an informal finger-in-the-wind thing I sent to
a perl beginners list. Nothing special, just a quick
survey.
http://www.self-reference.com/cgi-bin/perl6plurals.pl
I certainly do not see that many people on the
list agreeing with you.
And that means I should be quiet? I hope not.
what I have written in the comments blank:
Suggestion:
retain complete perl5 syntax with the following
DWIM exceptions defined:
Accesses that would, in array context, currently amount
to a single-length slice, in an scalar context, become
that-value-but-true, for string and logic accesses, and
give a non-quietable (fatal, even?) warning on use in a
numeric (but not assignment for later use) context. That
takes care of
@containername[{key-expression}]
and
@containername{{key-expression}}
Also, redefine the wrong kind of brackets to
correct to the right kind of brackets instead
of autovivifying the other kind of container, when
the other kind of container does not exist already.
Which is pretty much exactly what got suggested later 5/14
Later, the first person objective pronoun intoned:
Suggestion: deprecate {}.
The benefit is saving {} for alternative/future perl use,
and the fact that beginners prefer [] as the subscript
parens for both arrays and hashes by a more than 2
to 1 margin.
One cost is that:
$foo[$bar]
would be syntactically ambiguous. The compiler
would know enough to deal, but humans would not.
and strict braces would kill you if you use the wrong
one, instead of letting you slide
Suggestion: deprecate both % and {}.
Benefits are both of the above.
Costs are numerous and deep.
how about flexiblize instead of deprecate?
how about keeping them but deprecate allowing by-number and by-name
to share the same glob?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
# die smiling;
1 until defined(getvalue()); return it;
while pseudocoding something I realized that it would be really cool if there was another magical default shelf, like $_ or _ but subtly different, that stores, if lexically used, the object of the most recent defined or exists -- or maybe even the most recently referred to scalar, just the way it works in English. it would change much more often than $_ does. -- David Nicol 816.235.1187 [EMAIL PROTECTED] # die smiling;
Re: 1 until defined(getvalue()); return it;
Michael G Schwern wrote: That aside, could you put together a code example of what this wins? some expressiveness is gained, and a creation of a temporary variable can be avoided. ... defined $thing and return $thing ... is my working idiom for checking which case makes sense and returning the first hit. when $thing is a complex expression, a temporary variable must be explicitly assigned. it holds the place in my pseudocode. The pseudocode is for a source filter so I was thinking syntax optimizaitons...
Re: 1 until defined(getvalue()); return it;
Buddha Buck wrote: Why is [...] better than 1 until defined($foo=getvalue()); return $foo; small incremental improvement to [read|writ]ability writability: one less thing to write one less variable name to have to remember not to collide with readability: keyword it means look at very recent code, instead of starting at the top of the block and reading down to find what $foo is (trivially solvable by reading backwards...) when they're all calls to the same function it doesn't help, but if they are possible return points from a long routine, it would be nice to formalize the object-of-defined construction. It would not be difficult to implement. Would it? the it.pm module would export it as a function that returns whatever is in $nicol::it::itstash and invoke a source filter that replaces the last instance of exists or defined before an occurance of it with an alternate implementation that sets the stash. -- David Nicol 816.235.1187 [EMAIL PROTECTED] # die smiling;
Re: 1 until defined(getvalue()); return it;
Simon Cozens wrote:
On Wed, May 30, 2001 at 06:48:53PM +0100, Simon Cozens wrote:
*Nice*, but potentially a bugger to implement.
Of course, 'sub it():lvalue{$_}' gets you *most* of the benefit.
um, no.
foreach(@foods){
# okay, I'll try...
exists %grocery_stock_codes{$_} and buy it
};
I want to buy the code, as listed in the code table, not the food-by-name.
$_ will still be Granola when buy($) wants IPC_3435_5252_j
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
DWIM before autovivify unless strict
Re: what I meant about hungarian notation
John Porter wrote: Larry Wall wrote: : do you think conflating @ and % would be a perl6 design win? Nope, I still think most ordinary people want different operators for strings than for numbers. Different operators, conflated data type. That's what we have for scalars already. Makes sense to have it for containers indexed by scalar as well. add an explicit accuracy limit @container : accuracy 0.01; and you've got a language where $container[2/3] is guaranteed to access the same slot as $container[.6668] Now that's what I call going up to eleven! -- David Nicol 816.235.1187 [EMAIL PROTECTED] die 'smiling' if $still_debugging;
Re: what I meant about hungarian notation
David Grove wrote:
...
This is frightening me too. I really don't like the thought of
$i = 1.0;
$i += 0.1 if $INC;
$i .= Foo, Inc.;
(or more specifically a one line version that converts several times for a
single statement)
becoming
my str $i = 1.0;
if($INC) {
$i.asFloat += 0.1;
}
$i.asString .= Foo, Inc.;
We appear to be moving in that direction, trading programmer convenience
with politically correct verbosity.
that isn't what I suggested.
With references-in-scalars, the p5 status quo, there's no hint at all what
$R refers to. It might not be a reference, but it might be a genuine
scalar, holidng a number or some text. You can't deny this is a confusing
state of affairs. I have no idea if
print $R
is going to give me a reasonable output or some internals-debugging noise.
We even have the Cref operator to help us with this problem
sub deref($);
sub deref($){ref $_[0] ? deref $$_[0] : $_[0]);
print deref $R;
So why not, since the $ preceding the name of a reference doesn't do
a whole lot, let's deprecate it?
1 @$R
2 @{$R}
3 @{R}
4 @{R}
5 @{'R'}
6 @R
How much difference does it make, in situations where these
are all defined, 6/3 starts binding to 4 rather than 5?
You know, we have it (undecorated variablkes) already, if we don't mind
always using
curlies around variable names, we can create subroutines to return
references for
each and every variable.
my Dog spot;
could, in p5 terms, be short for something like this:
{
my $obj = new Dog;
sub spot { return $obj }
};
This is the exact same discussion from October 2000. :)
Re: what I meant about hungarian notation
Bart Lateur wrote: So what you're saying is that references aren't really scalars, but their own type. Thus they need their own prefix. But we've sort of run out of possible prefixes. that is my interpretation of the p4-p5 decision to make references fit within the scalar type; which itself echoes the notsbolts availability of memory addresses as integer types. Which cause[s|d] so much confusion when porting 32-bit code to 64-bit architecture If perl6 variable decorations switch from Part-Of-The-Name to type casts, pretending that a reference is a string continues to make the same amount of sense as pretending that a pointer to a structure is an integer. It works, but it's troublesome. -- David Nicol 816.235.1187 [EMAIL PROTECTED] all your base are belong to us, Will Robinson
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: Perl is a highly dynamic language An object with exactly one and only one method doesn't sound that dynamic to me. nonsense! It's got accessor methods too, for everyone who wanted to magicalize $index and so forth. Remeber those threads from last year?
Re: Apoc2 - STDIN concerns ::::: new mascot?
Larry Wall wrote: there seems to be a shortage of three-humped camels. At last! the unencumbered image for the mascot! Could O'Reilly really claim a three-humped camel was an image of a camel, with a straight face?
Re: Apoc2 - STDIN concerns
Larry Wall wrote:
Syntactically speaking it's too ambiguous to have both a unary and a
bracketing .
Cool. Do we get a operator to use as an l-value, instead of print?
$log = join localtime, 'difficult cramigudgeo';
It's possible we're thinking of iterators wrong here. Perhaps
iterators should typically be stored in @iter, not $iter. Then it's
pretty obvious that
for (@cases) { }
iterates, because it's in a list context.
but it is not obvious that @cases is an iterator. Unfortunately we don't
have an infinite supply of line-noise to arbitrarily extend this optimized
hungarian notation ($@%)
for Cfor ($cases){...} to do anything interesting, there's something
special about $cases, making iterator-in-scalar more visible than
iterator-in-array,
where it could easily be mistaken for a container instead of a generator.
I think iterator magic
always works in list context, and never in scalar.
okay, that disambiguates copy and retrieve handily, guess I'll delete the
five unsent e-mails eulogizing angles now
Re: Apoc2 - STDIN concerns
Nathan Wiger wrote: I think Uri's qh() suggestion is the cleanest: me too And it would make hash declarations cleaner: %hash = qh( foo bar jim = 'bob' var ); Plus maybe even a pragma to set the default value: use default hashval = 'closed'; ... Looks like a job for a new LineNoiseVar. is $% anything yet? format_page_number HANDLE EXPR $FORMAT_PAGE_NUMBER $% The current page number of the currently selected output channel. (Mnemonic: % is page number in nroff.) how about $% is that if we are using, umm, the format module, or the $QH_DEFAULT_VALUE if we aren't. Or go to $%%. Additionally, the qh syntax could very easily become a packed-structure sytnax.
Re: Apoc2 - Context and variables
Jonathan Scott Duff wrote: (*%a, %b) = (%c,%d);# %a slurps, %b gets nothing (%a, *%b) = (%c,%d);# %a = %c, %b gets the rest I'm sure your imaginations can twiddle the cardinality knob appropriate for generalization :-) -Scott so if you don't know exactly what the conext is going to be can you defer it with a continuation operator? @split_me_later = ?(%f,%g,%h); ... (%a,*%b) = @split_me_later
Re: Apo2: \Q ambiguity
Johan Vromans wrote:
[Quoting Michael G Schwern, on May 6 2001, 22:58, in Re: Apo2: \Q ambigui]
Hmmm, maybe you can point out the compose key on my keyboard, I
can't find it. ;)
Pick whatever you find convenient. I use the right control key.
From my .Xmodmap:
! Compose key
keycode 109 = Multi_key
I know what Larry went through. I had to do quite a bit of work just
to be able to type a £ symbol. I wound up remapping my 'option' key
(that's 'alt' to you non-Mac people) to £.
since we appear to be sharing on this topic, I ran
perl -e 'for (32..255){print chr};print $/'
and then used mouse paste, when I wanted « and ».
¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐ
ÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
are all in there somewhere.
Re: Subroutine attributes, from a long time ago
John Porter wrote: [EMAIL PROTECTED] writes: : : why should a reader expect that a declarative description : of foo would be followed by the body of foo? Isn't the functional definition of a sub just another one of its attributes, anyway? I'm a little bit disappointed that p6 doesn't appear to be letting user-defined classes take up slots in the main symbol table along with scalar and array slots. If I can define a $duh (duh.scalar) and a @duh (duh.array) why cant I define a class called actor and then define duh.actor? I guess this is back to the allowing undecorated keywords to mean variables thing. In keeping with Nathan's suggestion that angles become the shortcut for the .more method, which is special only in that it has a shortcut, the other early-perl declarations $,%,@ could be considered as shortcuts for the scalar, hash and array attributes of the keyword, aka duh.scalar, duh.hash and duh.array then we _keep_ typeglobs instead of throwing them away, and michael schwern and dan sugalski's heads both implode.
Re: Apoc2 - STDIN concerns
I know it is an annoying and bad habit but I'm still young enough so
at first glance I think I know it all.
[billions and billions of]
SYN_A # Return one element regardless of context.
SYN_B # Return number of element wanted by context.
SYN_C # Return all element regardless of context.
Left out are the Defined? (SYN_D) and Copy (SYN_E)
operations.
For files in p5 we have A and C in scalar or array context of bracketed
file handles. Introduction of counted busy context gives us B in
bracketed file handles:
($first, second_holder(), third_holder()) = $generator
($first, second_holder(), third_holder(), @AllTheRest) = $generator
Which lets us keep unbracketed for D and E.
The basic underlying question is, what is the context that should fire
off an iterator? Everyone thinks @foo[1..10] should just do the right
thing, whatever that is.
okay I'll bite. It's the second through eleventh values of @foo, a
10-element sized busy.
Assuming the following makes an iterator,
and doesn't set $iter to 1 the first time through:
$iter = 1..10;
something we might be able to currently do with a source rewrite
to a tied scalar
How many of these work?
while ($x = @foo[$iter]) { ... }
$x becomes a true and defined reference to a continuable expression ,
and a compile-time warning is issued about suspicious use of an
iterator, suggesting angle brackets.
while ($x = @foo[$iter]) { ... }
still doesn't DWITYM, or does it? It does, due to the relaxation of
the @arrayname[index] syntax being an accessor rather than a slice,
so it is equivalent of
while (($x) = @foo[$iter]) { ... }
would be a lazy while-equivalent of
foreach $x (@foo[1..10]){ ... }
while ($x = $iter) { ... }
unless the code has Creset $iter in it somewhere this will advance
the iterator, breezing right past false and only stopping on undef
(semantic shift triggered by appearance of angles)
(although there are no falses in 1..10)
while ($x = $iter) { ... }
endless loop unless $iter gets set to false or undef
for ($iter) { ... }
Cfor having some magic in it to iterate iterators seems reasonable
I think that iterators must be dereferenced by something explicit, and
we will have to be very clear as to what is explicit enough. Subscripts
may be explicit enough:
@foo[$iter] # okay?
@foo[$iter] # kludgey
Obviously, $iter.method doesn't want to iterate:
$iter.more # can't iterate, or you call $iter.more.more.more...
$iter.more# okay, iterates over some iterators.
Well, that's enough brainwracking for the moment. Gloria is making me
go eat something...
Larry
fascinating
Re: Apo2: \Q ambiguity is too a problem
Larry Wall wrote:
The ~~ is a cute hack though.
Credit is due to Steve Lane [EMAIL PROTECTED] who posted it to funwithperl.
...
I'm sorry, my eyes go crossed when I look at that, and the two \Q's
merge into one, which confuses me, in a stereoscopic sort of way.
I was wrong about \Q\E anyway. Apparently it gets optimized out of
the doublequoting process _BEFORE_ the interpolation occurs, so it cannot
break up the expression. Which is very odd since it happens _after_
interpolation normally since it affects interpoincluded parts of the
string.
metaquoting must happen multiple times in the course of the p5 interplation
process.
And \E\Q fails to have the first \E knock the
metaquote count into the negatives. \q is free however so why not use
define
\q as the zero-length noninterpolable expression, instead of tossing out
the
nifty if rarely used snap-on socket that is the metaquoting sequence?
We could leave \Q{} as metaquote and use \E for a expression stopper,
though that would be confusing to people used to the old \E, which is
dead, dead, dead, drive a stake through its heart, dead. (I hope...)
Larry
\Q{} seems like an alien in a land populated with qw, qh, qr, etc. Why not
join the parade and use qm, if abandoning \Q...\E?
print SCRIPT touch $(qm($filename));
Re: Apoc2 - STDIN concerns
Nathan Wiger wrote:
Perhaps qi() for interpolate or something else.
coming to Perl from Scheme I recall some distress that
I had to create
($j=$i) =~ s/(\$\S+)/$1/ge;
instead of what I wanted to do
$j=qqq/$i/;
so my nomination is for tokens matching /qq*/ to behave like
subsequent applications of evaluation within quotes, even though
it opens the door to a world of taint.
...
Basically, is left as direct access to the iterator, but it's not
magically called except where it clearly make sense (and I don't think
normal variable manip like passing into subs and hashes should be in this
category).
me too
Hmmm, I'm not sure about the iterator object you're implicitly proposing
above. Is it going to be standard fare to assume certain types of objects
are created from certain constructs? What would this do?
I took the iterator object assumption to imply that dotdot in scalar
context was being defined to return tied scalars that return consecutive
numbers, so we can forget about storing all these eminently optimizable
sequential temporary arrays.
$iter = (1..10);
The same thing as above? What about:
What would these do?
I'd parse them, in my hubris, like so:
$iter = (1,2,3,4);
p5: $iter = \(1,2,3,4);
instead of this parsing into comma operator which is what p5 appears
to do with it.
$iter = (5,7..10);
since the dotdot is within another array constructor here, we get
another reference to an array instead of a magic iterator. It can
become a rfc123-compliant magic iterator like so
$iter = ?(5,7..10);
For the rest, assignment is stronger than comma, unless that gets changed.
$iter = 1, 2, 3;
$iter = a, b, c;
$iter = 1, 4 .. 10;
Assuming, however, that we had an iterator object concept, I would say:
while ($x = @foo[$iter]) { ... }
Works.
so undef always passes through an array-lookup?
defined(@arrayA[undef]) # always false?
Phew! My brain hurst. ;-)
-Nate
i agree w/ e-thing
what I meant about hungarian notation
Hungarian notation is any of a variety of standards for organizing
a computer program by selecting a schema for naming your variables
so that their type is readily available to someone familiar with
the notation.
Just as Python is a language that enforces the common practice of
sane indentation by making it part of the language, Perl is a
language that enforces a dialect of hungarian notation by making
its variable decorations an intrinsic part of the language.
What if, instead of cramming everything into scalar to the point
where it loses its value as a data type that magically converts
between numeric and string, as needed, we undo the Great Perl5
Dilution and undecorate references.
The Scalar and The Containers keep their decorations, and things that
are neither numeric nor string values (references to reserved memory
containing
interpretable code, continuations, charm quarks, etcetera) get to stop
dragging around a signifier which does not fit them.
We are at the point where there are so many variable types that the
dollar sign on their names has become a hollow formality.
my dog $spot; #spot is a dog that looks like a scalar
#spot holds neither numeric nor string data
#why is spot burdened with the BASIC
#string identifier?
my dog spot;#after this declaration, it is clear that
#spot is a dog. Should a programmer wish
#or need to be even more specific about
#these things, e could even say
my dog dog_spot;#but it would be entirely up to em and
#the language would not enforce it.
So what I am suggesting is, Scalar as catch-all for unclassifiables
that are neither strings nor numbers may have been a historic stopgap
measure in perl 5 which was seen to be unworkable given the profusion of
object types which became available in perl 6.
An object of type abstracted reference to a chair is _NOT_ an object of
type numeric or string that magicly switches between as needed
This notation,
my type name
makes @ short for array
my @chairs; # equivalent, define a container
my ARRAY chairs;# keyed with wholes
and so forth
the name of the variable is chairs, its type is array,
it is a container, it has the dozen methods described
in the Ctie documentation, and you can get to them the
long way
chairs.PUSH(map {woodworking} ARRAY(treestumps));
or take the shortcut
push @chairs, map {woodworking} @treestumps;
or even, if everything is declared nearby, so we don't need
the decorations, which are now merely casts,
push chairs, map {woodworking} treestumps;
september's discussion, such as
http://www.mail-archive.com/perl6-all@perl.org/msg03542.html
never quite became a RFC (at least not one with undecorated in the title)
at this point we start reducing the funny char load.
The precious antipolymorphism of having @stuff and %stuff refer to
two completely different sets of stuff can be retained, in which case
the decorations must be used to disambiguate, or can be trashed, in
which case decorations can be used or not used as the programmer
sees fit, just as you can cast every occurance of every variable in
a C program if you want and it will compile just the same as if
you had merely declared them all exactly once.
Thanks for listening, I think I did well on the statistics final, got
two projects to do and then the semester is over.
Re: what I meant about hungarian notation
push chairs, map {woodworking} treestumps;
or even
push chairs, map BLOCK(woodworking) treestumps;
Re: Apo2: \Q ambiguity not a problem
Not a problem. \Q means quotemeta, except immediately following
a interpolated identifier. You want to start metaquoting immediately
after a curious interpolation? use \Q\Q.
I have been regularly, since I fingured out how, doing things like
print the time is now ${\(~~localtime)}[go home!]; # double-not
scalar golf hack
in p6 without weird brackets I supposed this becomes
print the time is now $(+localtime)\Q[go home!];
Right? So if I wanted to quotemeta this thing so I could let sh have it
safely, what in apo2 is preventing me from writing
print the time is\Q now $(+localtime)\Q[go home!] \E;
the only time there's an ambiguity is when the metaquoting starts
immediately
after the stopped variable identifier
print SH echo the time is now `date` so go $destinations{first}\Q\Q
$tainted \E;
perl -le'print \Q\Q\Q \E\E \E '
\\\ \\\
metaquote stacks -- why not use \E instead? it has the same issues, but
has
no effect at all currently, and E is for End_of_interpolble_specifier a lot
more than \Q does.
\Q\E is a safe zero-length noninterpolable in any context however, with
no side effect
Garrett Goebel wrote:
From: Larry Wall [mailto:[EMAIL PROTECTED]]
Richard Proctor writes:
: In Apocalypse 2, \Q is being used for two things, and I
: believe this may be ambiguious.
:
: It has the current \Quote meaning admitibly \Q{oute} it is
: also being proposed for a null token disambiguate context.
: As in $foo\Q[bar].
Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge.
I'll have to think about it. Maybe quotemeta becomes \qm{}
or some such.
The problem with \Q quotemeta was the biggest thing to jump out at me when
reading A2... That is before my brain turned to mush. Seems like quotemeta
be serving its purpose if you have to consider escaping its contents...
What's the Perl6 equivalent to:
#!perl -w
# script.pl:
my ($match, $filename) = @ARGV;
local $/;
open FH, $filename;
$file = FH;
print scalar @{[$file =~ m/(\Q$match\E)/gs]};
1;
__END__
file.txt contents:
{foo}\E{foo}\E{foo}
script.pl {foo} file.txt
3
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Parse, munge, repeat.
Re: Apoc2 - STDIN concerns
if we kept with their current meaning but added it as a handier whitespace quoter I would like that. p5: @things = one two three four five; _is_ currently a syntax error. In my mind. Not in my 5.005_03. however, where it appears to behave just like qw does, except that it does interpolation, which qw does not. Is the proposal, then, to abandon the interpolation within angle-quotes? Or just to give the feature some much-needed perl -le '@things = one two three four a$a five; print @things' one two three four a a five perl -le '@things = qw one two three four a$a five; print @things' one two three four a$a five
sandboxing
In all the discussion of customizing the parser, let us not forget that we also need to be able to limit the parser. The Penguin module offers one interface for doing that. But the larger question remains, is sandboxing something a language should support at all, or is it best left to the OS to provide a solid chroot facility? -- David Nicol 816.235.1187 [EMAIL PROTECTED] Parse, munge, repeat.
Re: Please make last work in grep
It also reminds me of mjd's mention of: my($first) = sort {...} @list;
being O(n) if Perl were really Lazy.
But it would need a completely different algorithm. Which is not too
bad. And even
my ($first, $second, $third) = sort {...} @list;
is kind-of plausible. So we'd definitely want ...
my @heapa is heap;
@heapa = @list;
my $first = shift @heapa;
my $second = shift @heapa;
my $third = shift @heapa;
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Parse, munge, repeat.
apo 2
I am going to miss doublequoting being the default quoting for here strings. I find that to be a very nice optimization and would like to know more about the reasoning behind taking it away. I worry that official standard p6 will be more difficult to use than official standard p5. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Parse, munge, repeat.
Re: Please make last work in grep
Graham Barr wrote: How this cooperates with lazy is a different matter entirely. Graham. http://dev.perl.org/rfc/123.html#Assigning_from_lazy_lists suggests that assigning to a sized busy array from a lazy array will fill it and stop. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Parse, munge, repeat.
Re: a modest proposal Re: s/./~/g
Jonathan Scott Duff wrote: I'd rather it be cc or _ (I didn't like the underscore at first, but it's grown on me a little) Comparing ~ and _ to available editors markup marks, _ is closer to the sideways () that an editor might use to indicate that two words should be joined together. Tilde looks like it might mean switch the order of the token ahead and the token behind me Will there be confusion with the _ that means the file statted by the last -X test? I doubt it: file tests need to bind tighter than the concat op and the problem is over. I can't create a situation where it would be confusing anyway -- what would the LHS of the _ be in a test situation? There wouldn't be one. For that matter, indirect object syntax is always bareword $object|bareword argument[, ...] which would collide with relatively few concat accretions, even without any semantic information. If it starts with a bareword, it's not a concat. A stronger argument against white-space-juxtapositions IMO would be the possible confusion generated by arguments getting accretted when a comma gets left out, instead of a syntax exception getting thrown: function(this,that the other); the second argument is now the intended second and third args and there is no third arg, instead of a syntax error. -- David Nicol 816.235.1187 [EMAIL PROTECTED] and they all say yodelahihu
Re: Strings vs Numbers (Re: Tying Overloading)
John Porter wrote: We could y/$@%/@%$/ ... ... and create an alternate parser able to handle the full internal internals API. I have finally figured out the main motivation behind the whole perl6 effort: the obfuscated perl contests were getting repetitive. Good night.
Re: s/./~/g
Eric Roode wrote: What is it about . that seems to inspire allergic reactions in people? Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. No, more like . is already used for something. The only reason I have seen written out so far for the shift from - to . and . to insert op here is: it looks more like other languages. That seems like a whole lot of fixing of non-broken syntax. which is why, back in http://www.mail-archive.com/perl6-all%40perl.org/msg01043.html Oh, last august, we discussed all this -- David Nicol 816.235.1187 [EMAIL PROTECTED] and they all say yodelahihu
Re: Larry's Apocalypse 1 \}
Dan Sugalski wrote: Most of the parser switching is going to be of the nesting variety. Every time the parser processes a double-quoted string constant or a regular expression you're going to be jumping parsers. That's all temporary, and we really do want them to nest. (You really don't want the perl parser to lose all its state every time you start a string...) No, of course not. I'm asking for separation of parsing and state so that multiple parsers can cooperatively contribute to the developing state. That is what would be required for python mode to be able to close blocks opened in perl mode, or v/v. Just like SH doesn't throw out all environment variables between instructions. SH is very much like this: you can have multiple parsers acting on multiple HERE documents, one after the other, in case anyone wasn't aware of that already, which I doubt.
Re: Tying Overloading
Larry Wall wrote: (And juxtaposition is out because we're not going to destroy indirect object syntax How often is indirect object syntax used without some whitespace? Having the perl5-perl6 converter locate it and insert a space shouldn't be too very tricky. $these=$this$that$the_other; is what we've been doing inside double quotes for years. Making butted-against-each-other be the string concatenation operator looks good IMO. I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will be stringify. Not unary diglyph \ ?
C or SH like string cat proposal
1: use adjacency w/o white space for string cat. 2: allow, as in C, consecutive double-quoted strings with no intervening tokens (i.e. just whitespace and comments) to be considered as one string 3: as Uri pointed out, it's all syntactic sugar for convolutions of Cjoin That means, if you have a long list of scalars rou want to cat together and it will run over the edge of your line you can do this: $onethroughten = $one$two$three$four$five $six$seven$eight$nine$ten; Will someone please explain to me the indirect object syntax which this allegedly steps on? -- David Nicol 816.235.1187 [EMAIL PROTECTED] Henrik's keyboard has nice letters like 'æ', 'ø' and 'å'
Re: how about just juxtaposing? (Re: Sane + string concat proposal)
Ah.. I knew I'd find the thread in here somewhere. The problems go away if you allow white space to signify. [...] Consider print Foo foo(bar); Did the author forget a semi-colon, or did they intend to concatinate there? Also, consider this... they forgot a semicolon. A spaceless juxtaposed concat would look like print Foofoo(bar); and we insist that indirect objects have a space in them. And introduce for when you absolutely positively don't want to write an expression with Cjoin. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Henrik's keyboard has nice letters like 'æ', 'ø' and 'å'
Re: Larry's Apocalypse 1 \}
Dan Sugalski wrote: I'm not a parser guy by any means (unfortunately) but we have the distinct possibility of completely replacing all of the parser rules after token X appears, whatever that token might be. (Heck, we may have the possibility of replacing the entire parser) There's no guarantee the non-perl-6 section will have a nice end-delimiter for us to find. Granted that won't be the case all the time, but it's certainly quite feasable. We might not even be able to rely on perl's definition of a token. (Or whitespace for that matter--Whitespace isn't just whitespace in python mode) sounds a lot like an exec system call: there are some things which remain in effect (open file handles, current directory, environment) but there are many others which do not. Maybe switching parsers is best an absolute kind of thing rather than a stacked kind of thing, with the later parser responsible for switching back. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Described as awesome by users
Re: Larry's Apocalypse 1 \}
Larry Wall wrote: David L. Nicol writes: : : [this parser switch thing] : sounds a lot like an exec system call: there are some things : which remain in effect (open file handles, current directory, : environment) but there are many others which do not. Maybe : switching parsers is best an absolute kind of thing rather than : a stacked kind of thing, with the later parser responsible for : switching back. The truth is somewhere in the middle. It is incumbent on the outer rule to inform the inner rule how it thinks the inner rule ought to terminate, and it is the choice of the inner rule whether to follow the convention suggested by the outer rule. A rule that starts at a left parenthesis will suggest stopping on a right parenthesis, but if the inner rule is parsing troff, all bets are off on properly nesting parens. Larry Right. The existence of these all bets are off cases is what makes, IMO, a non-stacked system look better. If the conversation starts in Russian, switches to Chechen, then Turkish, then English, the conversants might want to switch back to Russian without having to say a single word of Turkish or Chechen on the way back. Or they might not switch back at all! What I see as needed is a designated meta-token that will be reserved, in some form or another, as the switch-parser command. In human language you just switch, and the conversants notice that a switch has occured and if they are fluent they, by default, switch too -- this behaviour is confirmable by anyone who has spent time slacking at an embassy. The consensus remains that computers are not yet ready to figure out which of the languages they can understand they are being addressed in, even though the mechanism (start all the interpreters and the one that doesn't err out is the winner) has been available in science fiction since the early seventies (I encountered it in a yellowing paperback in 1977, the plot involved a midwestern dystopia run by a central computer which had been set up by a lone genius who later disappeared: it appeared to the naive that the computer was running amok and killing people but the protagonist was able to rule out mechanical error, eventually the culprit is cornered after a variety of suspensful moments -- Does anyone know the title of the book? I'd like to read it again now that I have Adult Perspective -- addititional remembered plot and setting details available on request) ... so we can't have the programs just switch. Even if they leave five consecutive blank lines between them? What about a hash-bang? Maybe putting a hash-bang in the middle of the text (outside of quoted literals, of course) could indicate that the referenced program is to take over the parsing duties. The problem with the oughts and incumbencies is, you have to come up with a whole minilanguage for telling the inner rule, parse until you get to a right angle bracket at the beginning of a line or something like that -- but then what have you gained over HERE notation? HERE notation is grand for language nesting: all those millions of perl programs that output HTML are a perfect example. But to replace the whole parser (replacing part of the parser can be reduced to replacing the whole parser with a very similar one) we don't care if we come back. We might not come back. We just need to choose a syntax for the transition. __PARSER_NAME__ matches other parts of the language behind the scenes the linkage could be arbitrarily complex, some languages might not be able to handle transitioning directly into some others, others might be able to switch over in medias. I don't know enough python to produce an example of a fragment that starts in perl and does __PYTHON__ to do some python-style array slicing using the variable names which had been momentarily before prefixed with @ symbols then does __PERL__ some time down, after the loops opened up with right curlies before the first switch have been closed by abandonment of indentation. That would be based on some very sophisticated handshaking, where the second language could close the first one's scopes and so on. What is the minimum granualrity of JPL? Can you write the first five lines of a function in JAVA and the last five lines in Perl? And the default case, the sensible autovivification, on encountering a __FUTBOL__ token would be to throw a syntax exception: Whatever is managing the developing op-code tree would have to catch those and see if it has a FUTBOL parser. Or throw an exception because it doesn't. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Described as awesome by users
Re: Larry's Apocalypse 1 \}
Brent Dax wrote: Yes, that is exactly what I had in mind, thanks for the validation. Only the comment syntax would have to come back to a designated module, with another hashbang. #!comment yadda yadda yadda blah blah blah foo bar baz #!VB6 foor=bar frob()
Re: Larry's Apocalypse 1 \}
Simon Cozens wrote:
On Thu, Apr 12, 2001 at 05:39:12PM -0400, Dan Sugalski wrote:
[We have FOO:BAR]
While this is reasonably true (and reasonably reasonable) it's not entirely
to the point. If we're going to provide a mechanism to define the syntax of
a mini-language (or a maxi one, I suppose, though there are probably better
ways to do it) then the details of colons and constants and what-have-yous
are pretty close to irrelevant.
No, I don't think so. The whole thing rests on the fact that class FOO knows
how to parse string BAR. This, from the tokener's point of view, means that
class FOO has to tell us when string BAR actually *ends*.
No it doesn't. There are well-defined rules for when string BAR actually
*ends*
which are followed before FOO ever sees it.
For complex BAR (and
complex FOO) this could be, uh, complex. It means that our parser would have
to call out to other routines - which can presumably be defined in Perl - to
assist in parsing Perl code. And hey, if BAR can be defined in Perl, it can be
defined on-the-fly. Oh dear.
Not impossible by any means, but *by no means* irrelevant.
No.
Recursive parsing is not needed. We have the HERE string, which can
include anything in with the rest of the code, by looking for the
end-token. The perl5 Inline module works that way.
Perl5 can be parsed by making everything token, whitespace, or
literal. Literals have to end the way they start, but it is not
recursive: interpolation is applied to a quoted literal, it does not
affect what is in and what is out of the literal.
To me the simplest way to proceed, with maximum flexibility, would be
to offer two types of rewriting systems:
1: your system operates from scratch on a string literal,
like Inline does now. Any syntax is allowed, as long as
there is some indicator you can remember to escape when
it appears within your string. This is how all
8-bit-safe transfer protocols work, except for the ones
that know the length of their payloads at the beginning.
Prefixing literals with character counts would be
nightmarish and I am NOT suggesting it.
2: your system operates on tokenized (but not yet
interpreted) perl symbols. The only restriction is, your
curlies have to match. So we introduce two new tokens,
the literal curlies -- \{ and \} -- which are equivalent
to \" within a string -- in case your special token would
like to accept pre-tokened (token, whitespace, literal)
code and agrees with perl's idea of how blocking and
quoting works. To parse python using this system we'd
need to keep the details of whitespace around instead of
instantly dismissing it. Or insist that language
extensions must maintain curlie balance. It's really a
very minor demand, esp. since there is method 1
(inline-style operation on a quoted literal string ) to
fall back on.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Home of the V-90 modern
pitching names for the attribute for a function with no memory or side effects
James Mastros wrote: Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. :memoizable :clean :nosideeffects
Re: What can we optimize (was Re: Schwartzian transforms)
Dan Sugalski wrote:
At 02:52 PM 3/29/2001 -0800, Russ Allbery wrote:
James Mastros [EMAIL PROTECTED] writes:
Ahh, bingo. That's what a number of people (inculding me) are
suggesting -- a :functional / :pure / :stateless /
:somthingelseIdontrecall attribute attachable to a sub.
The experience from gcc, which has a similar attribute, is that such an
attribute will be fairly rarely used and that most of your gains will come
from managing to teach the compiler to figure out that information for
itself.
I'm hoping to have this stage of optimization in perl.
Dan
define non-MY to mean, dynamic or lexical from outside of the function,
so, non-my relative to the function.
obviously_clean(\subX){ # could be defined as:
not (any appearance of known-unclean functions)
and
not (non-MY appears at all)
}
subs and functions can get flagged clean/unclean fairly quickly then.
known-unclean are things like "rand" and any functions that have not
been marked "clean" already.
The attribute would force a non-obviously clean subroutine to be treated
as clean, and memoized, unless use-less-memory is in effect. It would allow
for some pretty subtle abuses.
The Unlambda Programming Language
"currying" used in a fascinating context: an experimental language in which http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/#tut everything is a unary function. Multiple-argument functions are defined in such a way that the function takes the first argument and returns a function that takes the second.
Re: End-of-scope actions: Toward a hybrid approach.
Tony Olekshy wrote:
If we take this approach then when you just want to casually say
my $f = open $file; always { close $f };
you can. I like that. In addition, when you want to carefully ...
How about "later" instead of "always"
Because: "later" is a time in the future, but we don't know exactly
when,
and "always" has an aspect of continuing in time which is
distracting (to me.)
Bulletin: Nicol reads rfc 271; suggests restricted Cbless
We're having a blizzard in Kansas City. After breakfasting, changing
the litter box, and hiking to work through the snow, I am finally
looking at Conway's RFC 271. Guess which one of the earlier
activites it reminds me of.
I agree with Branden that the inheritance semantics is screwy.
I think DesignByContract contract enforcement is best done with
a parameter typing system of some kind (as in C++). Proper
objects don't get into invalid states (unless you smash them with
hammers, of course), so with polymorphic subs, where the
types of the arguments are part of the name of the function, and
some restrictions on Cbless
(Did anyone RFC an extension to Cbless that allows a type to
define a sanity checking function?)
you can't call a subroutine with an invalid argument.
The CPOST method of defining a thing that is to be done on exiting
the current scope would make things easier rather than more complex
in my opinion, as discusses previously.
If object validity checking were incorporated int Cbless the customary
return of an object
bless $retobj
}
would do an automatic sanity check against the requirements of the current
package. How about calling the standard function that bless refers to,
if it exists, before conferring its blessing, package::TEST ?
package compliant;
sub TEST{
# will be called at every blessing.
# compliant objects must have true cheese.
$_[0]-cheese() or die "FALSE CHEESE"
}
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"I don't care how they do it in New York"
Re: restricted Cbless
Branden wrote: If object validity checking were incorporated int Cbless the customary return of an object [snip] I don't think I quite understood you. Are you thinking `new' is the only one that would have pre/post to validate arguments? Actually every method call would potentially have pre/post blocks, by RFC 271. Did I get you wrong? bless is the (only) way to associate a reference with a package. Currently, if I set up a package that expects all the objects defined by it to have some representation or another (representation R) there is nothing stopping me from accidentally (or someone else who is being rude) blessing some noncompliant reference into the package, resulting in the necessity of all the consistency checking that the pre-handlers would be for (or did I get that wrong. ) Robust object methods have to do a lot of consistency checking because there is no guarantee that the reference labeled "duck" isn't really a chicken with softer feathers glued to it. What I'm arguing is that a stronger typing, that enforced a correlation between class-label and internal-data-consistent-with-expectations, would move the pre and post handlers from a procedural specification into a more functional one. We would, like in C++ or Java, define a new kind of object that embodies the whole of what the contract is between the two components exchanging the message. If the receiving function cannot be invoked unless it is invoked with an argument of type ExpectedType and the only way to get an argument into that type is to have it pass the required test, whatever that is, as defined within the ExpectedType specification, every contract gets its own object type and any pre or post processing becomes implied by conversion wrappers. Am I making sense? I worry I am rushing. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "I don't care how they do it in New York"
more POST recitation
Johan Vromans wrote:
Would the POST be executed if the open fails? Why? Why not?
sub readit {
POST {
close F;
}
open F, " $f" or die;
scalar(F)
}
Yes, because the flow of control passed it before the exception.
POST, as I see it, means, push a reference to the code in its block
onto a list of things to do when exiting the current scope, with no
regard to GC.
But I think this is getting ridiculous. $slightly_joking++; I'd
propose a much nicer and cleaner concept:
sub readit {
open F ... ;
prog1 {
scalar(F);
close F;
}
}
'prog1' executes all expressions in the block, and returns the result
of the first expression. Of course, we also need prog2, prog3, and so
on ... $slightly_joking--;
All that POST and such do, is obfuscate the flow of control. I doubt
that outweighs the small benefits.
-- Johan
do BEGIN and END obfuscate the flow of control?
If constructors can have arbitrary names, then why not
destructors? Because while a constructor is explicitly
called, a destructor is not. Destruction happens
automatically via Perl's garbage collection (GC) system,
which is a quick but somewhat lazy reference-based GC
system. To know what to call, Perl insists that the
destructor be named DESTROY. Perl's notion of the right
time to call a destructor is not well-defined currently,
which is why your destructors should not rely on when they
are called.
Why is DESTROY in all caps? Perl on occasion uses purely
uppercase function names as a convention to indicate that
the function will be automatically called by Perl in some
way. Others that are called implicitly include BEGIN,
END, AUTOLOAD ...
The twisty-turny things you have to do in order to have cleanup
code right now prevent a subroutine that needs cleanup code from
having multiple exit points, unless the cleanup code is listed
at each one.
With POST, you explicitly declare cleanup code as soon as you see
you will need it, and you don't have to worry about your lock
getting forgotten about or your file remaining open.
# without POST
sub find_first_line_matching_array($\@){
open F, shift or die "could not open: $!";
while(F){
foreach $w (@{$_[0]}){
if (/$w/){
close F;
return $_;
} } } }
# with POST
sub find_first_line_matching_array($\@){
open F, shift or die "could not open: $!";
POST{close F};
while(F){
foreach $w (@{$_[0]}){
return $_ if /$w/;
} } }
The above is a very contrived way to have multiple exit points;
but tracking $retval so you can hit your cleanup code is a drag.
Many times I've chosen to use something like Cgoto have_value
to hop down to the end of the sub, rather than repeat my
cleanup code before the return, several times, in inconvenient blocks.
POST would not be intended for flow-of-control; it is intended
to raise the code's s/n ration by abstracting the housekeeping.
Re: assign to magic name-of-function variable instead ofreturn
Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that
the following block is going to be subject to exception handlers which will
immediately follow as siblings of the block. Somewhat as I would look at
an if...elsif...else construct, it helps me put the block in context as I'm
reading it and also look ahead fo those handlers. I prefer this to
discovering a handler as I'm reading and then looking for the enclosing
block, or coming across an undecorated block and scanning to see if this is
because it has embedded handlers or is to create a closure, or to use a
redo, or...
like
eval { SomethingThatDies()};
if $@{
$@ =~ /case1/ and DealWithCase1 and return;
$@ =~ /case2/ and DealWithCase2 and return;
$@ =~ /case3/ and DealWithCase3 and return;
die "Unhandled case $@";
LABEL:
};
$@ gets reset at the next eval. I assume these things
nest appropriately, and $@ starts as null inside an eval
and evalling something inside there that dies does not
affect external ones. Testing
perl -le 'eval{eval{die "i"};print $@};print "now:$@\nok"'
yup.
Re: assign to magic name-of-function variable instead of return
James Mastros wrote: I'm quickly getting more confused here then I want to be, so I'm going to stop now. -=- James Mastros James: Thanks. One confusing thing is that I apparently switched from thinking $__ shuld be an alias to thinking $__ should be a reference; which makes (wnatarray?@$__:$$__) the alias for the lvalue. -- David Nicol 816.235.1187 [EMAIL PROTECTED] www.tmcm.com, dammit
Re: assign to magic name-of-function variable instead of return
[EMAIL PROTECTED] wrote:
Does that mean there's going to be a @__ as well, for uses in list context?
If so, what happens with:
sub some_sub {
@__ = qw /foo bar baz/;
}
my $fnord = some_sub;
If there isn't going to be a @__ of some sorts, how is the case of the sub
being called in list context going to be handled?
Abigail
If $__ is a reference to our lvalue, if any, instead of an alias, since
references are all scalar, we can take Cref($__) to get a finely
grained Cwant function.
And when the sub is called in list context, @$__ will be the list.
This allows intrusive functionality to fiddle with lvalue parts:
sub DirectBubbleSort(){
my ($i,$t) = (-1,0);
while (++$i = $#$__){
$$__[$i] $$__[1+$i] and $t++ and @$__[$i,1+$i] =
@$__[1+$i,$i];
};
$t and @$__ = DirectBubbleSort;
}
@SomeList = DirectBubbleSort; # instead of DirectBubbleSort(\@SomeList)
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
www.tmcm.com, dammit
a name for the currently executing sub
James Mastros wrote:
At least it's independent of the sub's name. I wish this could be
extended to doing recursive calls without having to say the subs own
name, again.
I agree, making the magic variable be the name of the sub is a bad idea.
Your idea for a name for the currently executing sub is interesting, I
think. I'm going to fork the thread.
-=- James Mastros
IMO the name of the currently executing sub should be accessed via an
extention to Ccaller().
caller{subname}
For that matter a reference to the lvalue if any could be
caller{lvalue}
instead of another LNV.
Re: assign to magic name-of-function variable instead of return
John Porter wrote:
http:[EMAIL PROTECTED]/msg02294.html
that the "handler" block should be nested within the block to
which it pertains, in much the same way that BEGIN and END blocks
reside inside the file to which they pertain.
So:
sub readit {
open F, " $f" or die "$f: $!";
F;
catch { ... }
end { close F }
}
FWIW I agree that this is better than doing the parts in different
places,
post readit {...}
seems like it could be very far away from
sub readit {...
and cause some serious AAAD confusion.
Damian?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
www.tmcm.com, dammit
Re: Really auto autoloaded modules
use autoload { Bar = 'http://www.cpan.org/modules/Bar',
MD5 = boogedyboogedyboogedyboo },
{ Baz = 'ftp://my.local.domain/perl-modules/Baz',
VERSION = 2,
MD5 = dfasgjlkndakjargjbg245098t4lkjng };
Security mechanisms more complex than expected checksums could
be added too -- gpg signatures, for instance
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
www.tmcm.com, dammit
