Re: CLOS multiple dispatch

2001-09-06 Thread David L. Nicol

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

2001-08-30 Thread David L. Nicol

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)

combined with a shorthand for generating lots of available prototypes

sub handle
   (*_window $w, kill_event $e)

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?


   David Nicol 816.235.1187
   KAK OH CKA3AT what he said

Re: CLOS multiple dispatch

2001-08-30 Thread David L. Nicol

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

2001-08-29 Thread David L. Nicol

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
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
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

2001-08-29 Thread David L. Nicol

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

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

2001-08-29 Thread David L. Nicol

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?

2001-07-11 Thread David L. Nicol

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?
 So mote it be. :)

What?  Up until now it's been vtable-pointers are per-object.

Re: Per-object inheritance in core a red herring?

2001-07-10 Thread David L. Nicol

 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
 *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,
 Anyhow, Self is the only one I can think of.  ALL THE FULL-TIME SELF

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?

2001-07-10 Thread David L. Nicol

 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

   David Nicol 816.235.1187
   Perl was born in downtown Hell! -- Matt Youell

Re: Per-object inheritance in core a red herring?

2001-07-10 Thread David L. Nicol

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?

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?

2001-07-10 Thread David L. Nicol

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?

Apparently I was basing my statements on an incorrect understanding.
According to a recent C++ reference,

 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

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?)

2001-07-09 Thread David L. Nicol

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


2001-07-09 Thread David L. Nicol

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.

2001-07-09 Thread David L. Nicol

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
  - 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:

Stuff about polymorphism and multiple dispatch was supposed to touch on
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

2001-07-09 Thread David L. Nicol


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
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
 %time = gmtime; # ok, localtime and gmtime have the same
 $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

 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

2001-07-09 Thread David L. Nicol

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 {
 my ($a, $b) = @_;
 my $c = bar($a + $b);
 my $d = bar($a - $b);
 if (BBB $c  $d BBE) {
 my $e = $c * $d;
 return ($e + 1)/($e - 1);
 } else {
 ($c, $d) = ($d, $c);
 return ($c + $d)/($c - $d);


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

2001-07-09 Thread David L. Nicol

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;


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).
  localtime would return a magic read-only hash reference.
 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
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
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

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

Perl's Magical Autoconverting Wondervariable.  I introduced the
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?)

2001-07-06 Thread David L. Nicol

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
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,
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?)

2001-07-05 Thread David L. Nicol

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?
 - Matt

What's the problem again?

I mean, really, any OO shop has it's local culture, of what the base
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
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?

2001-07-05 Thread David L. Nicol

Hong Zhang wrote:
 Say if you want Thread can be easily inserted into LinkedList,
 you can write
 public Thread extends Object implements Node {
 public Thread extends Object, Node {
 and don't bother to implement classic linked list node.

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?)

2001-07-04 Thread David L. Nicol

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?)

2001-07-03 Thread David L. Nicol

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

2001-06-28 Thread David L. Nicol

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

Language list is for determining what the programmer interface looks like.

'We already have a sub keyword'

2001-06-27 Thread David L. Nicol

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

Re: Multiple classifications of an object

2001-06-27 Thread David L. Nicol

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

Re: Multiple classifications of an object (the ::: placeholder)

2001-06-27 Thread David L. Nicol

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

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


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
like 'foo:::0x80f5934'

   David Nicol 816.235.1187

making variables or containers read-only

2001-06-21 Thread David L. Nicol

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
operation, whatever it looks like, might return a coderef which could be
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.

2001-06-20 Thread David L. Nicol

 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

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

2001-06-18 Thread David L. Nicol

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

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
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
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
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
that I believe needs to be made, by any names, because without it there
will be

Re: tasty db data

2001-06-13 Thread David L. Nicol

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
who would write:

sub loiter_after_generating_a_value {

my scalar retval = do something_that_generates_a_value;


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

2001-06-12 Thread David L. Nicol

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.

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

   David Nicol 816.235.1187
  Signature closed for repaving

Re: Coupla Questions

2001-06-12 Thread David L. Nicol

Damian Conway wrote:
 Graham wrote:
 Now I may be wrong here, but I thought I remembered something about

   .foo being the same as $
 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.

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

2001-06-12 Thread David L. Nicol

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
value to get assigned, or we need to pass around something -- a magic
perhaps -- that can hold a deferred expression -- and define certain
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
to a coderef, which will return the SV when it is run.  

Perl5 scalars can hold codrefs, but the programmer needs to explicitly run

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
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
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
this as a gag reflex) which is, for database purposes, something that
all the deferred keys getting rolled up into a SQL query and the values
inserted into the appropriate tasty vars so they become normal scalars
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

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
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

2001-06-12 Thread David L. Nicol

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.

 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.

