Coupla Questions

[Simon Cozens]

I've been working on, uh, let's call it a "Perl 6 emulator" recently,
and I've come unstuck about a few things.

I'm sure I'll think of some more questions, but here we go for now:

Should properties interpolate in regular expressions? (and/or strings) I
don't suppose they should, because we don't expect subroutines to. 
(if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we need m//e)

What should $foo = (1,2,3) do now? Should it be the same as what 
$foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
$foo = \@INC; does now.) Putting it another way: does a list in scalar
context turn into a reference, or is it just arrays that do that? If
so, how can we disambiguate hashes from lists?

Currently I have:

% ./perl -l 
printf "This is Perl version %vd\n", $^V; 
%foo = (test=>"ok 1", test2=>"ok 3"); 
print %foo{test}; 
print "ok 2" if ref ($a=%foo); 
print $a->{test2}; 
print "ok 4" if ref @INC; 
print "ok 5" unless ref ($a=(1,2,3))'
This is Perl version 6.0.0
ok 1
ok 2
ok 3
ok 4
ok 5

Does that look right?

-- 
 Every little bit of seaweed kelps.

Re: Stacks, registers, and bytecode. (Oh, my!)

[Nick Ing-Simmons]

Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>I'm not entirely sure of that one--processing a full regex requires the 
>perl interpreter, it's not all that modular. Though whether being able to 
>yank out the RE engine and treat it as a standalone library is important 
>enough to warrant being treated as a design goal or not is a separate 
>issue. (I think so, as it also means I can treat it as a black box for the 
>moment so there's less to try and stuff in my head at once)

We are way past that point in perl5 - having tried to use perl's regexps
in a non perl app you need perl there, not the interpreter perhaps
by bits of the tokenizer and of course SV *.

So to make it modular in perl6 yoiu have to re-write it, and I am will 
Larry - lets make the main op-state machine handle those ops too.
That will help with need to special case regexps for signal despatch 
etc.

>
>*) It makes the amount of mental space the core interpreter takes up smaller

But surely we are considering "expandable" intepreter already?
Adding regexp ops is just one such extension.

>*) It can make performance tradeoffs separately from the main perl engine
>*) We can probably snag the current perl 5 source without much change

I doubt that.

>*) The current RE engine's scared (or is that scarred?) me off enough that 
>I'd as soon leave it to someone who's more tempermentally suited for such 
>things.
>*) Treating regexes as non-atomic operations brings some serious threading 
>issues into things.

Leaving them atomic does as well - I will switch threads as soon
as the regexp completes ...

-- 
Nick Ing-Simmons

RE: Should we care much about this Unicode-ish criticism?

[NeonEdge]

Before people get their panties in a bunch, I'm not dissing Unicode. The point
that I am trying to make is that Unicode will probably never make everyone
happy. It WILL likely become widely accepted, and should offer the best
solution yet to integrating the major character sets into one.

> If the author of the original paper referred to here thinks there are
> still significant characters missing from Unicode, he should stop whining
> about it and put together a researched proposal.  That's what the
> Byzantine music researchers did, and as a result their characters have now
> been added.  This is how standardization works.  You have to actually go
> do the work; you can't just complain and expect someone else to do it for
> you.

That wasn't the point. The only character set I ever expect to encounter (or
for that matter, support) is already in (Latin1). The point I was making is
that no matter what goes in, until everything is in there, in all type-cases,
someone won't be happy.

> It seems to me that you haven't bothered to go look at what Unicode is
> actually doing.

Actually, I have. Unicode is mapping characters to numeric values, but not ALL
of them. This is a quote from unicode.org's site: "Unicode provides a unique
number for every character, no matter what the platform, no matter what the
program, no matter what the language." Now we all know that isn't actually true
(at least not yet). If that was the goal, then they failed. If however, they
simply are trying to improve on the ascii character set, then they have done a
fine job. If at some point, they meet that goal, then I'll be truly impressed,
because I'm not sure that it's possible regardless of the mechanism.

Grant M.

Re: Should we care much about this Unicode-ish criticism?

[Simon Cozens]

On Wed, Jun 06, 2001 at 07:28:45AM -0400, NeonEdge wrote:
> If that was the goal, then they failed.

Oh, for heaven's sake, don't be silly. Our goal is to write Perl 6.
We haven't done that yet. That was our goal, so we failed?

-- 
"IT support will, from 1 October 2000, be provided by college and
departmental card locks." - J-P Stacey

Re: Properties and stricture

[John Porter]

Michael G Schwern wrote:
> It will have to go for strict classes.  @ISA will have to be locked.

"strict classes"?


> my $meth = "foo";
> $obj->$meth();  # $obj->foo();
> 
> This definately can't work if $obj is of a class which is strongly
> typed.

"strongly typed class"?



> This can still work with strong typing if:
> 1)  The class only plays with its own symbol table
> 2)  It does it at compile time.

I agree that an (optional) strong-typing mechanism would
be nice to have in perl6.  However, I don't think it
should not have a run-time component.
I.e. "strong typing can only be done at compile time".
We'll do what we can at compile time, but this is Perl...

-- 
John Porter

Re: Should we care much about this Unicode-ish criticism?

[Dan Sugalski]

At 06:59 PM 6/5/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 04:44 PM 6/5/2001 -0700, Larry Wall wrote:
>: >(Perl 5 extends it all the way to 64-bit values, represented in 13 bytes!)
>:
>: I know we can, but is it really a good idea? 32 bits is really stretching
>: it for character encoding, and 64 seems rather excessive.
>
>Such large values would not typically be used for standard characters, but
>as a means of embedding an inline chunk of non-character data, such as a
>pointer, or a set of metadata bits.

