Re: Magic blocks (was: Compile-time undefined sub detection)

[Dave Mitchell]

On Sat, Mar 06, 2004 at 06:39:44PM -0800, Larry Wall wrote:
 my @x will begin {...}  # at BEGIN time
 my @x will check {...}  # at CHECK time (redefined to unit check)
 my @x will init {...}   # at INIT time
 my @x will end {...}# at END time

Sorry, perhaps I wasn't paying close enough attention, but suddenly we've
leaped from oddly named subs that get called at interesting times, to
array variables with oddly-named properties (or attributes, or whatever).
Je ne comprend pas :-(.

Dave.

-- 
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.

Re: Magic blocks (was: Compile-time undefined sub detection)

[Larry Wall]

On Mon, Mar 08, 2004 at 11:57:04PM +, Dave Mitchell wrote:
: On Sat, Mar 06, 2004 at 06:39:44PM -0800, Larry Wall wrote:
:  my @x will begin {...}  # at BEGIN time
:  my @x will check {...}  # at CHECK time (redefined to unit check)
:  my @x will init {...}   # at INIT time
:  my @x will end {...}# at END time
: 
: Sorry, perhaps I wasn't paying close enough attention, but suddenly we've
: leaped from oddly named subs that get called at interesting times, to
: array variables with oddly-named properties (or attributes, or whatever).
: Je ne comprend pas :-(.

Oddly named subs are cool as such, but there are times when you
don't so much want an oddly named sub as an oddly named method.
These are just oddly named methods on the container in question
(which certainly doesn't have to be an array).  Underneath they're
still oddly named subs in terms of when they run.  But they implicitly
get (as their first argument/invocant/topic) the container in question,
so they can do fancy things with $_ and .foo and Cwhen and such.

The will first syntax is mentioned in A6.  Plus we discussed it
last April with respect to state variables--see message below.

Larry

From [EMAIL PROTECTED]  Tue Apr 15 11:56:23 2003
Date: Tue, 15 Apr 2003 11:19:42 -0700
From: Larry Wall [EMAIL PROTECTED]
Subject: Re: Initializations outside of control flow
To: [EMAIL PROTECTED]

On Tue, Apr 15, 2003 at 10:34:35AM -0400, Mark J. Reed wrote:
: It just seems like there should be a way to accomplish that without
: the visual clutter.  Perhaps a trait:
: 
:   my $count is initially($INITIAL_VALUE);
: 
: If there's already a defined way of doing that in Perl 6, please
: point me at it and I'll go away chastened but happy.   Otherwise,
: does this seem a reasonable approach?  Ideas for a better name for
: the trait?  

The traits in question are already named corresponding to the
various initialization closures, which at the moment are named

BEGIN {...}
CHECK {...}
 INIT {...}
FIRST {...}
ENTER {...}

so, since the variable in question is the topic of the closure, we have

my $count will begin { .set($INITIAL_VALUE) }
my $count will check { .set($INITIAL_VALUE) }
my $count will  init { .set($INITIAL_VALUE) }
my $count will first { .set($INITIAL_VALUE) }
my $count will enter { .set($INITIAL_VALUE) }

Perhaps those particular traits are smart enough to distinguish whether
they have a closure or not, and build an appropriate closure if not,
so we could also have

my $count is begin($INITIAL_VALUE)
my $count is check($INITIAL_VALUE)
my $count is  init($INITIAL_VALUE)
my $count is first($INITIAL_VALUE)
my $count is enter($INITIAL_VALUE)

At the moment, I believe that = always happens at run-time.  So

my $count = BEGIN { calculation() }

would do the calculation at compile time but assign the resulting
value every time the statement is executed.  This means that a
declaration like:

state $where = $x;

is almost certainly incorrect.  It should probably be one of

state $where is begin($x);
state $where is check($x);
state $where is  init($x);
state $where is first($x);

Could go so far as to lose the is, treating these as variants of
is.

state $where begin($x);
state $where check($x);
state $where init($x);
state $where first($x);

The other possible approach would be to allow blockless closures like

BEGIN (state $where = $x);
CHECK (state $where = $x);
 INIT (state $where = $x);
FIRST (state $where = $x);

Maybe the parens aren't necessary, if they just introduce a syntactic
statement:

BEGIN state $where = $x;
CHECK state $where = $x;
 INIT state $where = $x;
FIRST state $where = $x;

But I think it would be a mistake to have = running at random times
depending on either the foo and BAR in

foo $x = BAR { ... }

Larry

This week's summary

[The Perl 6 Summarizer]

The Perl 6 Summary for the week ending 2004-03-07
Time marches on, and another summary gets written, sure as eggs are eggs
and chromatic is a chap with whom I will never start a sentence. We
start, as always, with perl6-internals.

  Platform games
Work continued this week on expanding the number of known (and
preferably known good) platforms in the PLATFORMS file.

  Languages tests
Dan reckons it's time to be a little more aggressive with tests for
ancillary stuff, in particular the contents of the languages
subdirectory. He called for language maintainers (and any other
interested parties) to at least get minimal tests written for all the
languages in the languages directory, and to get those welded to the
languages-test makefile target.

http://tinyurl.com/24sd3

  IMCC and objects/methods
Tim Bunce congratulated everyone on Parrot 0.1.0 before asking about
where we stood with IMCC and objects/methods. Leo confirmed Tim's
supposition that there is no syntactic support for objects and methods
in IMCC, at least in part because there's been no discussion of how such
syntax should look.

http://tinyurl.com/2jerk

  Parrotbug reaches 0.0.1
Jerome Quelin responded to Dan's otherwise ignored request for a parrot
equivalent of perlbug when he offered an implementation of parrotbug for
everyone's perusal, but didn't go so far to add it to the distribution.
I don't think it's been checked into the repository yet, but it'll
probably go in tools/dev/ when it does.

Later in the week, he actually got it working, sending mail to the
appropriate mailing lists. With any luck the mailing lists themselves
will be up and running by the time you read this.

http://tinyurl.com/3fknl

  Subclassing bug
Jens Rieks found what looked like a problem with subclassing, which
turned out to be a problem with clone not going deep enough. Simon
Glover tracked it to its den and Dan Sugalski fixed it.

http://tinyurl.com/ysogd

  Good news! Bad news!
Good news! Dan says the infrastructure is in place to do delegated
method calls for vtable functions with objects. Bad news! It doesn't
actually work because it's impossible to inherit from delegate.pmc
properly. Dan pleaded for someone to take a look at pmc2c2.pl and or
lib/Parrot/Pmc2c.pm and fix things so that the generated code is
heritable.

http://tinyurl.com/2ouce

  Parrot m4 updated
Bernhard Schmalhofer posted a patch to improve the Parrot implementation
of the m4 macro language.

http://tinyurl.com/2aauu

  Use vim?
I don't use vim, but it seems that Leo Tötsch does. He's added some
handy dandy vim syntax files for IMC code. If you're a vim user you
might like to check it out. Leo points out that the syntax tables might
well be handy if you don't know all 1384 opcode variants by heart.

http://tinyurl.com/36gqv

  Parrotris
Sadly, Jens Rieks' Parrot and SDL implementation of tetris didn't quite
make it under the wire for the 0.1.0 release. However, Leo has got round
to trying it and is impressed, though he did spot a few bugs (it doesn't
spot that the game is over for instance). Jens is working on fixing
those (and on adding new features), which he reckons will go a deal
faster when IMCC has better syntactic support for OO techniques.

http://tinyurl.com/2hklm

  Dates and Times
To paraphrase Barbie: Dates and Times are Hard. Not that hardness has
ever stopped Dashing Dan Sugalski before. This time he waded into the
swamp that is Parrot's handling of dates, times, intervals and all that
other jazz. He started by soliciting opinions. He got quite a few.

The discussion can probably be divided into two camps: KISS (Keep it
Simple) people, and DTRT (Do The Right Thing) people. But KISS still has
it's complexities (which Epoch do we want? Should time be a floating
point value?) and what, exactly, is the Right Thing? The catch is, time
is a messily human thing, and computers are really bad at messy
humanity.

Larry said that Dan could do what he wants with Parrot, but he wants
Perl 6's standard interface to be a floating point seconds since 2000.
He argues that floating point will almost always have enough precision
for the task at hand, and by the time it doesn't, it will. :-). He also
argued that normal users should *never* have to remember the units of
the fractional seconds.

Zellyn Hunter pointed everyone at Dave Rolsky's excellent article on the
complexities of handling dates and times with a computer.

Discussion is ongoing, but it seems that Larry and Dan are leaning
towards the KISS approach.

http://tinyurl.com/3dqhn

http://tinyurl.com/ywcs9

  Initializers, finalizers and fallbacks
Anyone who has been reading the internals list for any length of time,
or who has chatted