2001-06-11 Thread David L. Nicol

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],

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.


Ceval (string/block) is but one.  Crequire (file name / version number)
another. Cdo might be considered another.  There is discussion of
Clength(@) to do what beginners expect.

Those are the only ones we have right now. I am sure that the people
this are about evenly divided between thinking Basta, no mas! and
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
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

2001-06-11 Thread David L. Nicol

Vijay Singh wrote:

 Just how much $foo can dance on the head of a dot operator

The current Annals Of Improbable Research (
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

2001-06-11 Thread David L. Nicol


 You may wish to read this thread about lazy arrays and object
 persistence to get an idea of what you're getting into.

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

2001-06-11 Thread David L. Nicol

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...

2001-06-08 Thread David L. Nicol

~/perl/perl-5.7.1$ ./perl -le '%a=(1..10); print it; exists $a{1} and print


   David Nicol 816.235.1187
 The toad doesn't know it has ten toes.

Re: 1 until defined(getvalue()); return $^d;

2001-06-07 Thread David L. Nicol

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

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


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;

2001-06-07 Thread David L. Nicol

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

2001-06-07 Thread David L. Nicol

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;

2001-06-06 Thread David L. Nicol

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
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;

2001-06-06 Thread David L. Nicol

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

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

2001-06-06 Thread David L. Nicol

Damian Conway wrote:

 $ref.{a}can be  $ref{a}

which can also be


can it not?

Re: Properties and stricture

2001-06-06 Thread David L. Nicol

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).


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

2001-06-06 Thread David L. Nicol

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/');
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:

   David Nicol 816.235.1187
 Keep Dan Sugalski away from my stuffed animals

Re: $foo.Foun (was Re: Properties and stricture)

2001-06-06 Thread David L. Nicol

Me wrote:
 Question 1:
 Afaict, even with use strict at its most strict, perl 6
 can't (in practice) complain, at compile time, if
 refers to an undeclared Foun.

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

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
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!)

2001-06-04 Thread David L. Nicol

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?

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};

2001-06-01 Thread David L. Nicol

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

2001-05-30 Thread David L. Nicol

Me wrote:
 It was an informal finger-in-the-wind thing I sent to
 a perl beginners list. Nothing special, just a quick
  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:

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


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:
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;

2001-05-30 Thread David L. Nicol

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 $_

  David Nicol 816.235.1187 [EMAIL PROTECTED]
 # die smiling;

Re: 1 until defined(getvalue()); return it;

2001-05-30 Thread David L. Nicol

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
assigned.  it holds the place in my pseudocode.

The pseudocode is for a source filter so I was thinking syntax

Re: 1 until defined(getvalue()); return it;

2001-05-30 Thread David L. Nicol

Buddha Buck wrote:

 Why is [...] better than
 1 until defined($foo=getvalue()); return $foo; 

small incremental improvement to [read|writ]ability


one less thing to write
one less variable name to have to remember not to collide with


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
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;

2001-05-30 Thread David L. Nicol

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.

# 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

2001-05-10 Thread David L. Nicol

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


is guaranteed to access the same slot as


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

2001-05-09 Thread David L. Nicol

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)
 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

2001-05-09 Thread David L. Nicol

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

2001-05-08 Thread David L. Nicol

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?

2001-05-08 Thread David L. Nicol

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

2001-05-08 Thread David L. Nicol

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
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

2001-05-08 Thread David L. Nicol

Nathan Wiger wrote:

 I think Uri's qh() suggestion is the cleanest:

me too

 And it would make hash declarations cleaner:
%hash = qh(
 jim = 'bob'
 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


   $%  The current page number of the currently selected
   output channel.  (Mnemonic: % is page number in

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

Re: Apoc2 - Context and variables

2001-05-08 Thread David L. Nicol

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  :-)

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

2001-05-08 Thread David L. Nicol

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

2001-05-08 Thread David L. Nicol

John Porter wrote:
  : 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

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

2001-05-08 Thread David L. Nicol

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)

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...


Re: Apo2: \Q ambiguity is too a problem

2001-05-08 Thread David L. Nicol

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
metaquoting must happen multiple times in the course of the p5 interplation

  And \E\Q fails to have the first \E knock the
metaquote count into the negatives.  \q is free however so why not use
\q as the zero-length noninterpolable expression, instead of tossing out
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...)

\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

2001-05-08 Thread David L. Nicol

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


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

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]) { ... }

so undef always passes through an array-lookup?

defined(@arrayA[undef]) # always false?

 Phew! My brain hurst. ;-)

i agree w/ e-thing

what I meant about hungarian notation

2001-05-08 Thread David L. Nicol

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
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
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

2001-05-08 Thread David L. Nicol

 push chairs, map {woodworking} treestumps;