Ah. In that case, perhaps extended utf-8 processing isn't really the most 
appropriate way to go. If the intent is to do embedded binary bits in a 
text stream, maybe we should build input and output filters to do that instead.

>: And I
>: really, *really* want to do as little as possible internally with
>: variable-width encodings. Yech.
>
>Mmm, the difficulty of that is overrated.  Very seldom do you want to
>do anything other than find the next character, or the previous
>character, and those are pretty easy to do in utf8.

As Hong pointed out to me on more than one occasion. I'm not sure I buy 
that, and I have serious reservations about the speed of dealing with 
variable length characters instead of fixed-length ones. (Though I still 
need to build a test suite to benchmark that)

>: >They also arbitrarily define UTF-32 to not use higher values than
>: >0x10, but that doesn't mean we're gonna send in the high-bit Nazis
>: >if people want higher values for their own purposes.
>:
>: Well, that'd be inappropriate since a good chunk of the rest of the set's
>: been dedicated to future expansion. I think it might be a reasonable idea
>: for -w to grumble if someone's used a character in the unassigned range,
>: though. (IIRC there's a piece set aside for folks to do whatever they want
>: with)
>
>Certainly, but it's easy to come up with reasons to want to stuff more
>bits inline than the private use areas will support.

Maybe. That trips my "way too clever" reflex, though, and makes me think 
that perhaps it's not the best way to go about that sort of thing. Rather 
than making non-text things look like text, maybe we'd be better off coming 
up with a better way to intermingle text and non-text things. It'd be more 
space-efficient as well, since utf-8 encoding random binary things will 
tend to expand them more than would seem necessary.

>Rather than have
>-w grumble about such characters, I'd rather see an optional output
>discipline that enforces strict Unicode output.

Fair enough.

>On the other hand, maybe there's some use for a data structure that is
>a sequence of integers of various sizes, where the representation of
>different chunks of the array/string might be different sizes.  Would
>make some aspects of copy-on-write more efficient to be able to chunk
>strings and integer arrays.  And of course this would all be transparent
>at the language level, in the absence of explicit syntax to treat an
>array as a string or a string as an array.

I think that'd be a better solution than fibbing about what a piece of a 
data stream is.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Should we care much about this Unicode-ish criticism?

[Larry Wall]

Russ Allbery writes:
: Yeah, but one of the guarantees of UTF-8 is:
: 
:-  The octet values FE and FF never appear.
: 
: I can see that this property may not be that important, but it makes me
: feel like things that don't have this property aren't really UTF-8.

Which is one of the reasons I call it "utf8" instead.  I think of utf8
as a nice way to compactly store a sequence of arbitrarily sized
integers.  And you know I've never been particularly interested in
having Perl enforce arbitrary limits.  (Admittedly, in the particular
case of integer size, Perl has historically accepted some arbitrary
2**n limits to gain performance.)

I'm much more interested in the clean abstraction of "a string is a
sequence of integers" than I am in the fact that those integers happen
to represent particular characters under Unicode.  To be sure, it's
quite handy that those integers do represent characters, but (as has
been pointed out redundantly and repetitiously) the definition of
Unicode changes over time.

In contrast, the definition of integers doesn't change.  (At least, it
hadn't changed last time I checked...)

Larry

Re: Should we care much about this Unicode-ish criticism?

[Larry Wall]

Dan Sugalski writes:
: At 06:59 PM 6/5/2001 -0700, Larry Wall wrote:
: >Such large values would not typically be used for standard characters, but
: >as a means of embedding an inline chunk of non-character data, such as a
: >pointer, or a set of metadata bits.
: 
: Ah. In that case, perhaps extended utf-8 processing isn't really the most 
: appropriate way to go. If the intent is to do embedded binary bits in a 
: text stream, maybe we should build input and output filters to do that instead.

I see the issue of filters as orthogonal to the issue of representation.
In other words, I don't understand what you're saying.

: >Mmm, the difficulty of that is overrated.  Very seldom do you want to
: >do anything other than find the next character, or the previous
: >character, and those are pretty easy to do in utf8.
: 
: As Hong pointed out to me on more than one occasion. I'm not sure I buy 
: that, and I have serious reservations about the speed of dealing with 
: variable length characters instead of fixed-length ones.

Whether you buy it or not, I wasn't offering it as a mere conjecture.
That is precisely what Perl 5.6+ is already doing for Unicode data.
It's not a big deal unless your program is full of substr().  And it
saves on input processing, if the input is already known to be UTF-8.

: >Certainly, but it's easy to come up with reasons to want to stuff more
: >bits inline than the private use areas will support.
: 
: Maybe. That trips my "way too clever" reflex, though, and makes me think 
: that perhaps it's not the best way to go about that sort of thing. Rather 
: than making non-text things look like text, maybe we'd be better off coming 
: up with a better way to intermingle text and non-text things. It'd be more 
: space-efficient as well, since utf-8 encoding random binary things will 
: tend to expand them more than would seem necessary.

True 'nuff.  There are many valid reasons to want to annotate
substrings with various kinds of out-of-band metadata.  The trick
is to keep the out-of-band data in sync with the in-band data.

: >On the other hand, maybe there's some use for a data structure that is
: >a sequence of integers of various sizes, where the representation of
: >different chunks of the array/string might be different sizes.  Would
: >make some aspects of copy-on-write more efficient to be able to chunk
: >strings and integer arrays.  And of course this would all be transparent
: >at the language level, in the absence of explicit syntax to treat an
: >array as a string or a string as an array.
: 
: I think that'd be a better solution than fibbing about what a piece of a 
: data stream is.

