Re: Required Named Parameters Strike Back - P6 Summary Clarification

[John Siracusa]

From the recent P6 Summary:
   Larry's response is a masterpiece of conciseness:
 
  Well, actually, we saved you last summer when we decided to make +
  mean that the parameter must be named.

Larry's response also didn't really address the issue, since parameters
marked with a + in the signature are optional, not required.

   Discussion continued after this of course, but it was mostly concerned
   with making sure things worked as expected.

The continuing discussion revealed why it is not possible to check for
required params at compile time (well, for methods, anyway), but I still
wanted a way to tell Perl 6 to do runtime checks for me in response to a
particular signature.

Damian suggested an is required trait for signatures:

   sub foo(+$a is required, +$b is required) { ... }

which I'm all for, even if it is only a runtime check, but I'm not sure if
this is just one of Damian's Crazy Ideas(tm) or if it'll actually end up as
a standard part of the Perl 6 language.

-John

Re: Required Named Parameters Strike Back - P6 Summary Clarification

[Larry Wall]

On Wed, Apr 28, 2004 at 02:16:00PM -0400, John Siracusa wrote:
: ...but I'm not sure if this is just one of Damian's Crazy Ideas(tm)
: or if it'll actually end up as a standard part of the Perl 6 language.

I've never considered the two to be mutually exclusive.  :-)

Larry

This week's Summary

[The Perl 6 Summarizer]

  The Perl 6 Summary for the week ending 2004-04-25
And we're back on a weekly schedule again (unless the Mayday bank
holiday knocks me for six next week). As I expected, the Apocalypse has
brought out a rash of prophets and prognosticators in perl6-language,
but perl6-internals is still ahead on number of messages per week.

  Constant Strings
I confess I'm not sure I quite understand the constant strings patches
that Leo Tötsch and Jeff Clites were discussing. I understand the bottom
line though -- they make parrot a lot quicker when comparing constant
strings. Huzzah!

Then it turned into a discussion of Unicode (or at least, Parrot string
handling which is almost, but not quite, the same thing).

http://tinyurl.com/2mowl

  Parrot m4 0.0.4
Bernhard Schmalhofer posted a patch to bring his parrot implementation
of m4 up to what he's calling version 0.0.4

http://tinyurl.com/34be5

  SDL Parrot status
Portland Parrot stalwart, chromatic, posted a link to a SDL Parrot site
he's set up with current status, downloadable snapshots and other good
SDL Parrot related things.

http://tinyurl.com/2gcbs

  Passing arrays of structs to NCI subs
That man chromatic again, this time he asked if there was a secret
syntax for passing and retrieving arrays of things to and from NCI. Leo
noted that, according to the docs, there is no secret syntax, it's all
documented but unimplemented.

http://tinyurl.com/2xsrc

  PMC Constants
Last week, Leo asked for comments on his proposal for PMC constants.
This week, Dan replied. Essentially he's all for the idea, but wasn't
sure which implementation strategy was the best choice.

http://tinyurl.com/2ff8t

  Assign and set
Leo announced some changes he'd made to the behaviour of the set and
assign opcodes. Jens Rieks pointed out a case that he'd missed.

http://tinyurl.com/3bl4u

  hyper op - proof of concept
Leo also implemented what he described as a rather hackish and
incomplete new opcode called hyper. Dan liked it enough to suggest
that we should go the whole hog and add a hyper vtable to PMCs, with
hyper versions of all the standard vtable entries. He and Dan had a long
discussion of this, with contributions from various luminaries including
Larry. There was some debate as to whether we really needed overridable
hyper ops, but Dan's adamant that whatever happens they'll be
implemented in a vtable to allow for potential optimizations in some
cases.

http://tinyurl.com/37wqy

  Separating allocation and initialization of objects
Last week, Leo posted the latest object benchmarks, and things were
fast. But there was one test where Python was faster. Analysis of the
results and the code seemed to point the finger at Parrot's combined
allocation and initialization. This week Dan confessed that he was
leaning towards separating the two because that would allow for a
standard PCC call into the initialization code. He pointed out that
there were still a few issues, but that appears to be the way he's
thinking.

http://tinyurl.com/24h68

  Another config task
Dan pointed out that the current config scheme relies rather heavily on
flags set in the current perl install, which isn't ideal. He suggested
that people might like to look into making Parrot's config step rather
less Perl dependent and pointed at things like 'metaconfig'.

http://tinyurl.com/3xn29

  Problems with the Perl 6 Compiler
Allison Randal noted that languages/perl6/ was failing all its tests.
The issue arose because the Perl 6 test module inherits from
Parrot::Test, and Parrot::Test's behaviour got changed recently. She
wondered why the changes had been made. After some discussion, Allison
provided a patch to make things work with the new Test module.

http://tinyurl.com/2j3kp

  IMCC temp optimizations...
Dan is possibly the only person using Parrot in a commercial (mission
critical?) environment, using a compiler from a legacy language to
Parrot. He's currently experiencing problems with IMCC taking a long
time to compile the PIR generated by his compiler. Apparently it's
because he's using a lot of .locals and temps. He and Leo discussed it
back and forth to try and find optimizations (both of IMCC and of Dan's
compiler) for the issue. (Dramatic) progress was made.

http://tinyurl.com/3f9gq

  Korean character set information
Last week, Dan had wished he had access to anyone who knew anything
about Korean. This week kj provided some information. The ensuing
discussion of Unicode (again, maybe I'm going to have to extend my I
don't cover the Unicode arguments policy from perl6-language to the
internals list too) led Jarkko Hietaniemi to propose that Parrot's
standard character set be cuneiform, with Phaistos disc symbols for