or even 
push chairs, map BLOCK(woodworking) treestumps;

Re: Apo2: \Q ambiguity not a problem

2001-05-04 Thread David L. Nicol

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
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
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
 my ($match, $filename) = @ARGV;
 local $/;
 open FH, $filename;
 $file = FH;
 print scalar @{[$file =~ m/(\Q$match\E)/gs]};
 file.txt contents:
 {foo}\E{foo}\E{foo} {foo} file.txt

  David Nicol 816.235.1187 [EMAIL PROTECTED]
  Parse, munge, repeat.

Re: Apoc2 - STDIN concerns

2001-05-04 Thread David L. Nicol

if we kept  with their current meaning but added it
as a handier whitespace quoter I would like that.

@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


2001-05-03 Thread David L. Nicol

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

2001-05-03 Thread David L. Nicol

  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

2001-05-03 Thread David L. Nicol

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

2001-05-02 Thread David L. Nicol

Graham Barr wrote:
 How this cooperates with lazy is a different matter entirely.

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

2001-04-27 Thread David L. Nicol

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:

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)

2001-04-25 Thread David L. Nicol

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

2001-04-25 Thread David L. Nicol

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

Oh, last august, we discussed all this

  David Nicol 816.235.1187 [EMAIL PROTECTED]
  and they all say yodelahihu

Re: Larry's Apocalypse 1 \}

2001-04-24 Thread David L. Nicol

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

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

2001-04-24 Thread David L. Nicol

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.


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

2001-04-24 Thread David L. Nicol

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

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)

2001-04-24 Thread David L. Nicol

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
 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 \}

2001-04-23 Thread David L. Nicol

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 \}

2001-04-23 Thread David L. Nicol

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.

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

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
to do some python-style array slicing using the variable names
which had been momentarily before prefixed with @ symbols then

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 \}

2001-04-23 Thread David L. Nicol

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.

yadda yadda yadda
blah blah blah
foo bar baz
foor=bar  frob()

Re: Larry's Apocalypse 1 \}

2001-04-19 Thread David L. Nicol

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
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.


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

2001-03-30 Thread David L. Nicol

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.




Re: What can we optimize (was Re: Schwartzian transforms)

2001-03-30 Thread David L. Nicol

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

 I'm hoping to have this stage of optimization in perl.

  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)
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

2001-02-19 Thread David L. Nicol

"currying" used in a fascinating context: an experimental 
language in which

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.

2001-02-13 Thread David L. Nicol

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

and "always" has an aspect of continuing in time which is
distracting (to me.)

Bulletin: Nicol reads rfc 271; suggests restricted Cbless

2001-02-09 Thread David L. Nicol

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

2001-02-09 Thread David L. Nicol

Branden wrote:

  If object validity checking were incorporated int Cbless the customary
  return of an object
 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

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

2001-02-09 Thread David L. Nicol

Johan Vromans wrote:

 Would the POST be executed if the open fails? Why? Why not?
sub readit {
 close F;
 open F, " $f" or die;

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 {
 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,

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: $!";
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};
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

2001-02-07 Thread David L. Nicol

 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...


eval { SomethingThatDies()};
if $@{
  $@ =~ /case1/ and DealWithCase1 and return;
  $@ =~ /case2/ and DealWithCase2 and return;
  $@ =~ /case3/ and DealWithCase3 and return;
  die "Unhandled case $@";

$@ 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"'


Re: assign to magic name-of-function variable instead of return

2001-02-05 Thread David L. Nicol

James Mastros wrote:

 I'm quickly getting more confused here then I want to be, so I'm going to
 stop now.
  -=- James Mastros


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], dammit

Re: assign to magic name-of-function variable instead of return

2001-02-05 Thread David L. Nicol


 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?

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] = 
$t and @$__ = DirectBubbleSort; 

@SomeList = DirectBubbleSort; # instead of DirectBubbleSort(\@SomeList)

  David Nicol 816.235.1187 [EMAIL PROTECTED], dammit

a name for the currently executing sub

2001-02-05 Thread David L. Nicol

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().


For that matter a reference to the lvalue if any could be


instead of another LNV.

Re: assign to magic name-of-function variable instead of return

2001-02-05 Thread David L. Nicol

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.
 sub readit {
 open F, " $f" or die "$f: $!";
 catch { ... }
 end { close F }

FWIW I agree that this is better than doing the parts in different

post readit {...}

seems like it could be very far away from 

sub readit {...

and cause some serious AAAD confusion.


  David Nicol 816.235.1187 [EMAIL PROTECTED], dammit

Re: Really auto autoloaded modules

2001-02-05 Thread David L. Nicol

use autoload { 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], dammit

  1   2   3   >