If you want to attach the label "fib" to an intentional violation of
cultural convention, I suppose I can't stop you.  But Rosa Parks wasn't
pretending to be white when she sat in the front of the bus.  :-)

Larry

Re: Should we care much about this Unicode-ish criticism?

[David L. Nicol]

Dan Sugalski wrote:
> 
>  I've been
> assuming that an Anything->Unicode translation will be lossless, but this
> makes me wonder whether that assumption is correct.

I seem to recall from reading articles on this issue that the issue is
encoding of arrangement:  Even with an unlimited number of glyphs, unicode
remains one-dimensional and two-dimensional writing systems experience
transitional stress.

The rude solution is to insist that 2d writers use a 1d pidgin.  Not being
fluent in any 2d languages, I cannot invent examples.

Re: Coupla Questions

[Damian Conway]

   > So, to match $foo's colour against $bar, I'd say
   > 
   > $bar =~ /$foo.colour/;

No, you need the sub call parens as well:

 $bar =~ /$foo.colour()/;
  

   > Great, but how do I match $foo followed by any character followed by the
   > literal "colour"?
   
 $bar =~ /$foo.colour/;


   > Would I have to use "\Q"?

No. You could use the $(...) scalar interpolator instead:

 $bar =~ /$($foo).colour/;


   > >> print "ok 5" unless ref ($a=(1,2,3))'
   > ^^

Sorry, in my haste I missed that twist. You are, of course, correct.


   > >> Oh, hrm. Shouldn't it be $a{test2}?
   > > Yes. Or $a.{test}
   > 
   > So "." isn't necessarily the "property" operator, then? OK.
   > Time to spend more quality time with YACC. :(

Now there's an oxymoron, if ever I heard one. ;-)

Damian

Re: Coupla Questions

[Graham Barr]

On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote:
> 
>> So, to match $foo's colour against $bar, I'd say
>> 
>> $bar =~ /$foo.colour/;
> 
> No, you need the sub call parens as well:
> 
>  $bar =~ /$foo.colour()/;

Hm, I thought Larry said you would need to use $() to interpolate
a method call. So this would be


  $bar =~ /$($foo.colour)/;

Graham.

Re: Coupla Questions

[Damian Conway]

   > >> So, to match $foo's colour against $bar, I'd say
   > >> 
   > >> $bar =~ /$foo.colour/;
   > > 
   > > No, you need the sub call parens as well:
   > > 
   > >  $bar =~ /$foo.colour()/;
   > 
   > Hm, I thought Larry said you would need to use $() to interpolate
   > a method call. So this would be
   > 
   >   $bar =~ /$($foo.colour)/;

That was not my understanding. At least not for (pseudo-)method calls.
But many things are still in flux and I may well have missed a meeting. ;-)

Damian

Re: Coupla Questions

[Graham Barr]

On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote:
> 
>> >> So, to match $foo's colour against $bar, I'd say
>> >> 
>> >> $bar =~ /$foo.colour/;
>> > 
>> > No, you need the sub call parens as well:
>> > 
>> >  $bar =~ /$foo.colour()/;
>> 
>> Hm, I thought Larry said you would need to use $() to interpolate
>> a method call. So this would be
>> 
>>   $bar =~ /$($foo.colour)/;
> 
> That was not my understanding. At least not for (pseudo-)method calls.

But with the above you still have abiguity, for example what does this do

 $bar =~ /$foo.colour($xyz)/;

I may be remembering about interpolation into strings as "$file.ext" is
going to be common. But I do think the $() approach is clean and
unambiguous

Graham.

Re: Coupla Questions

[Larry Wall]

[EMAIL PROTECTED] writes:
:> What should $foo = (1,2,3) do now? Should it be the same as what 
:> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
:> $foo = \@INC; does now.) Putting it another way: does a list in scalar
:> context turn into a reference, or is it just arrays that do that?
: 
: Just arrays, I believe.

That hasn't actually been decided yet.  There are good arguments on
both sides.

Larry

Re: Coupla Questions

[Damian Conway]

   > But with the above you still have abiguity, for example what does this do
   > 
   >  $bar =~ /$foo.colour($xyz)/;

"Looks like a method call with parens, so *is* a method call with parens."

   
   > I may be remembering about interpolation into strings as "$file.ext" is
   > going to be common. But I do think the $() approach is clean and
   > unambiguous

I agree wholeheartedly. 

But it's not as *convenient* as "unadorned" interpolation.
Expecially if we expect method calls to be frequently interpolated.

Damian

Re: Coupla Questions

[Graham Barr]

On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
>> But with the above you still have abiguity, for example what does this do
>> 
>>  $bar =~ /$foo.colour($xyz)/;
> 
> "Looks like a method call with parens, so *is* a method call with parens."
> 
>
>> I may be remembering about interpolation into strings as "$file.ext" is
>> going to be common. But I do think the $() approach is clean and
>> unambiguous
> 
> I agree wholeheartedly. 

Good.

> But it's not as *convenient* as "unadorned" interpolation.

Sometimes convenient has to give way

> Expecially if we expect method calls to be frequently interpolated.

I don't hear people screaming because it's difficult in perl5, so I doubt
it will be very frequent. But even the $() is easier than the current
perl5 way to do it.

Graham.

Re: Coupla Questions

[Damian Conway]

   > > But it's not as *convenient* as "unadorned" interpolation.
   > 
   > Sometimes convenient has to give way

Here we differ. I think the frequency of the

/$var.ident(whatever)/

pattern is likely to be low enough that method interpolation is a
better use for the syntax.


   > > Expecially if we expect method calls to be frequently interpolated.
   > 
   > I don't hear people screaming because it's difficult in perl5,

Mainly because they use /$var->{raw_attribute}/, which we want to discourage.
And which won't be available on opaque objects.

   
   > so I doubt it will be very frequent.

Perl 6's interface is likely to be far more OO than Perl 5's, so this may not
be the case. For example: Perl 5's $#array syntax becomes something
like @array.length (i.e. a method call)
   

   > But even the $() is easier than the current perl5 way to do it.

There we definitely do agree :-)

Damian

Re: Coupla Questions

[Simon Cozens]

On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
> But it's not as *convenient* as "unadorned" interpolation.

Disagree. "Adorning" a piece of syntax reminds the programmer that
something out of the ordinary is happening. It's a mental speed limit
sign - a traffic light, if you like - that forces you to slow down to
work out what's really going on.

Briefly:
Complicated syntax is a GOOD THING for complicated semantics.

/foo.$bar.baz/can be accidentally speed-read as /foo.bar.baz/
/foo.$($bar.baz)/ means "Uhoh, something's going on".

-- 
Premature optimization is the root of all evil.
-- D.E. Knuth

Re: Should we care much about this Unicode-ish criticism?

[David L. Nicol]

Russ Allbery wrote:
> 
>  a caseless character wouldn't show up in
> either IsLower or IsUpper.


maybe an IsCaseless is warrented -- or Is[Upper|Lower]
could return UNKNOWN instead of TRUE|FALSE, if the
extended boolean attributes allow transbinary truth values.

Re: Should we care much about this Unicode-ish criticism?

[Russ Allbery]

David L Nicol <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> a caseless character wouldn't show up in either IsLower or IsUpper.

> maybe an IsCaseless is warrented -- or Is[Upper|Lower] could return
> UNKNOWN instead of TRUE|FALSE, if the extended boolean attributes allow
> transbinary truth values.

Well, UNKNOWN isn't accurate either; the case *is* known.  It's just
neither upper nor lowercase.

(I wonder what it should return for titlecase characters too, for that
matter.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Should we care much about this Unicode-ish criticism?

[Simon Cozens]

On Wed, Jun 06, 2001 at 09:57:58AM -0400, NeonEdge wrote:
> Perl 6 cannot assume that Unicode is done. 

Don't tell anyone, but it never did.

-- 
Thus spake the master programmer:
"After three days without programming, life becomes meaningless."
-- Geoffrey James, "The Tao of Programming"

RE: Should we care much about this Unicode-ish criticism?

[NeonEdge]

> Oh, for heaven's sake, don't be silly. Our goal is to write Perl 6.
> We haven't done that yet. That was our goal, so we failed?

Don't be ridiculous. With that as our goal, the ONLY way we could fail is to
NEVER write Perl 6. Unicode, on the other hand, was originally released for
public consumption way back in 1991. There are 10 additional releases since
then. None of which have been 'complete' solutions.
There's nothing 'wrong' or 'bad' with an incomplete solution, provided that we
don't assume that it is one. Perl 6, as Perl 5, will be an 'incomplete'
solution by itself, but I wouldn't have it any other way :-). If it was to be a
complete solution, we could name it Perl "Unicode character 221E" ;-).
This will not be resolved here. There will be many more papers on how Unicode
fails to include this or that character or sets, and there will also be papers
on how "such-and-such" shouldn't be 'worthy' of inclusion. That's the process.
All that I'm saying is that we shouldn't assume this to be the end-all-be-all.
Perl 6 (and every other version of Perl) needs to make as few assumptions as
possible about what it will be handed, and should make considerations for the
next "big thing".

Grant M.

Re: Should we care much about this Unicode-ish criticism?

[Simon Cozens]

On Wed, Jun 06, 2001 at 09:06:09AM -0400, NeonEdge wrote:
> > Oh, for heaven's sake, don't be silly. Our goal is to write Perl 6.
> > We haven't done that yet. That was our goal, so we failed?
> 
> Don't be ridiculous. With that as our goal, the ONLY way we could fail is to
> NEVER write Perl 6. 

Exactly. Same goes for Unicode. And pretty much every other standard, in
fact. These things evolve. They're *never* done. I don't see anyone
claiming that they *are* done, but I see you telling us that they should
be regarded as a failure if they're not done. Uh, great. So they're
incomplete. So what?

-- 
In this talk, I would like to speculate a little, on ... the development
of intelligent life. I shall take this to include the human race, even
though much of its behaviour throughout history has been pretty
stupid... - Stephen Hawking

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

[John Porter]

David L. Nicol wrote:
> it isn't currently in 5.6.1's
> 
> bool
> Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen)
> 
> function (contrary to what John Porter said) 

Huh?  What did I say?::

-- 
John Porter

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

[Me]

> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> > 
> > $foo.Foun
> > 
> > refers to an undeclared Foun.
> 
> it is already detectable.  from perldoc perlref:

Perhaps for perl 5, but, aiui, Damian confirmed
that my thinking about Perl 6 was correct.

> Although other discussion in the thread indicates that
> we may be confusing properties and member fields.

My concern was user defined variable and value properties.

(Though part of my reason for that concern was that whatever
limits on stricture might apply to any one member of the joint
property and method namespace might also have to apply
to the others.)

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

If that's so, I am totally confused.

Re: Properties and stricture

[Dave Storrs]

On Tue, 5 Jun 2001, Michael G Schwern wrote:

> On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote:
> > I cannot imagine running an enterprise critical application
> 
> As a complete digression, can we please strike the term "enterprise"
> from the English lexicon?  Completely redundant and drives me up the
> wall.  Almost as bad as "ecommerce".

But if we did, how could we hope to get a good new Star Trek
series? :>


Dave

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

[Daniel S. Wilkerson]

Damian Conway wrote:

> I very much doubt Perl is going to become significantly more statically
> analyzable in general. Though static determinacy is obviously a
> desirable thing, there are plenty of other B&D

Bondage and Discipline?

> languages that offer it
> in abundance. And the dynamic power that Perl would have to lose would not
> compensate for the static benefits gained.
>
> Damian
>
> PS: Of course, as always, Larry's MMV on that ;-)

Main Man Vote?


One of the major features of Perl is that it can cross between "data" and
"code" so easily (eval, inserting into the namespace at runtime, changing the
inheritance tree at runtime, computed method calls, computed gotos, etc.).
I knew this, but it is rather amazing how many different examples of this
people used against my arguments for "strong" type checking at compile time.

What about a trade-off between compile time checking and run time checking?
I think everyone agrees that if something is going to fail, it is better for
you to find this out sooner rather than later.  Compile time is sooner, run
time is later, and when the IRS audits a customer who's taxes were done wrong
because of a subtle data corruption bug you never caught in testing is even
later.  Can we move the time when you catch the type failure error at least
somewhat sooner, even if we can't get it all the way to compile time?  Perl
already has other intermediate "times".  For example, the BEGIN block code is
run during compile time.

I suggest that for most programs you could "factor out" all of the
data-to-program bits of your code (that prevent compile time checking) into
an initial phase of your program.  After that phase is ended (all the
autoloading is done, inheritance tree modified, whatever) you run the
"compile time" checker on your own program, perhaps giving it a set of
sentences to verify, such as "This class/package is sealed".  If there is a
type failure, at least you get the error right then, before you tell the
robot to pick up the car.  Assertions are good for checking that *data* has
properties I expect.  If data can be come program (as in Perl), I want
assertions that my *program* has properties I expect.

For those of you who love code that manipulates its own internals, you can
see such "assertions about the program" are a kind of introspection into your
own parse tree.  People have written compilers that first parse and then
allow your custom plug-in to check properties of the parse tree.  These
"assertions about the program" could be implemented that way.  First you call
"parse", which is used just like the current "eval", but instead returns the
parse tree.  Then have your own routines traverse over the tree and verify
any properties your heart desires.  A few standard ones implementing, say,
sealed classes, would of course show up on CPAN.

This strategy would of course require a "parse" to produce a nice parse tree
data structure, with all the compile time properties conveniently attached.
It would also be nice if afterward, you could turn off some/all of the
data-to-program features, like namespace manipulation.

Daniel

Re: Coupla Questions

[Simon Cozens]

On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote:
> print $a->{test2}; 

Oh, hrm. Shouldn't it be $a{test2}? That works too, at any rate.
Does that mean that arrow between variable and subscript is optional,
or should this be some kind of error? Or should it mean something else
altogether?

-- 
It starts like fascination, it ends up like a trance
   You've gotta use your imagination on some of that magazine romance
And these bones--they don't look so good to me
   Jokers talk and they all disagree
One day soon, I will laugh right in the face of the poison moon  

Re: Properties and stricture

[Piers Cawley]

"Daniel S. Wilkerson" <[EMAIL PROTECTED]> writes:
> Michael G Schwern wrote:
> > No subroutine refs.  No dynamic inheritance.  No autoloading.  No
> > dynamic method calls.  No symbol table manipulation.  No eval.  No
> > automatic method generation.  (That's off the top of my head).
> 
> You don't loose all of these. Java has interfaces, and then any
> class, even loaded at compile time, that satisfies an interface is
> allowed to be used in its place. This is as good as subroutine refs
> (and in general object refs) that are checked at compile time, but
> where the implementation shows up at run time.

Um... how is this as good as a subroutine reference? I confess that I
fail to see it.

You do realise that not having subroutine references kills all sorts
of useful stuff. Apache::Registry springs to mind. 

> Dynamic inheritance, is that messing with the inheritance tree at
> runtime? I've never found a need for that. I think a lot of these
> features are just bad habits that people may use but they don't
> realize that they don't really need (like computd gotos). I've never
> used that, if I'm understanding you.

Dynamic inheritance is definitely scary. Fun, but scary. Using it in
production code would definitely be scary. Then again, having a state
token which you rebless to change the state has some good stuff going
for it...

> Java allows you to load classes at runtime. The interface /
> implementation matching is checked then. No, you can't do many of
> the tricks that you can in Perl, like having autoload implement
> methods for you that don't really exist lexically, etc. Again, this
> would only not be allowed in "strict-type-checking". So, you give it
> up only if you want to.

Hopefully, with strict-type-checking on you'd be able to predeclare
subroutines that are implemented via AUTOLOAD:

sub foo ();

> Not sure what a dynamic method call is. Virtual method calls,
> perhaps? Java has these.

What's a 'virtual method call'?

A dynamic method call looks something like:

my $method = compute_methodname(@_);
$object->$method();

Remarkably useful sometimes.

> Symbol table manipulation is for me another "computed goto"
> something I don't think I'll ever want. Again, you only give it up
> in the special mode.

You never use a modules that use the Exporter? Wow. Or wrote an
AUTOLOAD that loaded deferred methods into the module symbol table?

> No eval of strings, you mean. eval of blocks is fine: eval {}; if
> ($@) { etc.}. Eval of strings seems like a very local thing that I
> would rarely want to eval large chunks of code in. Perhaps it could
> throw a "type checking failed" exception that you could catch
> outside the eval.

No eval of strings kills things like the Template Toolkit (Assuming it
hasn't been killed big time by the 'no subroutine refs' thing...),
which definitely evals 'large chunks of code' within strings.

> Automatic method generation. Again, never found the need, and you
> only give it up if you want to.

Personally I reckon that having Automatic method generation is *way*
better than violating the DRY principle to build a maze of twisty
little accessor methods, all different.

> > Every class in the hierarchy has to be defined and loaded
> > completely at compile time (well, at least their method
> > signatures) and defined strictly. If there's a class which isn't
> > strictly defined anywhere in your hierarchy, no go.
> 
> Yes, that's the point.

Hmm... I think you just killed mod_perl.

> > Also, since you're doing so much more work at compile time, any
> > strictly typed code will probably have to be pre-compiled or else
> > be sluggish to startup (this is just a guess).
> 
> Again, for large applications, one expects them to be pre-compiled.

Does one? Are you using perl for large applications? I am and they're
definitely not precompiled.

> > An optional strict typing system would be nice, but I just want
> > you to be aware how difficult it will be to do right, and what you
> > give up by using it. This isn't just a "let's toss this in" sort
> > of feature.
> 
> Yes, its not easy to do right, and it is very helpful. Certainly
> worth it in my opinion.

The system you proposed doesn't appear to be doing it right. Too many
babies get thrown out with the bath water. I love the compile time
optimization possibilities that come with static type checking, but
there has to be some way of allowing us keep Perl's flexibility whilst
still seeing some of those gains.

Personally, what I'd like to see is a system that does as much type
based optimization as it can at compile time. If dangerous ops happen
later that could affect all the optimizations, then the various
optimization caches (yeah, I'm being *very* fuzzy here, I'm not
enormously up on the technology so let me wave my hands a bit)
affected need to get flushed and perl has to go back to doing things
the old, slow way.

However, I would hope that some optimizations will be of the
'calculate once, use many' typ

Re: Properties and stricture

[Piers Cawley]

Michael G Schwern <[EMAIL PROTECTED]> writes:
> Consider the following... Foo is a poster-child for a strict class.
> Everything is predeclared and typed.  Its entire hierarchy is rock
> solid.  Someone uses Foo in their script and calls Foo->bar.  They
> also use Bar, a module you installed a long time ago.  Bar does this:
> 
> package Bar;
> eval "sub Foo::bar { 23 }";
> 
> Oh crap!  All the wonderful compile-time checking we did on Foo has
> just been blown to pieces.

Well, if Damian's suggestions for strict classes in perl 5+i becomes
anything more than fiction then that eval will throw an exception.

-- 
Piers Cawley
www.iterative-software.com

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

[David L. Nicol]

Since this thread made it into this week's Official Perl6 Summary,
here goes a defense of C as a shorthand for the thing that last
had C or C queried of it.

It (by which I mean C, 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. C 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 C construct and reassigning C<$_> might be
longer than referring to a defined-specific magic variable.

 
> which also scales rather nicely:
> 
> return $_ for grep{defined} $thing, $otherthing, $somethingelse;

This does not help in the case of a long, unrolled routine which is to
return the first sensible parse of something.  Although with a
short-circuiting
grep this would work, and be a nice controlling abstraction too.


 
> As for the original problem of:
> 
> 1 until defined(getvalue()); return it;
> 
> You can already write:
> 
> 1 until defined($_=getvalue()); return $_;
> 
> which doesn't seem a huge extra burden.

I want the assignment done behind-the-scenes, rather
than by explicit programmer action.
 
I hereby revise my proposal from a bareword to a Line Noise Variable,
so that this interesting but rarely used feature, like other similar ones,
for instance $?.

Re: Coupla Questions

[Damian Conway]

   > Should properties interpolate in regular expressions? (and/or strings)

Do you mean property look-ups via the pseudo-method syntax?
In that case, yes they should


   > I don't suppose they should, because we don't expect subroutines to. 
   > (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we need m//e)

Err. I *would* expect sub call iterpolation in regexes, since they will
interpolate in qq{...} contexts, and that's what a regex basically is.

But what you showed is not the syntax for it:

 /bar($baz,$quux)/; # match bar then match-and capture
# matches of interpolated value of $baz,
# a comma, interpolated value of $quux

 /&bar($baz,$quux)/;# match interpolated value of call to
# bar with two args


   > What should $foo = (1,2,3) do now? Should it be the same as what 
   > $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
   > $foo = \@INC; does now.) Putting it another way: does a list in scalar
   > context turn into a reference, or is it just arrays that do that?

Just arrays, I believe.
   
   > Currently I have:
   > 
   > % ./perl -l 
   > printf "This is Perl version %vd\n", $^V; 
   > %foo = (test=>"ok 1", test2=>"ok 3"); 
   > print %foo{test}; 

Yes

   > print "ok 2" if ref ($a=%foo); 

Yes. Though C would be a better test

   > print $a->{test2}; 

die "Unexpected > after subtraction operation. Did you mean $a.{test2}???"

   > print "ok 4" if ref @INC; 

Yes

   > print "ok 5" unless ref ($a=(1,2,3))'

No. Equivalent to ref($a=3), I believe

   > Does that look right?

60% right, at least. ;-)

 
   > > print $a->{test2}; 
   > 
   > Oh, hrm. Shouldn't it be $a{test2}?

Yes. Or $a.{test}
   
   > That works too, at any rate.
   > Does that mean that arrow between variable and subscript is optional,

There is no arrow. Only dot.

And yes, it's optional anywhere the dot acts like a /\b/ boundary:

$ref.[1]can be  $ref[1]
$ref.{a}can be  $ref{a}
$ref.(@args)can be  $ref(@args)
$ref.meth() CAN'T be$refmeth()


Disclaimer: Rules #1 and #2 apply to all of the above.

Damian

Re: Coupla Questions

[Simon Cozens]

Thanks *very* much for your answers; I still have a lot of work left
to do, it seems. But I'm still a little confused:

On Thu, Jun 07, 2001 at 06:08:23AM +1000, Damian Conway wrote:
>> Should properties interpolate in regular expressions? (and/or strings)
> Do you mean property look-ups via the pseudo-method syntax?
> In that case, yes they should
 
So, to match $foo's colour against $bar, I'd say

$bar =~ /$foo.colour/;

Great, but how do I match $foo followed by any character followed by the
literal "colour"? Would I have to use "\Q"?

> Err. I *would* expect sub call iterpolation in regexes, since they will
> interpolate in qq{...} contexts, and that's what a regex basically is.

Fair enough.

>  /&bar($baz,$quux)/;  # match interpolated value of call to

Ah, good. Much easier to parse.

> Just arrays, I believe.

Good, that's what was planning on.

>> print $a->{test2}; 
> die "Unexpected > after subtraction operation. Did you mean $a.{test2}???"

Urgh. OK, arrow is dead. That also makes things easier. Probably.

>> print "ok 5" unless ref ($a=(1,2,3))'
^^
> No. Equivalent to ref($a=3), I believe

Since ref($a=3) is undef, that should print "ok 5".

>> Oh, hrm. Shouldn't it be $a{test2}?
> Yes. Or $a.{test}

So "." isn't necessarily the "property" operator, then? OK.
Time to spend more quality time with YACC. :(

-- 
"If you want to travel around the world and be invited to speak at a lot
of different places, just write a Unix operating system."
(By Linus Torvalds)

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

[Simon Cozens]

On Wed, Jun 06, 2001 at 02:20:25PM -0500, David L. Nicol wrote:
> this is a confusing hack that might not save any cycles.

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 $&?

-- 
You advocate a lot of egg sucking but you're not very forthcoming with the 
eggs. - Phil Winterbottom (to ken)

Re: Coupla Questions

[Brent Dax]

Graham Barr <[EMAIL PROTECTED]>:
>On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
>> [EMAIL PROTECTED] writes:
>> :> What should $foo = (1,2,3) do now? Should it be the same as what
>> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC
does what
>> :> $foo = \@INC; does now.) Putting it another way: does a list in
scalar
>> :> context turn into a reference, or is it just arrays that do that?
>> :
>> : Just arrays, I believe.
>>
>> That hasn't actually been decided yet.  There are good arguments on
>> both sides.
>
>Can someone post a few ? I am open to what are the pros/cons
>but right now my mind is thinking " Whats the benefit of making
>$a=(1,2,3); be the same as $a=[1,2,3];  when it could do something
>different, ie what it does in perl5"

I'm wondering if () should keep its functionality as a list composer at all.
Perhaps it should just be:

$foo=($a, $b);  #$foo is equal to $b
$foo=[$a, $b];  #$foo is an array ref
$foo={$a, $b};  #$foo is a hash ref

@foo=($a, $b);  #same as @foo=$b (what would that do?)
@foo=[$a, $b];  #@foo is an array containing $a and $b
@foo={$a, $b};  #@foo is an array containing $a, '', $b, '' (?)

%foo=($a, $b);  #same as %foo=$b (what would that do?)
%foo=[$a, $b];  #%foo is a hash containing $a => $b (?)
%foo={$a, $b};  #%foo is a hash containg $a => '', $b => '' (?)

Thus,
($a, $b)=($c, $d);  #$b=$d
[$a, $b]=[$c, $d];  #$a=$c; $b=$d; (except inline)
{$a, $b}={$c, $d};  # ???

This means that each of the wraparound things has exactly one meaning,
regardless of context.  It also gives () back its C meaning, grouping stuff
together so it'll be evaluated first, instead of a meaning that can be
different in different contexts.  (In general, I think that "syntactic
operators" like parenthesis and comma should behave the same regardless of
scalar/list context, while functions should behave differently.  That's just
my bias, though.  Feel free to laugh at me if I'm wrong here.)

--Brent Dax
[EMAIL PROTECTED]

Re: Coupla Questions

[David L. Nicol]

Damian Conway wrote:

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


which can also be

$ref.a

can it not?

Re: Properties and stricture

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


Me: 

Oh please.  If it makes no sense one way, reparse.  I had
no trouble at all binding Michael's "myself" into
"many people" and neither did you, unless someone has recently
lobotomized you with a guitar pick.

OTOH, you may have been making a point about strict syntax-based
parsing, in which case I may be in a minority in misperceiving
your post as the worst case of smartassery I've seen this month.

"closed" property ((was Re: $foo.Foun ((was Re: Properties and stricture

[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/SMERSH.sd');
swallow(my $agent_list_mod_key = (is open %SMERSH_agent_identities);)
%SMERSH_agent_identities is closed;

Mallory can't defame a good agent by modifying this list of bad
agents without setting it to not closed, he can't do that without
getting the key, and the key has been swallowed (whatever that means.)


Even more compact would be the setting to closed returning the capability.

package reflexive;

# prevent modification to %reflexive:: like so:
my $opener = (%reflexive:: is closed);

# re-allow modification like so:
&$opener;


-- 
   David Nicol 816.235.1187
 Keep Dan Sugalski away from my stuffed animals

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

[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
> 
> $foo.Foun
> 
> refers to an undeclared Foun.
> 
> Right?


it is already detectable.  from perldoc perlref:

   Perl will raise an exception if you try to access
   nonexistent fields.  To avoid inconsistencies, always use
   the fields::phash() function provided by the "fields"
   pragma.



Although other discussion in the thread indicates that we may
be confusing properties and member fields.


as I understand it, .foo has been proposed to replace ->{foo} and
we're talking about fields, not properties.

Property access has got to be something else.  Last year's code pitched
to the perl6-data list generally used a colon for that; use of "is" as the
property assignment operator invites and suggests 

$foun_status_of_foo = (is $foo foun);

to access the status of the foun property of foo, should such exist and be
defined
et cetera. Maybe there will be a distinction between notexist and notdef. 
I know the
SQL people want an explicit "unknown" value.

And we're in blue sky territory for the stricture.



-- 
   David Nicol 816.235.1187
 Keep Dan Sugalski away from my stuffed animals

Re: Coupla Questions

[Graham Barr]

On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote:
> On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
> > Can someone post a few ? I am open to what are the pros/cons
> > but right now my mind is thinking " Whats the benefit of making
> > $a=(1,2,3); be the same as $a=[1,2,3];  when it could do something
> > different, ie what it does in perl5"
> 
> A reason against making the behaviours ($foo=array vs. $foo=list)
> different would be that you're then making lists and arrays more
> distinct than necessary. Does this make $foo a reference, or the number
> of elements:

But if you change () consider, how do you do 

  $min = (localtime(time))[1];

and if () creates a reference what does

  $x = (1 + 2) * 3;

it's still () in a scalar context.

IIRC when Larry covered this, he did not suggest changing (), but changing the meaning
of the , in the scalar context.

() is a grouping contruct, not a list generator.

Graham.

Re: Coupla Questions

[Graham Barr]

On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> :> What should $foo = (1,2,3) do now? Should it be the same as what 
> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
> :> $foo = \@INC; does now.) Putting it another way: does a list in scalar
> :> context turn into a reference, or is it just arrays that do that?
> : 
> : Just arrays, I believe.
> 
> That hasn't actually been decided yet.  There are good arguments on
> both sides.

Can someone post a few ? I am open to what are the pros/cons
but right now my mind is thinking " Whats the benefit of making
$a=(1,2,3); be the same as $a=[1,2,3];  when it could do something
different, ie what it does in perl5"

Graham.

Re: Coupla Questions

[Simon Cozens]

On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
> Can someone post a few ? I am open to what are the pros/cons
> but right now my mind is thinking " Whats the benefit of making
> $a=(1,2,3); be the same as $a=[1,2,3];  when it could do something
> different, ie what it does in perl5"

A reason against making the behaviours ($foo=array vs. $foo=list)
different would be that you're then making lists and arrays more
distinct than necessary. Does this make $foo a reference, or the number
of elements:

$foo = (@bar=(1,2,3));
or this:
$foo = @bar = (1,2,3);

But on the other hand, what about?
$foo = (1,2,3);
@bar = (1,2,3); $foo = @bar;   # Array in scalar context, so ref?
@bar = (1,2,3); $foo = (@bar); # "List" in scalar context, so number?
($foo) = @bar; # Array in list context, ...?
($foo) = (@bar); # List in list context, ...?

But then, what does this do?
$foo = (3, 4, @bar, 5); 
Is the 2nd element treated as a "scalar context", so you get a reference to
@bar in there, or does list flattening still apply?

See, if you make $a=(1,2,3) take a reference just like $a=[1,2,3], this
frees up [] for something else. You could have () for flattening and []
for non-flattening lists. (Something somehow seems LISP-like about that
idea, but it's been too long...)

So that's an argument for, uh, something me going to sleep, I think.

Oh, one last thing: is
$a = @foo; # Perl 6
equivalent to
$a = [ @foo ]; # Makes a copy
or
$a = \@foo; # Takes a direct reference
?

The former extends to lists, the latter doesn't.

-- 
I don't understand how people can think SCSI is anything more quirky
than a genius with peculiar dietary requirements in a world where the
creators of Notes, and their new owners, are allowed to walk the streets
without fearing for their very lives. - Graham Reed, asr

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

[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

bool
Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen)

function (contrary to what John Porter said) but adding it,
as extended defined/exists that Only Gets Called When It
Immediately And Obviously Precedes Use Of The Magic Variable,

would save the later lookups.

This is a "Little thing that can just be thrown in" and is nothing
more than that.

Making $', $`, and $& lexically scoped too could solve their
performance hit issues too.  They're convenient.

Re: Coupla Questions

[Simon Cozens]

On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> Damian Conway wrote:
> > $ref.{a}can be  $ref{a}
> which can also be
>   $ref.a

Dereferencing a hashref is the same as accessing a property?
I hope not.

-- 
Did you know that 1 barn yard atmosphere = 9.2e-17 erg?

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

[Simon Cozens]

On Wed, Jun 06, 2001 at 07:21:19PM -0500, David L. Nicol wrote:
> No, this datum is already known by defined() and exists() all I
> am suggesting is a name for the Perl API name for it. 

Sorry, I didn't read your original post thoroughly enough; yes,
one for defined and exists would be feasible, but IMHO ultimately
pointless.

And you could probably do it in pure Perl anyway by overloading
the ordinary defined and exists operators, so there isn't much need
for it in the core.

> Well, it isn't currently in 5.6.1's
> bool
> Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen)

Eh, you probably mean pp_exists, since exists doesn't just act on hashes.

> Making $', $`, and $& lexically scoped too could solve their
> performance hit issues too.  They're convenient.

Could it really? Have you tried to implement this?

-- 
This week I will definitely have passed the Administrative Event Horizon:
when you spend quite a few more hours doing silly corporate bullshite than
anything remotely technical or to do with the administration of systems.
- Red Drag Diva

Re: Properties and stricture

[Me]

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

> > It could work in perl when perl is being used in an
> > FP manner; that would indeed be very Perlish.
> 
> Yes!  That would be a magic trick I'd love to see.

Indeed.