Returning from Rules

[Luke Palmer]

I notice that when I write a grammar, I end up doing this an awful lot
(in P::RD notation):

list: term ',' list { make_node(@item[0,1,3]) }
| term  { $item[1] }

With attention on the actions, and assuming  is on.

In Perl 6, aside from the fact that there's a clearly better way to
write this rule, this would be translated:

rule list {
 ,  { $0 = make_node('list', $?term, $?list) }
  |{ $0 = $?term }
}

The part that I'm complaining about in this mail is C<$0 = >.  While
it's only three extra characters, I believe that it is a large hindrance
to readability.  However, we can reclaim this readability by noticing
that the construct:

<{ get_rule() }># call an anonymous rule returned by the code block

Can also be written:

<$( get_rule() )>

Because of the interpretation of:

<$somerule>

Therefore, the first syntax can be redefined to evaluate the code block
and assign the result to $0.  The example now becomes:

rule list {
 ,   <{ make_node('list', $?term, $?list) }>
  | <{ $?term }>
}

My argument for using this notation stems from the fact that it would
be a royal pain to write subs like:

sub add ($a, $b) {
$RET = $a + $b;
}

Even though it's just a few extra characters.  I don't want to think
about replacing the current parse tree node, I just want the rule to
represent a value.  An assignment has little place there.

Luke

A12: Mutating Methods and hyperoperators

[Matthew Walton]

I know these were discussed to death not that long ago, but reading 
Apocalypse 12 I had a query I couldn't remember if it had been covered 
before or not, and I certainly don't recall seeing it in the Apocalypse, 
although I've not read the entire thing with as much attention as I 
might like yet (it's great work though).

So, simple query. I know I can do

@things».method();

But can I do

@things».=method();

which would presumably be the same as

map { .=method() } @things;

And if I can't do it, why not? I think I should be able to do it, but 
it's entirely possible I've missed something, because I usually have.

Thanks

Matthew

Re: A12: Mutating Methods and hyperoperators

[Luke Palmer]

Matthew Walton writes:
> I know these were discussed to death not that long ago, but reading 
> Apocalypse 12 I had a query I couldn't remember if it had been covered 
> before or not, and I certainly don't recall seeing it in the Apocalypse, 
> although I've not read the entire thing with as much attention as I 
> might like yet (it's great work though).
> 
> So, simple query. I know I can do
> 
> @thingsÂ.method();
> 
> But can I do
> 
> @thingsÂ.=method();

Of course.

> which would presumably be the same as
> 
> map { .=method() } @things;
> 
> And if I can't do it, why not? I think I should be able to do it, but 
> it's entirely possible I've missed something, because I usually have.

Not this time :-)

Luke

Re: Apocalypse 12

[Mark A. Biggar]

Brent 'Dax' Royal-Gordon wrote:

chromatic wrote:

Perl.com has just made A12 available:


I started reading it last night, and ended up going to bed before I was 
finished.  But I just wanted to say that this:

With this dispatcher you can continue by saying "next METHOD".

is the sort of genius that makes me glad Larry's designing this 
language.  Well done!

Yeah, remmeber from A4 that flow control stuff like "next", "leave",
"return" are semantically a form of exception throw and so are actaully 
dymanically (not lexically) scoped (although the compiler is free to
optimize if the target is in the lexical scope of the construct or
vice versa).

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: A12 Q: Pointer-to-member-function behavior?

[Larry Wall]

On Sat, Apr 17, 2004 at 11:52:19AM -0400, Austin Hastings wrote:
: Is it permissible to use variable dispatch for private methods?

Don't see why not, as long as the overhead of switching isn't imposed
on every method call.

: class Cerebellum {
:   method :think() {...}
:   method :ponder() {...}
:   method :cogitate() {...}
: 
:   method some_method() {
: ...
: $activity = «:think, :ponder, :cogitate».random;

s/,//g

: $brain.$activity;
:   }
: }
: 
: Or would the colons be on the invocation, not the name?

Could be made to work either way.

: PS: Sorry, Piers.

He can just ignore this thread if he thinks it's too much.  But Piers
really shouldn't carp--the backticks thread is highly compressible...  :-)

Larry

A12 undef method calls

[Luke Palmer]

A12 mentions that C<$foo.bar> should return undef if C<$foo> is undef.
While I like the idea a lot, I don't think it should happen without
distinction.  In fact, that's what I would most expect C<.?> to do, not
"call a method if there is one," though that seems useful, too.

I'm just shooting in the dark here, but perhaps C should play that
role.  That way you have:

$foo.?bar  # return undef if "bar" is undef... in a manner of speaking
$foo?.bar  # return undef if $foo is undef
$foo?.?bar # return undef if either is (?)

Either that or C<.?> could double as both roles, considering C
an object with no methods.

And I can't figure out for the life of me why you'd ever want to use
C<.+>...

Luke

Re: A12: Mutating Methods and hyperoperators

[Matthew Walton]

Luke Palmer wrote:

Matthew Walton writes:
But can I do

@things».=method();


Of course.
Excellent. Thankyou.

Not this time :-)
Next time then, probably.

placeholder attachment?

[Trey Harris]

Can anyone explain the rules of placeholder attachment?  i.e., in the
example in Perl6::Placeholder's manpage,

  grep { $data{$^value} } 1..10;

C<$^value> is clearly intended to attach to the outer closure C<{
$data{$^value} }>, not the inner closure C<{$^value}>.  But how does the
compiler know?  What is the general rule?

It's easy to just say "don't nest placeholder-using closures," but that
doesn't seem workable in practice since every block is a closure, unless
placeholders are forbidden from all but the most trivial cases.  Absurdly
trivial, it seems.  How about

  $sub = { if $^a { $^b = $^a } };

?  Are there two C<$^a>'s, one masking the other?  Or just one?  If two,
then the code should fail at runtime for attempted assignment to an
undefined lvalue (because $^b isn't set) or more likely at compile-time
for a missing required parameter.  If there's just one C<$^a>, wouldn't
C<$^b> get set to the topic of the C, i.e. C<$^a> (or is the topic of
an C's first closure always C?), leading to the expression being
equivalent to

  $sub = ( if $^a { $^a = $^a } };

?  Or will Perl DWIM and attach both $^a and $^b to the outer sub?  If so,
how did it know to do that, and not attach it to whatever sub contains the
assignment to $sub?

I'm probably just confused here, but I'd appreciate some straightening
out, as it's relevant to something I'm working on.  Apo 6 seems to be
silent on this (which perhaps indicates that I'm making this a lot harder
than it is).

Trey

Testing job

[Mark Jason Dominus]

I'm writing automated tests for the example code in my book, which
will go into production early next month.  I have the harness and test
apparatus all set up; I wrote a complete set of tests for chapter 6,
and I think I know how I want it done.  But I need help writing the
tests themselves, because time is short and I have a lot of other
stuff to do.

If you would be interested in helping me with this, send me mail right
away.  I believe that my publisher is willing to pay for it, although
I don't know how much.

-D.

Re: Apocalypse 12

[Mark A. Biggar]

Brent 'Dax' Royal-Gordon wrote:

chromatic wrote:

Perl.com has just made A12 available:


I started reading it last night, and ended up going to bed before I was 
finished.  But I just wanted to say that this:

With this dispatcher you can continue by saying "next METHOD".

is the sort of genius that makes me glad Larry's designing this 
language.  Well done!

Yeah, remmeber from A4 that flow control stuff like "next", "leave",
"return" are semantically a form of exception throw and so are actaully
dymanically (not lexically) scoped (although the compiler is free to
optimize if the target is in the lexical scope of the construct or
vice versa).
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: placeholder attachment?

[Luke Palmer]

Trey Harris writes:
> Can anyone explain the rules of placeholder attachment?  i.e., in the
> example in Perl6::Placeholder's manpage,
> 
>   grep { $data{$^value} } 1..10;
> 
> C<$^value> is clearly intended to attach to the outer closure C<{
> $data{$^value} }>, not the inner closure C<{$^value}>.  But how does the
> compiler know?  What is the general rule?

This is a tough question, one to which I don't know the answer.  I'll
do something different for a change and speculate :-)

In your first example, it does what you mean because the hash subscript
isn't a closure.  Curlies are always closures, except when they're not
(to be specific, in hash subscripts and hash constructors).

> It's easy to just say "don't nest placeholder-using closures," but that
> doesn't seem workable in practice since every block is a closure, unless
> placeholders are forbidden from all but the most trivial cases.  Absurdly
> trivial, it seems.  How about
> 
>   $sub = { if $^a { $^b = $^a } };

I want this to work.  It could look at C's signature and see that
the closure it is expecting wants arguments, and since it doesn't, it
knows that they belong outside.  But that doesn't generalize.

I think a better solution would be to associate all placeholders with
the outermost closure that introduced a placeholder.  For example:

$sub = { { $^a + $^b } };

Would bind them both to the inner one, while:

$sub = { $^a; { $^a + $^b } };

Would bind them both to the outer one.  Since placeholders are meant for
small scopes, this seems a good heuristic.  That second example was
obviously a hack to get it to work right.  The clean way to do that
would be:

$sub = -> $a, $b { { $a + $b } };

Luke

Re: Constant strings - again

[Jeff Clites]

On Apr 18, 2004, at 8:06 AM, Leopold Toetsch wrote:

Leopold Toetsch <[EMAIL PROTECTED]> wrote:

[ initial proposal ]

I've now checked in a working version.
* c2str.pl generates a  .str header from a .c file
* c2str.pl --all generates $(INC)/string_private_cstring.h
* this us used in string_init() to finally generate entries
  in the interpreter's constant string table
* to add new files makefiles/root.in or such has to be edited
  see objects.str as a template
Using multiple files is only slightly tested though.
To handle multiple files, we'll probably need to generate a .c to hold 
the C strings (instead of the .h), and have an extern declaration in 
the .h (since it will be included in multiple files). That's assuming 
they'll all be aggregated into a single file (which makes sense).

Here is a related patch, to cause us to cache the hash values of all 
strings (on demand). The important part is that the cached value is 
cleared out in unmake_COW, which is called any time we might mutate the 
string (and thus, invalidate the cached value). This will have the 
side-effect of allowing c2str.pl to be slightly simpler, since it won't 
need to pre-calculate the hash value (since const strings are the same 
as any others, and their hash value will be calculated and cached if it 
is ever needed).

This change speeds up the attached benchmark by a factor of 1.86 in the 
optimize case (via --optimize, so -Os), or 3.73 in the unoptimized case 
(on Mac OS X):

# without the patch, optimized build
% ./parrot hash-timing.pasm
679 hash entries
128 characters per test key
100 lookups each
rep 1:  1.093889 sec
rep 2:  1.109484 sec
rep 4:  1.095041 sec
# with the patch, optimized build
% ./parrot hash-timing.pasm
679 hash entries
128 characters per test key
100 lookups each
rep 1:  0.608547 sec
rep 2:  0.586352 sec
rep 4:  0.575159 sec
JEff



hash-caching.patch
Description: Binary data


hash-timing.pasm
Description: application/text

Re: Basic Library Paths (was Re: ICU data file location issues)

[Gordon Henriksen]

Dan Sugalski wrote:

Brent 'Dax' Royal-Gordon wrote:

Dan Sugalski wrote:

3) Parrot itself (the main executable) has a static, global 1K buffer 
in it that starts and ends with some recognizable string (like, say, 
"***+++***START|" and "|END***+++***") so we can find it and 
overwrite the contents if the library gets moved, for use on 
platforms where the only way to put a path in is to stick it 
statically in the executable.
That's pretty disgusting, but I don't know that I have a better idea.
There isn't one, alas, at least for some people.
Everyone running tripwire, et al. (or simply md5sum'ing files to verify 
integrity) will just love this strategy to death.

Finding resource and library files relative to the binary really is a 
very good strategy. Windows is adopting the placed-near-the-binary 
strategy for locating resources and libraries. It has completely 
eliminated "DLL hell" for .NET programs. Mac OS 7 through X have all 
used the same strategy. They have never had major problems with library 
or resource location. Looks like a strong precedent and a proven 
technique.

Of course, one can find pathological cases—especially on Unix, which 
seems designed to thwart this sort of easy-to-administer technology:

	• parrot binary unlink'd between exec and main(). (Can't happen on 
Windows.)
	• Launched through a symlink to the binary.
	• Launched through a hard link to the binary.
	• bin/ is a symlink, so ../share won't work.
	• Platform can't find the binary. (Can't happen on Windows, Linux, 
or Mac OS X.)
	• chroot (which, in general, near-the-binary solves rather than 
complicates).

But I'd say these are all are heavily outweighed by the advantages. And, 
in any case, it's a trivial matter at this point in design to offer 
support for replacing a call to Parrot_get_bin_path() (or whatever) with 
"/usr/local/bin" at configure time. That resolves all of the above. With 
a loss of functionality, true, but: Users on platforms which can't 
support this feature won't after all expect /opt/parrot to work after it 
was mv'd.

As for the security concerns of trusting anything but one's current 
binary*, parrot could adopt a cryptographic solution for verifying 
integrity of resource files, if anybody's really all that worried about 
an errant Unicode character database.

—

Gordon Henriksen
[EMAIL PROTECTED]
* - Is the binary itself is really all that trustworthy in the first 
place? If a user is executing a program through an untrusted or 
compromised path, they're already putting their life in their hands, and 
accessing ${bin}/../share won't make the configuration any more 
trustworthy.

Re: Constant strings - again

[Jarkko Hietaniemi]

> C-constant region of memory? For instance, if we could tell their 
> memory address is < stack base, and use that to identify them as 
> constant?

I don't think there is much chance of getting anything like this working
portably.

> static_strings[7], or something. Then the check is just whether 
> (some_string >= static_strings[0] && some_string <= 
> static_strings[max])--if so, it was from a literal (and thus, is 
> constant).

Something like this would be feasible.  In fact, if we are going for
compile-time tricks, all constant strings (or their "bodies", at least)
could be concatenated into a single giant string, and then have another
constant array just having the [offset, bytes] pairs.  Or, rather, the
[offset, bytes, hash] triplets.

Re: [perl #28916] gmake

[Jeff Clites]

On Apr 17, 2004, at 1:47 PM, Nicholas Clark (via RT) wrote:

# New Ticket Created by  Nicholas Clark
# Please include the string:  [perl #28916]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28916 >
You must use /usr/bin/gmake to build ICU.

(parrot build fails)

gmake was never on our list of "minium platform requirements"

What is our plan w.r.t to this. Currently parrot is broken on any Unix
machine that doesn't have gmake.
That's actually not true. That message appears to be spurious. I  
certainly don't have anything called "gmake" on my system (I don't even  
know what it is), but ICU builds for me. See:

http://oss.software.ibm.com/cvs/icu/~checkout~/icu/ 
readme.html#HowToBuildSupported

AIX, FreeBSD, and Solaris are all listed as either "reference platform"  
or "regularly tested". Though the versions you have may differ, I'd be  
surprised if that's the problem. Perhaps you could supply some more  
details as to how these builds are failing for you.

JEff

specifically *I* now can't build parrot on:
  AIX ajax 1 5 0052B23F4C00
  FreeBSD colon.colondot.net 4.9-STABLE FreeBSD 4.9-STABLE #5: Fri Feb  
20 16:12:05 GMT 2004  
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/COLONDOT  i386
and I'm not going to be able to build it on the Solaris box I recently  
got
an account on.

These are all machines perfectly capable of building perl 5, and  
machines with
working C++ compilers.

I don't have an answer for this, but I'd like one.

Nicholas Clark

Re: Basic Library Paths (was Re: ICU data file location issues)

[Jeff Clites]

On Apr 17, 2004, at 6:18 PM, Gordon Henriksen wrote:

Dan Sugalski wrote:

Brent 'Dax' Royal-Gordon wrote:

Dan Sugalski wrote:

3) Parrot itself (the main executable) has a static, global 1K 
buffer in it that starts and ends with some recognizable string 
(like, say, "***+++***START|" and "|END***+++***") so we can find 
it and overwrite the contents if the library gets moved, for use on 
platforms where the only way to put a path in is to stick it 
statically in the executable.
That's pretty disgusting, but I don't know that I have a better idea.
There isn't one, alas, at least for some people.
Everyone running tripwire, et al. (or simply md5sum'ing files to 
verify integrity) will just love this strategy to death.
It would be no different than what would happen if you had to rebuild 
to change the built-in path. This just has the advantage of not 
requiring a compiler, and the source code.

Of course, one can find pathological cases—especially on Unix, which 
seems designed to thwart this sort of easy-to-administer technology:

	• parrot binary unlink'd between exec and main(). (Can't happen on 
Windows.)
	• Launched through a symlink to the binary.
	• Launched through a hard link to the binary.
	• bin/ is a symlink, so ../share won't work.
	• Platform can't find the binary. (Can't happen on Windows, Linux, or 
Mac OS X.)
	• chroot (which, in general, near-the-binary solves rather than 
complicates).
Pick any strategy, and there will be an opportunity to thwart it. 
Launch the binary, and then force-unmount the filesystem containing it 
and all of its resources. That would thwart any strategy with external 
resources. The point here (which you're probably agreeing with) is to 
provide a solution that gives people flexibility they can use, not a 
solution that will work if they are actively trying to trip it up.

As for the security concerns of trusting anything but one's current 
binary*, parrot could adopt a cryptographic solution for verifying 
integrity of resource files, if anybody's really all that worried 
about an errant Unicode character database.
It's really no different that loading an external Perl module today, as 
I see it.

* - Is the binary itself is really all that trustworthy in the first 
place? If a user is executing a program through an untrusted or 
compromised path, they're already putting their life in their hands, 
and accessing ${bin}/../share won't make the configuration any more 
trustworthy.
Exactly. The contents of the filesystem are either secure, or they're 
not.

JEff

Re: c2str.pl

[Jarkko Hietaniemi]

FWIW, the usually picky Tru64 compiler is happy with the code generated
with the newest c2str.pl.

P.S.  Why is the /*const*/ commented out?  I would think it would be a
good idea.

[perl #28915] parrotbug can only send mail

[via RT]

# New Ticket Created by  Nicholas Clark 
# Please include the string:  [perl #28915]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28915 >


parrotbug can only send mail.
This isn't that useful on systems where mail is accepted by sendmail,
but will never get delivered.
perlbug is able to save the bug report to a file, which can then be copied
over to a system that can send mail.

Would it be possible to add this to parrotbug?

I tried using parrotbug to report this, but... :-)

Nicholas Clark

[perl #28920] [BUG & Test PATCH imcc/t/syn.t] IMCC .param directives cannot be interrupted

[via RT]

# New Ticket Created by  chromatic 
# Please include the string:  [perl #28920]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28920 >


The attached patch to the IMCC test suite demonstrates that .param
directives must appear in one contiguous block, else an 'No entries on
UserStack!' error will appear.

This may be intentional -- however, it surprised me.

-- c


Index: imcc/t/syn/pcc.t
===
RCS file: /cvs/public/parrot/imcc/t/syn/pcc.t,v
retrieving revision 1.40
diff -u -u -r1.40 pcc.t
--- imcc/t/syn/pcc.t	30 Mar 2004 14:50:00 -	1.40
+++ imcc/t/syn/pcc.t	18 Apr 2004 00:32:11 -
@@ -1,6 +1,6 @@
 #!perl
 use strict;
-use TestCompiler tests => 36;
+use TestCompiler tests => 37;
 
 ##
 # Parrot Calling Conventions
@@ -1394,3 +1394,34 @@
 P 0
 OUT
 
+output_is(<<'CODE', <<'OUT', '.param lines not contiguous');
+.sub _main
+_func(1,2,3,'ok ', 'ok ', 'ok ')
+end
+.end
+.sub _func
+# integer arguments
+.param int one
+.param int two
+.param int three
+
+# string arguments
+.param string ok_one
+.param string ok_two
+.param string ok_three
+
+print ok_one
+print one
+print "\n"
+print ok_two
+print two
+print "\n"
+print ok_three
+print three
+print "\n"
+.end
+CODE
+ok 1
+ok 2
+ok 3
+OUT

Re: Basic Library Paths (was Re: ICU data file location issues)

[Gordon Henriksen]

On Saturday, April 17, 2004, at 10:35 , Gordon Henriksen wrote:

Which suggests to me a linked list of resource resolvers. First one in 
the chain to return a file handle to the data or PBC wins. The head of 
parrot's own "system" chain would be available to be appended to any 
other chains that wanted it.
And the more I mull this over, the more I really come up with maybe 4 
slots in the search chain which are logically important. The order is up 
for debate, but they all need to be in there (whenever they apply, that 
is).

1.  Paths relative to the PBC binary which is searching for a library.
2.  Paths relative to the embedding application.
3.  Paths relative to parrot itself (be that libparrot.shlib or parrot).
4.  Paths to "system" libraries as specified by the administrator.
When searching for resources, only #1 should be used. Here are some 
examples:

PBC File: (whatever)
Host app: /usr/local/bin/parrot
Parrot: /usr/local/lib/libparrot.shlib
Consider searches for:
icu.dat
Search path:
1.  /usr/local/shared   # Relative to executable
PBC File: D:\inetpub\wwwroot\example.pbchtml
Host app: C:\Apache\libexec\httpd.exe
Parrot: C:\Parrot\lib
Consider searches for:
icu.dat
mod_parrot.pbc
My::WWWUtil.pbc
Time::HiRes.pbc
Search path:
D:\inetpub\wwwroot{,\lib,\..\lib}  # Relative to PBC
C:\Apache\libexec{,\lib,\..\lib}  # Relative to host app
C:\CPAN\lib  # System libraries
C:\Parrot\lib  # Relative to parrot
PBC File: ./bin/fib
Host app: /home/me/bin/parrot
Parrot: /home/me/bin/parrot
Consider searches for:
icu.dat
Time::HiRes.pbc
fib.parrot_resource_file
One possible search path:
./bin/{,/lib,/../lib}  # Relative to PBC
/usr/local/lib  # System libraries
/home/me/lib  # Relative to parrot


The scenario which gives me a little bit of heartburn is one like this, 
though:

Consider, say, an e-commerce site package. Call it OneStep::ECS. Runs 
under mod_parrot in Apache. Has hooks to load plugins:

	• Third-party plugins to provide connectivity to payment processing 
engines (call it OneStep::VeriSignPayflow.pbc).
	• First-party plugins allowing the customer to integrate his 
storefront with his database (call it 
MySite::OneStepECSCustomizations.pbc).

Now consider searches for VeriSign::PayflowPro.pbc, PayFlowPro.dll, 
MySite::CRM.pbc, MySite::Reporting.pbc, mysite_logo.png, 
Time::HiRes.pbc, libparrot.pbc, CGI.pbc

So maybe some libraries are "hosts" and need to be included in the 
search paths of libraries which are linked to them. One could even look 
at libparrot that way, in which case the search path model becomes:

Paths relative to this PBC file.
Paths relative to its hosts.
Paths relative to its hosts' hosts.
Paths relative to its hosts' hosts' hosts.
...
Paths configured by the system administrator.
—

Gordon Henriksen
[EMAIL PROTECTED]

Re: Basic Library Paths (was Re: ICU data file location issues)

[Gordon Henriksen]

On Thursday, April 15, 2004, at 01:48 , Dan Sugalski wrote:

At this point I can say I don't honestly care all that much, and most 
of my worries are based on vague feelings that there are platforms out 
there where finding the actual executable name is somewhere between 
hard and impossible. I will, then, do the sensible thing and just punt 
on this--we can work out a best practices thing and enshrine it as the 
default on systems which can support it and be done with it.

The other question, then, is do we see the need for multiple categories 
of library which would want separately settable library paths?
Wouldn't it be sensible to build something robust enough to also solve 
the problems of finding parrot user libraries and user resources? In 
which case, a static search path is decidedly retro. It would hardly 
make sense to not include, at the front of the search path, directories 
relative to the PBC file trying to find its libraries or resources.*

For finding resources, one doesn't generally want to fall back to system 
paths. Finding libraries is another matter.

Then there's the mention of using URLs to load resources (e.g., over 
HTTP). Which seems sensible and forward-thinking to me.

Which suggests to me a linked list of resource resolvers. First one in 
the chain to return a file handle to the data or PBC wins. The head of 
parrot's own "system" chain would be available to be appended to any 
other chains that wanted it.

—

Gordon Henriksen
[EMAIL PROTECTED]
(* - The directory containing every loaded PBC file is not at all 
important; consider an application like Apache+mod_parrot which is 
loading multiple independent PBC files. It would be useful to allow the 
administrator to install both the production PBC in addition to a 
development release of the same application on the same web server [just 
at different paths], with confidence that mod_parrot won't get the two 
confused. [IIS can do this. It's very cool.])

[perl #28916] gmake

[via RT]

# New Ticket Created by  Nicholas Clark 
# Please include the string:  [perl #28916]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28916 >


You must use /usr/bin/gmake to build ICU.

(parrot build fails)

gmake was never on our list of "minium platform requirements"

What is our plan w.r.t to this. Currently parrot is broken on any Unix
machine that doesn't have gmake.

specifically *I* now can't build parrot on:
  AIX ajax 1 5 0052B23F4C00
  FreeBSD colon.colondot.net 4.9-STABLE FreeBSD 4.9-STABLE #5: Fri Feb 20 16:12:05 GMT 
2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COLONDOT  i386
and I'm not going to be able to build it on the Solaris box I recently got
an account on.

These are all machines perfectly capable of building perl 5, and machines with
working C++ compilers.

I don't have an answer for this, but I'd like one.

Nicholas Clark

Re: ICU data file location issues

[Gordon Henriksen]

On Saturday, April 17, 2004, at 02:17 , Gordon Henriksen wrote:

On Thursday, April 15, 2004, at 02:25 , Jeff Clites wrote:

For Unix platforms at least, you should be able to do this:

	executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
That absolutely does not work, as already pointed out. Ths looks like a 
reasonable reference implementation (LGPL), though:

http://www.opensource.apple.com/darwinsource/10.3/libiconv-9/libiconv/srclib/
progreloc.c
On Windows and Linux, it uses Win32 and /proc to provide a robust 
implementation. Otherwise, it guesses by looking at $0 and $ENV{PATH}.

My guess is that there's a more reliable (and non-portable) way to do 
this on Mac OS X, since Carbon applications need to reliably open the 
resource fork of the executable.
Ah! Indeed there is.

http://developer.apple.com/documentation/Carbon/Reference/Process_Manager/
index.html
And, indeed, it is witheringly non-portable.

	CFDictionaryRef dict = ProcessInformationCopyDictionary(
		kCurrentProcess, kProcessDictionaryIncludeAllInformationMask);
	CFString cfPath = (CFString *) CFDictionaryGetValue(dict, 
kIOBundleExecutableKey);
	CFIndex length = CFStringGetMaximumSizeForEncoding(cfPath, 
kCFEncodingUTF8);
	char *path = (char *) malloc(length + 1);
	CFStringGetCString(cfPath, path, length + 1, kCFEncodingUTF8);
	CFRelease(dict);

Ahem.

I'm sure the ProcessInformationCopyDictionary API is implemented in 
terms of something sane at the Darwin level, but God only knows what it 
is.

—

Gordon Henriksen
[EMAIL PROTECTED]

Re: ICU data file location issues

[Gordon Henriksen]

On Thursday, April 15, 2004, at 02:25 , Jeff Clites wrote:

For Unix platforms at least, you should be able to do this:

	executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
That absolutely does not work, as already pointed out. Ths looks like a 
reasonable reference implementation (LGPL), though:

http://www.opensource.apple.com/darwinsource/10.3/libiconv-9/libiconv/srclib/
progreloc.c
On Windows and Linux, it uses Win32 and /proc to provide a robust 
implementation. Otherwise, it guesses by looking at $0 and $ENV{PATH}.

My guess is that there's a more reliable (and non-portable) way to do 
this on Mac OS X, since Carbon applications need to reliably open the 
resource fork of the executable.

—

Gordon Henriksen
[EMAIL PROTECTED]

Re: Constant strings - again

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:

> To handle multiple files, we'll probably need to generate a .c to hold
> the C strings (instead of the .h), and have an extern declaration in
> the .h (since it will be included in multiple files). That's assuming
> they'll all be aggregated into a single file (which makes sense).

Well, there is one include file per .c (e.g. objects.str), which holds
defines for this file. The global string table is included only in
string.c to construct the strings. There is no need to have include
files with any extern declarations or includes for multiple files.

> Here is a related patch, to cause us to cache the hash values of all
> strings (on demand). The important part is that the cached value is
> cleared out in unmake_COW, which is called any time we might mutate the
> string

Yep. Should work.

> side-effect of allowing c2str.pl to be slightly simpler, since it won't
> need to pre-calculate the hash value (since const strings are the same
> as any others, and their hash value will be calculated and cached if it
> is ever needed).

We still can precalculate for these constant strings and save some extra
cylces (the precalculated value isn't used yet, but ...) And we can
precalculate hash values for the string constants in the constant table
during compilation (and write it into the PBC).

> This change speeds up the attached benchmark by a factor of 1.86 in the
> optimize case (via --optimize, so -Os), or 3.73 in the unoptimized case
> (on Mac OS X):

Wheee, that's a lot.

I'll apply it RSN - I'm currently fighting with the Makefile (classes
stuff moved to main)

> JEff

leo

Re: [perl #28916] gmake

[Peter Sinnott]

On Mon, Apr 19, 2004 at 02:46:20AM -0700, Jeff Clites wrote:
> On Apr 17, 2004, at 1:47 PM, Nicholas Clark (via RT) wrote:
> 
> ># New Ticket Created by  Nicholas Clark
> ># Please include the string:  [perl #28916]
> ># in the subject line of all future correspondence about this issue.
> ># http://rt.perl.org:80/rt3/Ticket/Display.html?id=28916 >
> >
> >
> >You must use /usr/bin/gmake to build ICU.
> >
> >(parrot build fails)
> >
> >gmake was never on our list of "minium platform requirements"
> >
> >What is our plan w.r.t to this. Currently parrot is broken on any Unix
> >machine that doesn't have gmake.
> 
> That's actually not true. That message appears to be spurious. I  
> certainly don't have anything called "gmake" on my system (I don't even  
> know what it is), but ICU builds for me. See:
> 
> http://oss.software.ibm.com/cvs/icu/~checkout~/icu/ 
> readme.html#HowToBuildSupported
> 

http://oss.software.ibm.com/cvs/icu/~checkout~/icu/readme.html#HowToBuildUNIX

says

Building International Components for Unicode on UNIX requires:

* A C++ compiler installed on the target machine (for example: gcc,
* CC, xlC_r, aCC, cxx, etc...).
* An ANSI C compiler installed on the target machine (for
 example: cc).
* A recent version of GNU make (3.77+).
* For a list of z/OS tools please view the z/OS build
* section of this document for further details.

One my local linux machine

migo:/home/psinnott# make -v
GNU Make 3.80

Freebsd provided there own version of make so on a freebsd machine
gnu make is installed as gmake

> AIX, FreeBSD, and Solaris are all listed as either "reference platform"  
> or "regularly tested". Though the versions you have may differ, I'd be  
> surprised if that's the problem. Perhaps you could supply some more  
> details as to how these builds are failing for you.
> 
> JEff

-- 
It is our mission to synergistically foster excellent leadership skills 
in order to professionally utilize quality deliverables

Re: c2str.pl

[Leopold Toetsch]

Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> FWIW, the usually picky Tru64 compiler is happy with the code generated
> with the newest c2str.pl.

> P.S.  Why is the /*const*/ commented out?  I would think it would be a
> good idea.

Isn't used anymore (it produced warnings during initialization).

leo

Re: [perl #28920] [BUG & Test PATCH imcc/t/syn.t] IMCC .param directives cannot be interrupted

[Leopold Toetsch]

Chromatic <[EMAIL PROTECTED]> wrote:

> The attached patch to the IMCC test suite demonstrates that .param
> directives must appear in one contiguous block, else an 'No entries on
> UserStack!' error will appear.

> This may be intentional -- however, it surprised me.

$ perldoc imcc/docs/calling_conventions.pod

   · .param
   The .param declarations must be the first statements
   in the sub if any. No other statements are allowed
   between .param - not even comments currently.

leo

Re: Constant strings - again

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:

> Here is a related patch, to cause us to cache the hash values of all
> strings (on demand). The important part is that the cached value is
> cleared out in unmake_COW, which is called any time we might mutate the
> string (and thus, invalidate the cached value).

Thanks, applied.
leo

A note WRT c2str.pl

[Leopold Toetsch]

I've now changed interpreter.c to use CONST_STRING() too. It's basically 
working but there is a problem:
The macros use the current line number for identifying a string. When 
the line is:

  f (some,
  CONST_STRING("foo"),
  some_more);
then c2str.pl and the C compiler have different line numbers.
So CONST_STRING() has to be on the last line of one statement.
leo

Re: set_string_native

[Dan Sugalski]

At 5:35 PM +0200 4/16/04, Leopold Toetsch wrote:
This vtable currently copies the string.
Yeah, and we've the same issue with set_pmc -- some of the versions 
make a copy and some just use the passed in PMC. (the 
get_[string|pmc] vtable methods have a similar issue--should they 
return the real thing or a copy?)

I'm up for a set and assign string & pmc vtable method, as well as a 
get and access (to get a copy and a direct reference, respectively) 
string and pmc method, though there's always the caveat that some 
PMCs won't be able to actually do this and will have to make a copy 
anyway.
--
Dan

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

Re: OO benches

[Dan Sugalski]

At 11:19 AM +0100 4/17/04, Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:

 Aaron Sherman <[EMAIL PROTECTED]> wrote:
 On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote:

 Sorry, I gave the wrong impression. I meant it looks suspiciously like
 Python is doing a lazy construction on those objects, not that there is
 anything wrong with the benchmark.
 No, I don't think that this is happening. Parrot's slightly slower
 object instantiation is due to register preserving mainly. The "__init"
 code is run from inside the "new PObj, IClass" opcode. As its not known
 that a method call is happening here, we can't use register preserving
 operations that only save needed registers--we have to save all
 registers. These two memcpys are the most heavy part of the operation.
Maybe we should rethink that then and make allocation and
initialization two different phases.
That's the way I'm leaning. I know it's a *bad* idea from a 
high-level language point of view, but from the lower levels it's 
less of a bad idea.

New, then, would allocate the object and you'd need to then call its 
constructor, with the constructor call using full-on parrot calling 
conventions and giving the calling code a chance to save the 
registers it was interested in. Of course, then we get into the issue 
of handling return values from multiple calls into methods as we 
automatically redispatch the constructor, but...
--
Dan

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

Re: [perl #28916] gmake

[Dan Sugalski]

At 1:47 PM -0700 4/17/04, Nicholas Clark (via RT) wrote:
# New Ticket Created by  Nicholas Clark
# Please include the string:  [perl #28916]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28916 >
You must use /usr/bin/gmake to build ICU.

(parrot build fails)

gmake was never on our list of "minium platform requirements"

What is our plan w.r.t to this. Currently parrot is broken on any Unix
machine that doesn't have gmake.
The plan (at the moment) is to either require gmake on the system or 
to link with the system-installed ICU. I'm not sure we want to hack 
up ICU enough to build with more vanilla make systems--that's going a 
bit above and beyond.

I'm still not 100% sure what we ought to do with ICU distribution. 
That needs some thought.
--
Dan

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

Re: Basic Library Paths (was Re: ICU data file location issues)

[Dan Sugalski]

At 9:18 PM -0400 4/17/04, Gordon Henriksen wrote:
Dan Sugalski wrote:

Brent 'Dax' Royal-Gordon wrote:

Dan Sugalski wrote:

3) Parrot itself (the main executable) has a static, global 1K 
buffer in it that starts and ends with some recognizable string 
(like, say, "***+++***START|" and "|END***+++***") so we can find 
it and overwrite the contents if the library gets moved, for use 
on platforms where the only way to put a path in is to stick it 
statically in the executable.
That's pretty disgusting, but I don't know that I have a better idea.
There isn't one, alas, at least for some people.
Everyone running tripwire, et al. (or simply md5sum'ing files to 
verify integrity) will just love this strategy to death.
No, not really. This only gets done once, when the package is installed.

Finding resource and library files relative to the binary really is 
a very good strategy.
I'm not saying it isn't, just that it's not possible on some systems. 
Granted, fairly old one generally, but...
--
Dan

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

RE: A12 undef method calls

[Austin Hastings]

> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Monday, 19 April, 2004 06:00 AM
> To: Language List
> Subject: A12 undef method calls
> 
> 
> A12 mentions that C<$foo.bar> should return undef if C<$foo> is undef.
> While I like the idea a lot, I don't think it should happen without
> distinction.  In fact, that's what I would most expect C<.?> to do, not
> "call a method if there is one," though that seems useful, too.
> 
> I'm just shooting in the dark here, but perhaps C should play that
> role.  That way you have:
> 
> $foo.?bar  # return undef if "bar" is undef... in a 
> manner of speaking
> $foo?.bar  # return undef if $foo is undef
> $foo?.?bar # return undef if either is (?)
> 

I think that undef->undef is desirable default behavior, not something that should 
have to be spelled out over and over again.

There are really four cases. Assuming errors in all:

1- Untyped/Undefined: "I don't know *WHAT* you want."

2- Typed/Undefined: "I know what you want, but you can't get it (yet)."

3- Untyped/Defined: "I know what you want, but this object doesn't support it."

4- Typed/Defined: "I know what you want, and this is plain wrong."

I think that 3 and 4 should throw exceptions, as being clearly wrong (unless 
AUTHMETH[DEF] is present). 1 and 2 on the other hand are more in the region of 
"easygoing DWIMery", so should just return a helpful undef, unless C is in effect.

> Either that or C<.?> could double as both roles, considering C
> an object with no methods.

Ugh. Let's make '.' as useful as possible, please.

> And I can't figure out for the life of me why you'd ever want to use
> C<.+>...

This is probably the "should be" default for '.':

"Call a method. If there's more than one, figure out what to do about that case and do 
it. But make sure that SOMETHING gets done, or let me know why not."

=Austin

RE: Apocalypse 12

[Austin Hastings]

> -Original Message-
> From: Mark A. Biggar [mailto:[EMAIL PROTECTED]
>
> Brent 'Dax' Royal-Gordon wrote:
>
> > chromatic wrote:
> >
> >> Perl.com has just made A12 available:
> >
> >
> > I started reading it last night, and ended up going to bed before I was
> > finished.  But I just wanted to say that this:
> >
> > With this dispatcher you can continue by saying "next METHOD".
> >
> > is the sort of genius that makes me glad Larry's designing this
> > language.  Well done!
> >
>
> Yeah, remmeber from A4 that flow control stuff like "next", "leave",
> "return" are semantically a form of exception throw and so are actaully
> dymanically (not lexically) scoped (although the compiler is free to
> optimize if the target is in the lexical scope of the construct or
> vice versa).

I kind of have a problem with this on fragility grounds.

Not so much the C syntax, as the whole non-local-goto idea.

Specifically, if you have code that uses C or C without the loop
name, it's vulnerable to having additional control structures inserted in
the flow. (If the named approach is used, it's vulnerable to having named
entities inserted in the flow. Less vulnerable, but vulnerable.)

I'm wondering if there's some way to convert C into C, such that each loop would have a unique "identity" that could be
passed around.

This would raise the bar for erroneous invocations, and at the same time
make slightly more programmatic things possible. (Sure, C works, but at what price?)

=Austin

Re: Apo 12: Space in method calls

[Larry Wall]

On Sat, Apr 17, 2004 at 01:07:44PM -0500, Abhijit A. Mahabal wrote:
: I do not understand one of the examples in the Use of methods/the dot
: notation section:
: 
: $obj.method ($x + $y) + $z
: 
: >From the earlier examples (like $obj.method +1), I got the impression that
: you look ahead until you find a term or an operator. In the example above,
: isn't ($x + $y) a full term, all by itself, and in that case would not
: this mean ($obj.method($x + $y)) + $z, the same as the other call it is
: contrasted with:
: 
: $obj.method($x + $y) + $z
: 
: What am I missing?

The distinction is not term/operator exactly.  It's a four-way distinction
between

definitely a postfix op -> () hold arguments, otherwise no arguments
definitely a binary op  -> there are no arguments
ambiguous   -> require disambiguation
definitely a term   -> treat method as list operator

where the last category assumes that the term indicates the first item
in an expression.  (Note that a definite unary operator is the beginning
of a term.)

The basic underlying motivation is to allow methods a list operators:

$my.for 1..3 {...}

Now, we haven't actually defined what puts the method call into which
category.  But the rather obvious poler opposites are

$obj.meth,  -> obviously not arguments
$obj.meth $foo,$bar -> obviously arguments

If the rules get skewed one way or the other to eliminate the ambiguos
middle category, I'd say that we tend to give the benefit of the
doubt to the list, and you have to put a "stopper" like comma or a
right bracket or brace, or put explicit empty parens, if you want to
pass no arguments.  But if we can unambiguously define what's ambiguous :-)
then it might be useful to force people to clarify what they mean, just
for readability.

Larry

Re: Apo 12

[Larry Wall]

On Sat, Apr 17, 2004 at 01:12:58PM -0400, Austin Hastings wrote:
: If it's not totally obvious to everyone, you should download a copy of A12
: (I like the "printer-friendly" all-in-one-page version) as a hedge against
: the almost-inevitable slashdotting.

Or not...

Perhaps slashdot has decided they don't frontpage PhD dissertations.  :-)

Larry

Re: placeholder attachment?

[Larry Wall]

On Mon, Apr 19, 2004 at 04:48:05AM -0600, Luke Palmer wrote:
: Trey Harris writes:
: > Can anyone explain the rules of placeholder attachment?  i.e., in the
: > example in Perl6::Placeholder's manpage,
: > 
: >   grep { $data{$^value} } 1..10;
: > 
: > C<$^value> is clearly intended to attach to the outer closure C<{
: > $data{$^value} }>, not the inner closure C<{$^value}>.  But how does the
: > compiler know?  What is the general rule?
: 
: This is a tough question, one to which I don't know the answer.  I'll
: do something different for a change and speculate :-)

Hey, I never speculate.  ;-)

: In your first example, it does what you mean because the hash subscript
: isn't a closure.  Curlies are always closures, except when they're not
: (to be specific, in hash subscripts and hash constructors).

Yes, that's the basic rule.  In Perl 5 the curlies are (potentially)
blocks, though the optimizer throws away the block entry and exit
when it thinks it can.  In Perl 6 we'll just say that those aren't
blocks.  If you really want a block inside a subscript, you can always
use do {}.  (But merely putting semicolons inside a subscript turns
it into a multidimensional subscript, not a block.)

: > It's easy to just say "don't nest placeholder-using closures," but that
: > doesn't seem workable in practice since every block is a closure, unless
: > placeholders are forbidden from all but the most trivial cases.  Absurdly
: > trivial, it seems.  How about
: > 
: >   $sub = { if $^a { $^b = $^a } };
: 
: I want this to work.  It could look at C's signature and see that
: the closure it is expecting wants arguments, and since it doesn't, it
: knows that they belong outside.  But that doesn't generalize.

I don't think I want that to work.

: I think a better solution would be to associate all placeholders with
: the outermost closure that introduced a placeholder.  For example:
: 
: $sub = { { $^a + $^b } };
: 
: Would bind them both to the inner one, while:
: 
: $sub = { $^a; { $^a + $^b } };
: 
: Would bind them both to the outer one.

This is the sort of twisty thinking that some people can keep straight
and some people can't.  That's why we simplified the list of rules
from the original placeholder RFC, after all.

: Since placeholders are meant for
: small scopes, this seems a good heuristic.  That second example was
: obviously a hack to get it to work right.  The clean way to do that
: would be:
: 
: $sub = -> $a, $b { { $a + $b } };

Yup.

Larry

Re: Apo 12: Space in method calls

[Abhijit A. Mahabal]

On Mon, 19 Apr 2004, Larry Wall wrote:

> On Sat, Apr 17, 2004 at 01:07:44PM -0500, Abhijit A. Mahabal wrote:
> : $obj.method ($x + $y) + $z
> :
> : >From the earlier examples (like $obj.method +1), I got the impression that
> : you look ahead until you find a term or an operator. In the example above,
> : isn't ($x + $y) a full term, all by itself, and in that case would not

> : What am I missing?
>
> The distinction is not term/operator exactly.  It's a four-way distinction
> between
>
> definitely a postfix op   -> () hold arguments, otherwise no arguments
> definitely a binary op-> there are no arguments
> ambiguous -> require disambiguation
> definitely a term -> treat method as list operator
>
> where the last category assumes that the term indicates the first item
> in an expression.  (Note that a definite unary operator is the beginning
> of a term.)

> $obj.meth,-> obviously not arguments
> $obj.meth $foo,$bar   -> obviously arguments
>

 $obj.meth() + $bat -> obviosly not arguments
 $obj.meth () + $bat-> obviosly not arguments
 $obj.meth ($foo + $bar) + $bat -> ambiguous, likely to be list
 $obj.meth($foo + $bar) + $bat  -> $foo + $bar the argument
 $obj.meth($foo + $bar), $bat   -> list

Is that about the story so far? Or is the last example probably going to
be illegal without a space?

How bad is it to require space before arguments that are a list, so that
the no-space case is unambiguous?

> Larry

--Abhijit

Re: Apo 12

[Dan Sugalski]

At 8:11 AM -0700 4/19/04, Larry Wall wrote:
On Sat, Apr 17, 2004 at 01:12:58PM -0400, Austin Hastings wrote:
: If it's not totally obvious to everyone, you should download a copy of A12
: (I like the "printer-friendly" all-in-one-page version) as a hedge against
: the almost-inevitable slashdotting.
Or not...

Perhaps slashdot has decided they don't frontpage PhD dissertations.  :-)
For that they leave it to lambda.weblogs.com to heap *educated* scorn 
and derision on things. :)
--
Dan

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

Re: Apo 12: Space in method calls

[Larry Wall]

On Mon, Apr 19, 2004 at 10:37:57AM -0500, Abhijit A. Mahabal wrote:
: > $obj.meth,  -> obviously not arguments
: > $obj.meth $foo,$bar -> obviously arguments
: >
: 
:  $obj.meth() + $bat -> obviosly not arguments
:  $obj.meth () + $bat-> obviosly not arguments

No, obviously arguments.  Okay, I see the problem.  What you're missing
is that in an earlier Apocalypse, we said that postfix subscripts
and argument lists may not have an intervening space.

:  $obj.meth ($foo + $bar) + $bat -> ambiguous, likely to be list

No, obviously arguments.

:  $obj.meth($foo + $bar) + $bat  -> $foo + $bar the argument

Correct.

:  $obj.meth($foo + $bar), $bat   -> list

No, if you mean that $bat is the final argument to the method call.
Yes, if by that you mean the list is outside the method call.  The
absence of a space makes ($foo + $bar) a postfix argument-supplying
operator.  So this is parsed:

($obj.meth($foo + $bar)), $bat

: Is that about the story so far? Or is the last example probably going to
: be illegal without a space?

It's certainly not illegal, but it won't do what you want if you think
it'll pass $pat to $obj.meth.

: How bad is it to require space before arguments that are a list, so that
: the no-space case is unambiguous?

It may turn out that all the unambiguous cases do in fact require space
before the list (unless you use the explicit colon).  However, that doesn't
necessarily make it beneficial to declare that

$obj.meth+1

is unambiguous in the other direction.  I think if something is going
to be unclear to the *reader* of the code, we should probably not
make it easy to write it that way.

Larry

Re: placeholder attachment?

[Trey Harris]

In a message dated Mon, 19 Apr 2004, Larry Wall writes:
> On Mon, Apr 19, 2004 at 04:48:05AM -0600, Luke Palmer wrote:
> : Trey Harris writes:
> : > Can anyone explain the rules of placeholder attachment?  i.e., in the
> : > example in Perl6::Placeholder's manpage,
> : >
> : >   grep { $data{$^value} } 1..10;
> [...]
> : In your first example, it does what you mean because the hash subscript
> : isn't a closure.  Curlies are always closures, except when they're not
> : (to be specific, in hash subscripts and hash constructors).
>
> Yes, that's the basic rule.  In Perl 5 the curlies are (potentially)
> blocks, though the optimizer throws away the block entry and exit
> when it thinks it can.  In Perl 6 we'll just say that those aren't
> blocks.  If you really want a block inside a subscript, you can always
> use do {}.  (But merely putting semicolons inside a subscript turns
> it into a multidimensional subscript, not a block.)

Okay, thanks for setting me straight there.

> : > It's easy to just say "don't nest placeholder-using closures," but that
> : > doesn't seem workable in practice since every block is a closure, unless
> : > placeholders are forbidden from all but the most trivial cases.  Absurdly
> : > trivial, it seems.  How about
> : >
> : >   $sub = { if $^a { $^b = $^a } };
> :
> : I want this to work.  It could look at C's signature and see that
> : the closure it is expecting wants arguments, and since it doesn't, it
> : knows that they belong outside.  But that doesn't generalize.
>
> I don't think I want that to work.

Alright, you're the boss.  But it does make placeholders nearly useless,
does it not, by essentially limiting them to subs containing single
expressions?

> : I think a better solution would be to associate all placeholders with
> : the outermost closure that introduced a placeholder.  For example:
> :
> : $sub = { { $^a + $^b } };
> :
> : Would bind them both to the inner one, while:
> :
> : $sub = { $^a; { $^a + $^b } };
> :
> : Would bind them both to the outer one.
>
> This is the sort of twisty thinking that some people can keep straight
> and some people can't.  That's why we simplified the list of rules
> from the original placeholder RFC, after all.

What is the list of rules?  That's why I asked, and I'm still not clear
exactly what happens in the example I gave.  Saying that my example
shouldn't work only eliminates one of the possibilities, the one where it
works, while leaving all the ways it might not work open. It being
guaranteed to do what I don't mean is a step towards making what I mean be
something closer to what it does, but it would be helpful if I knew what
it does so that I can more finely adjust what I mean.  :-)

Trey

Is Dog|undef a legal type?

[Abhijit A. Mahabal]

If we have a method that returns Dog if it returns anything at all, can we
say:

method foo returns Dog|undef {...}

In a similar vein, if the function reurns a dog or a refernce to an array
, can we use  Dog|Array?

And is this legal:

given ($obj){
when Dog: ...
when Array: ...
   #obviously $obj can be a ref to an array, not itself an array
}

--Abhijit

Abhijit A. Mahabal  http://www.cs.indiana.edu/~amahabal/

Re: Apo 12: Space in method calls

[Abhijit A. Mahabal]

> No, obviously arguments.  Okay, I see the problem.  What you're missing
> is that in an earlier Apocalypse, we said that postfix subscripts
> and argument lists may not have an intervening space.

Oh, I see. Yes, I had missed that. Thanks for clearing that up.

--Abhijit

Re: set_string_native

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:35 PM +0200 4/16/04, Leopold Toetsch wrote:
>>This vtable currently copies the string.

> Yeah, and we've the same issue with set_pmc -- some of the versions
> make a copy and some just use the passed in PMC. (the
> get_[string|pmc] vtable methods have a similar issue--should they
> return the real thing or a copy?)

 assign Px, Sy   $1->vtable->assign_string_native  # copy string
 setPx, Sy   $1->vtable->set_string_native # refer to string

 assign Px, Py   $1->vtable->assign_pmc
 setPx, Py   $1->vtable->set_pmc

I'm not sure if we need the two different get vtable methods though. At
least there isn't any usage for these ;)

What about keyed variants of assign for strings and PMCs?

OTOH

  assign Px, Iy
  assign Px, Ny

could be aliased in the assembler to their C variants, so that we
can toss these opcodes.

leo

OSCON discount slots

[Dan Sugalski]

The folks at O'Reilly have handed me 20 discount slots for OSCON this 
year for "Parrot core contributors", whatever that's supposed to 
mean. These are 15% off the registration cost, and can be used with 
other discounts. (There's an early-bird 20% discount if you register 
before June 18th, so presumably that'd get you 35% off total)

I have no idea how many folks can actually use these, nor a really 
great way to fairly hand these out (nor what a "core contributor" is 
for us :) so here's the deal. I'll give 'em out to anyone who's 
submitted a patch or does other maintenance type stuff (runs 
tinderboxen, swamps out the RT queue, or whatever), on April 30th, to 
folks in the following order:

1) People who wouldn't otherwise be going to OSCON
2) People who are going but paying their own way
3) Everyone else
If there are any left, then it'll be to anyone who qualifies who 
wants one as you ask.
--
Dan

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

Re: Apo 12

[Larry Wall]

On Mon, Apr 19, 2004 at 11:44:24AM -0400, Dan Sugalski wrote:
: For that they leave it to lambda.weblogs.com to heap *educated* scorn 
: and derision on things. :)

Hmm, well, in all their educatedness, they don't seem to have figured
out that the prototyping behavior they're looking for is actually
supplied by wildcard delegation in Perl 6...

Larry

Re: Constant strings - again

[Jeff Clites]

On Apr 19, 2004, at 2:25 AM, Leopold Toetsch wrote:

We still can precalculate for these constant strings and save some 
extra
cylces (the precalculated value isn't used yet, but ...) And we can
precalculate hash values for the string constants in the constant table
during compilation (and write it into the PBC).
So the tradeoff there is that in the case of run-from-source it may be 
a slowdown (since we'll calculate hash values of some strings which may 
not be ever used as hash keys or lookup keys), but we can detect how we 
are running, and only calculate them if we are writing out byte code, 
so that should be a win.

We'll be in trouble if we ever change the hash algorithm, if we're 
freezing the result into PBC. So we should probably have something in 
the signature, so that if we detect that the algorithm may have 
changed, we ignore what's in the PBC, and fall back to cache-on-demand.

JEff

Re: Is Dog|undef a legal type?

[Larry Wall]

On Mon, Apr 19, 2004 at 11:00:33AM -0500, Abhijit A. Mahabal wrote:
: If we have a method that returns Dog if it returns anything at all, can we
: say:
: 
: method foo returns Dog|undef {...}

Yes, but...  You'd say that only if you wanted to allow a return
type that can be simultaneously Dog and undef, as well as either.
Remember that | is inclusive-OR, not exclusive.  The default meaning of

method foo returns Dog {...}

is actually

method foo returns Dog^undef {...}

since any Object is implicitly allowed to be undef instead.

: In a similar vein, if the function reurns a dog or a refernce to an array
: , can we use  Dog|Array?

Certainly.  Again, you might wish to be more specific with Dog^Array,
though Dog|Array will certainly work, and is arguably more readable.

: And is this legal:
: 
: given ($obj){
:   when Dog: ...
:   when Array: ...
:  #obviously $obj can be a ref to an array, not itself an array
: }

Yes.  Note that there's little distinction in Perl 6 between a ref to an
an array and the array itself.  If you use an array in scalar context, you
automatically get the reference.

Larry

Re: [perl #28915] parrotbug can only send mail

[Jerome Quelin]

Nicholas Clark (via RT) wrote:
> parrotbug can only send mail.
> This isn't that useful on systems where mail is accepted by sendmail,
> but will never get delivered.
> perlbug is able to save the bug report to a file, which can then be
> copied over to a system that can send mail.
>
> Would it be possible to add this to parrotbug?

It is planned: there's already a --output option, but is not yet 
implemented. I really need more tuits there.

I'll try to implement it asap.

Speaking about parrotbug, are the [EMAIL PROTECTED] addresses 
created? What do they currently do?


Jerome
-- 
[EMAIL PROTECTED]

Re: placeholder attachment?

[Dave Whipp]

"Trey Harris" <[EMAIL PROTECTED]> wrote i
> It's easy to just say "don't nest placeholder-using closures," but that
> doesn't seem workable in practice since every block is a closure, unless
> placeholders are forbidden from all but the most trivial cases.  Absurdly
> trivial, it seems.  How about
>
>   $sub = { if $^a { $^b = $^a } };

I would like to think that not all blocks have the same context. We could
define a "placeholder" scope as being a lexical scope that sends data to a
block. Thus C, C etc., all introduce lexical scopes that
are tagged as placeholder scopes; but C and C do not. Its a bit
like an inside-out-in-reverse C concept.


Dave.

Re: Is Dog|undef a legal type?

[Juerd]

Abhijit A. Mahabal skribis 2004-04-19 11:00 (-0500):
>   when Dog: ...
>   when Array: ...

Shouldn't that be:

when Dog { ... }
when Array { ... }

Or is there some .when that I have not yet heard of?


Juerd

Re: placeholder attachment?

[Larry Wall]

On Mon, Apr 19, 2004 at 08:57:47AM -0700, Trey Harris wrote:
: > : > It's easy to just say "don't nest placeholder-using closures," but that
: > : > doesn't seem workable in practice since every block is a closure, unless
: > : > placeholders are forbidden from all but the most trivial cases.  Absurdly
: > : > trivial, it seems.  How about
: > : >
: > : >   $sub = { if $^a { $^b = $^a } };
: > :
: > : I want this to work.  It could look at C's signature and see that
: > : the closure it is expecting wants arguments, and since it doesn't, it
: > : knows that they belong outside.  But that doesn't generalize.
: >
: > I don't think I want that to work.
: 
: Alright, you're the boss.  But it does make placeholders nearly useless,
: does it not, by essentially limiting them to subs containing single
: expressions?

Placeholders are by nature useless in anything complex if nobody can
figure out their scope.  The intent is to keep the rule simple enough
that you use placeholders for simple things, but -> $a,$b {...} for
more complex things.

Strictly speaking, they're not limited to single expressions.
You just can't put them into a subordinate closure.  You could have
any number of statements in your block.  But yes, the strong intent is
to discourage their use beyond simple expressions.  You may think that
anything that can't be completely generalized is "nearly useless", but
natural language is full of non-generalizable but nevertheless useful
idioms.  Linguists like to distinguish productive from non-productive
affixes, for instance.  A new productive suffix in English is -gate,
which means "the scandal associated with..."  On the other hand,
the bi- prefix is on the verge of dying in English, which is partly
why we found "bicoastal" funny when it was coined, I suspect.  By contrast,
the -ant suffix meaning "person who does..." is pretty much completely 
non-productive anymore.  That doesn't mean we stop using words like
"attendant", however.

: > : I think a better solution would be to associate all placeholders with
: > : the outermost closure that introduced a placeholder.  For example:
: > :
: > : $sub = { { $^a + $^b } };
: > :
: > : Would bind them both to the inner one, while:
: > :
: > : $sub = { $^a; { $^a + $^b } };
: > :
: > : Would bind them both to the outer one.
: >
: > This is the sort of twisty thinking that some people can keep straight
: > and some people can't.  That's why we simplified the list of rules
: > from the original placeholder RFC, after all.
: 
: What is the list of rules?  That's why I asked, and I'm still not clear
: exactly what happens in the example I gave.  Saying that my example
: shouldn't work only eliminates one of the possibilities, the one where it
: works, while leaving all the ways it might not work open. It being
: guaranteed to do what I don't mean is a step towards making what I mean be
: something closer to what it does, but it would be helpful if I knew what
: it does so that I can more finely adjust what I mean.  :-)

There is no list of rules.  There is only one rule:  Placeholders bind
to the most closely surrounding closure.

If you want a list of rules, go see RFC 23.  :-)

Larry

Re: Is Dog|undef a legal type?

[Abhijit A. Mahabal]

> Abhijit A. Mahabal skribis 2004-04-19 11:00 (-0500):
> > when Dog: ...
> > when Array: ...
>
> Shouldn't that be:
>
> when Dog { ... }
> when Array { ... }
>
> Or is there some .when that I have not yet heard of?

Guilty as charged. My Perl6 is getting rusty...

--Abhijit

Re: Is Dog|undef a legal type?

[Larry Wall]

On Mon, Apr 19, 2004 at 07:01:34PM +0200, Juerd wrote:
: Abhijit A. Mahabal skribis 2004-04-19 11:00 (-0500):
: > when Dog: ...
: > when Array: ...
: 
: Shouldn't that be:
: 
: when Dog { ... }
: when Array { ... }

Yes, that's how it should be written.

: Or is there some .when that I have not yet heard of?

Nope.  I was just reading the previous as pseudocode, so I didn't say
anything about it.

Larry

A12: Required Named Parameters Strike Back!

[John Siracusa]

Those with encyclopedic knowledge of the perl6-language list will recall my
impassioned, but ultimately futile plea for required named parameters--that
is, required arguments to a function that must be supplied as "pairs" rather
than positionally.

Here's a post from the middle of that old thread:

http://www.nntp.perl.org/group/perl.perl6.language/14689

Okay, so no one seemed to buy my argument the last time around, but now I'm
reading A12 and I see things like this:

http://www.perl.com/pub/a/2004/04/16/a12.html?page=7#the_default_constructor

> The arguments for the default constructor are always named arguments, hence
> the *%_ declaration to collect all those pairs and pass them on to bless.

http://www.perl.com/pub/a/2004/04/16/a12.html?page=9#multi_submethod_build

> It is not likely that Perl 6.0.0 will support multiple dispatch on named
> arguments, but only on positional arguments. Since all the extra arguments to
> a BUILD routine come in as named arguments, you probably can't usefully multi
> a BUILD (yet).

These passages may not seem directly relevant to my earlier argument, but I
think they do add something to the topic.

The first one confuses me a bit.  The default constructor has a *%_
signature, which means it slurps up all the named parameters.  It's obvious
that the default constructor is only interested in named params, but the
signature doesn't really enforce this, AFAICT.  If I call a default
constructor like this:

$dog = Dog.new(name => 'Fido', age => 7, 2, 'Brown', Collar.new());

then Perl 6 won't say boo at either compile time or runtime.  Or maybe I'm
wrong, but either way this isn't really an argument for required named
params since there are no required args to the default constructor anyway.
But I'm getting there (I hope), so bear with me :)

I'm not sure what the above would do, assuming the default new() doesn't
have a [EMAIL PROTECTED] term waiting at end of its signature to slurp up the args 7,
'Brown', and Collar.new().  Would those args just be ignored?  And what if
it was called like this?

$dog = Dog.new(2, name => 'Fido', age => 7, 'Brown', Collar.new());

Is that a compile-time or runtime error?  Hm.  Anyway, let's move on.

Let's supposed that I don't like the default constructor and want to replace
it with one of my own.  I decode that an object of my Dog class cannot be
instantiated without a name, age, and id.  But being a good Perl 6 citizen,
I document the usage of my constructor like this:

$dog = Dog.new(name => 'Fido', age => 7, id => 2);

After all, according to A12, "arguments for the default constructor are
always named arguments", so I'm trying to follow suit.  I don't want my
customized constructor to be needlessly different than the default
constructor.  Unfortunately, the signature for my constructor has to be:

method new($name, $age, $id, *%rest) { ... }

which means that, regardless of how I document the API, someone can do this:

$dog = Dog.new('Fido', 2, 7);

and there's nothing I can do to stop them.

...so, did you catch the fact that the second example is a two year-old dog
instead of a seven year-old dog?  Maybe, maybe not, which is part of why I,
as the API designer, decided that those params should named.

Even more importantly, I decided to use named params because there's no
"natural" or implied order for the name, age, and id attributes.  It's
completely arbitrary.

Okay, so it's arbitrary.  Then why can't I just maintain that arbitrary
order forever and ever?  In fact, if I do nothing, it will be maintained.
So what's the problem?

Yes, the answer is that "it's the principle."  Name, age, and id are
required, but there is no implied order.  I want them to be named params.  I
am the API designer.  I think it will reduce errors and make code that uses
my Dog object easier to read and maintain.

It's not as if I'm forbidding Dog users from using the indirect object
syntax or something like that.  My demands are modest, useful,  and
certainly no more onerous or "B&D"-esque than choosing method names or
deciding which arguments are required or any of the other things that an API
designer does. 

Obviously the Perl 6 Language Design Illuminati have at least a few thoughts
in a similar direction.  "The arguments for the default constructor are
always named arguments" because constructors often initialize lots of
attributes, and those attributes rarely have a natural or implied order.
Constructors just plain look and work better with named params.  (The only
possible exception is a special-case for a single argument.)

But, ha ha, that's too bad if you also decide that some of the constructor
params are required!  Even if nothing has changed about the lack of a
natural or implied order of the arguments, you, as the API designer, are
forced to both *choose* and *maintain forever* an arbitrary order for your
params!

I think this is a bad thing.

This may seem like it has turned into just a repeat of the Synopsis 6
discuss

Re: Apo 12

[John Siracusa]

On 4/19/04 11:11 AM, Larry Wall wrote:
> On Sat, Apr 17, 2004 at 01:12:58PM -0400, Austin Hastings wrote:
> : If it's not totally obvious to everyone, you should download a copy of A12
> : (I like the "printer-friendly" all-in-one-page version) as a hedge against
> : the almost-inevitable slashdotting.
> 
> Or not...
> 
> Perhaps slashdot has decided they don't frontpage PhD dissertations.  :-)

Yeah, but did you see the story about that awesome new D language?  It has a
native "dictionary" type!

-John

Re: placeholder attachment?

[Larry Wall]

On Mon, Apr 19, 2004 at 09:42:14AM -0700, Dave Whipp wrote:
: "Trey Harris" <[EMAIL PROTECTED]> wrote i
: > It's easy to just say "don't nest placeholder-using closures," but that
: > doesn't seem workable in practice since every block is a closure, unless
: > placeholders are forbidden from all but the most trivial cases.  Absurdly
: > trivial, it seems.  How about
: >
: >   $sub = { if $^a { $^b = $^a } };
: 
: I would like to think that not all blocks have the same context. We could
: define a "placeholder" scope as being a lexical scope that sends data to a
: block. Thus C, C etc., all introduce lexical scopes that
: are tagged as placeholder scopes; but C and C do not. Its a bit
: like an inside-out-in-reverse C concept.

We can certainly outlaw placeholders in scopes that already specify
the argument list externally (including when there are no arguments
for C et al.).  But what we're *not* going to do is complexify
the rules about which closure the placeholders try to bind to in the
first place.  Useless generalization is a really good place to trim
the complexity of a language.  And generalizing placeholders would be
useless, in my estimation, particularly since we introduced the ->
notation as an intermediate form specifically to take away the need
to generalize placeholders.

Larry

Re: Apo 12

[Larry Wall]

On Mon, Apr 19, 2004 at 01:19:36PM -0400, John Siracusa wrote:
: On 4/19/04 11:11 AM, Larry Wall wrote:
: > On Sat, Apr 17, 2004 at 01:12:58PM -0400, Austin Hastings wrote:
: > : If it's not totally obvious to everyone, you should download a copy of A12
: > : (I like the "printer-friendly" all-in-one-page version) as a hedge against
: > : the almost-inevitable slashdotting.
: > 
: > Or not...
: > 
: > Perhaps slashdot has decided they don't frontpage PhD dissertations.  :-)
: 
: Yeah, but did you see the story about that awesome new D language?  It has a
: native "dictionary" type!

Hey, it supports C syntax, so maybe we could compile Parrot in it.  :-)

Larry

Re: A12: Required Named Parameters Strike Back!

[Larry Wall]

On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
: I know we are running out of special characters, but I really, really think
: that required named parameters are a natural fit for many common APIs.  A12
: has reinforced that belief.  Save me, Dami-Wan Wallnobi, you're my only
: hope...

Well, actually, we saved you last summer when we decided to make +
mean that the parameter must be named.

Larry

Re: A12: Required Named Parameters Strike Back!

[Dan Sugalski]

At 1:14 PM -0400 4/19/04, John Siracusa wrote:
I know we are running out of special characters, but I really, really think
that required named parameters are a natural fit for many common APIs.
Well... maybe, but ponder a likely common case--automatically 
redelegated initialization methods with classes that have parents 
written in languages without named parameters. (Like, say, all the 
rest...)
--
Dan

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

Re: set_string_native

[Dan Sugalski]

At 6:04 PM +0200 4/19/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
 At 5:35 PM +0200 4/16/04, Leopold Toetsch wrote:
This vtable currently copies the string.

 Yeah, and we've the same issue with set_pmc -- some of the versions
 make a copy and some just use the passed in PMC. (the
 get_[string|pmc] vtable methods have a similar issue--should they
 return the real thing or a copy?)
 assign Px, Sy   $1->vtable->assign_string_native  # copy string
 setPx, Sy   $1->vtable->set_string_native # refer to string
 assign Px, Py   $1->vtable->assign_pmc
 setPx, Py   $1->vtable->set_pmc
I'm not sure if we need the two different get vtable methods though. At
least there isn't any usage for these ;)
Well, think of aggregates (where it's most likely to be used) where 
you'd want to either get a copy of an element (because you don't want 
to modify what was in the aggregate) or the actual element itself 
(because you do, and don't want to re-store the value in the 
aggregate. That's where I can see this being really useful.
--
Dan

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

Re: A12: Required Named Parameters Strike Back!

[John Siracusa]

On 4/19/04 1:30 PM, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
> : I know we are running out of special characters, but I really, really think
> : that required named parameters are a natural fit for many common APIs.  A12
> : has reinforced that belief.  Save me, Dami-Wan Wallnobi, you're my only
> : hope...
> 
> Well, actually, we saved you last summer when we decided to make +
> mean that the parameter must be named.

...named and required, or named and optional?  IOW, is this all true?

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

foo();  # compile-time error!
foo(1, 2);  # compile-time error!
foo(a => 1, 2); # compile-time error!
foo(a => 1);# compile-time error!

foo(a => 5, b => 7); # ok
foo(b => 1, a => 2); # ok

-John

Re: A12: Required Named Parameters Strike Back!

[Jonathan Scott Duff]

On Mon, Apr 19, 2004 at 10:30:18AM -0700, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
> : I know we are running out of special characters, but I really, really think
> : that required named parameters are a natural fit for many common APIs.  A12
> : has reinforced that belief.  Save me, Dami-Wan Wallnobi, you're my only
> : hope...
> 
> Well, actually, we saved you last summer when we decided to make +
> mean that the parameter must be named.

Except that last time I read, named parameters are always optional. So,
if John wants perl to carp when any of the name, age, or id is
unspecified, he's back to manually checking the parameters at run-time.
Maybe that's a feature.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: A12: Required Named Parameters Strike Back!

[John Siracusa]

On 4/19/04 1:41 PM, Dan Sugalski wrote:
> At 1:14 PM -0400 4/19/04, John Siracusa wrote:
>> I know we are running out of special characters, but I really, really think
>> that required named parameters are a natural fit for many common APIs.
> 
> Well... maybe, but ponder a likely common case--automatically
> redelegated initialization methods with classes that have parents
> written in languages without named parameters. (Like, say, all the
> rest...)

Then either make the order part of the API ("Sorry, we're using a C lib!")
or provide "manual" delegation with an arg-ordering wrapper.  Calling out to
lesser languages is always bound to be crufty... ;)

-John

Minor confusion

[Jonathan Scott Duff]

Quoting A12...
> Note that an attribute declaration of the form
> 
> has Tail $wagger .= new(...)
> 
> might not do what you want done when you want it done, if what you
> want done is to create a new Dog object each time an object is built.
> For that you'd have to say:
> 
> has Tail $wagger = { .new(...) }
> 
> or equivalently,
> 
> has Tail $wagger will build { .new(...) }

Since $wagger is meant to be an object attribute, shouldn't it have a
dot?  And is omitting the dot an error?

has Tail $.wagger = { .new(...) }   # right?

Also, based on the earlier assertion that closure valued attributes
get the attribute as the topic, shouldn't the text say "to create a
new Tail object" rather than "Dog"?  i.e.,

has Tail $.wagger = { .new(...) }   # is the same as
has Tail $.wagger = { $.wagger.new(...) }

which does some appropriate magic to call Tail.new because $.wagger
hasn't been initialized yet. Or is Tail also a Dog somehow? What happens
if the attribute is untyped? Presumably that's an error.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

A12: Naming Police - "P6opaque"

[John Siracusa]

>From page 7:

> In any event, strings are reserved for other object layouts. We could
> conceivably have things like:
>
>return $class.bless("Cstruct", *%_);
>
> So as it happens, 0 is short for the layout "P6opaque".

I feel like "we" have pretty well staked out the letters p-e-r-l, but
anything else is still up for grabs.  (I think I brought this up before on
the internals list regarding the PL_ prefix.)

The C language probably has a good claim on "C", but I think it's unwise for
us try to squat on P\d+, especially when this is such a rare use (first arg
to bless) and three extra characters are not the end of the world.  What
happens in 5 years when the super-popular "P6" language starts sweeping the
nation?  Oops.  Also, "Perl6" makes for better documentation than "P6".

So, how about "Perl6opaque" (or "Perl6Opaque"), just to be safe :)

-John

Re: A12: Required Named Parameters Strike Back!

[Dan Sugalski]

At 1:50 PM -0400 4/19/04, John Siracusa wrote:
On 4/19/04 1:41 PM, Dan Sugalski wrote:
 At 1:14 PM -0400 4/19/04, John Siracusa wrote:
 I know we are running out of special characters, but I really, really think
 that required named parameters are a natural fit for many common APIs.
 Well... maybe, but ponder a likely common case--automatically
 redelegated initialization methods with classes that have parents
 written in languages without named parameters. (Like, say, all the
 rest...)
Then either make the order part of the API ("Sorry, we're using a C lib!")
or provide "manual" delegation with an arg-ordering wrapper.  Calling out to
lesser languages is always bound to be crufty... ;)
Um. Yeah. I think it's safe to say you're going to have positional 
args in core APIs for an awfully long time to come.
--
Dan

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

A12: default accessors and encapsulation

[John Siracusa]

Let's say I have a class with some attributes:

class Dog;

has $.name is rw;
has $.age is rw;
has $.gender is rw;

I initially decide to accept the default accessors.

$dog.name = 'Ralph';
print $dog.age;

This works well for a while, but then I decide to update Dog so that setting
the name also sets the gender.

$dog.name = 'Susie'; # also sets $dog.gender to 'female'

How do I write such a name() method?  Do I just check the arg, set the
gender, and then return $.name as an "lvalue" or something?

If so, what happens if, some time down the road, the $.name attribute goes
away entirely?  I can't return it as an lvalue now, can I?

Basically, I'm wondering how much of the object's internals I'm exposing by
accepting the default accessors.

-John

Re: A12: default accessors and encapsulation

[Juerd]

John Siracusa skribis 2004-04-19 14:20 (-0400):
> has $.gender is rw;
> (...)
> This works well for a while, but then I decide to update Dog so that setting
> the name also sets the gender.
> $dog.name = 'Susie'; # also sets $dog.gender to 'female'
> How do I write such a name() method?  Do I just check the arg, set the
> gender, and then return $.name as an "lvalue" or something?

IIRC, something like

has $.name is rw is STORE { ... };

> If so, what happens if, some time down the road, the $.name attribute goes
> away entirely?  I can't return it as an lvalue now, can I?

Why not?


Juerd

Re: PMC constants

[Dan Sugalski]

At 4:39 PM +0200 4/16/04, Leopold Toetsch wrote:
While trying to speed up hash lookups [1] I came (again) to the 
problem that we are missing true PMC constants. We just have a 
special Sub PMC for storing subroutine entries but no general way to 
represent a constant PMC item. E.g.:

   .const pmc s = "value"
   .const pmc i = 1
   ...
   add $P0, i
   setprop $P0, "xxx", s
This would AFAIK not need a lot more opcode variants, because where 
we now have C and C, we would then just have 
C[2]. Only some ops that take PMCs only would need 
additional variants like setprop_p_sc?_pc.
I'm currently thinking of constant scalar PMCs only, but this could 
get generalized to constant aggregates too.
I'm all for constant PMCs--they've been in the base design since the 
beginning, and I'd love to get them in and running.

The interpreter stuff's simple enough--we teach the ops preprocessor 
to handle them the same way that it does string constants, and index 
into the PMC constant table. We'll want to put them in a separate 
part of the bytecode file, so we probably ought to nail down metadata 
so we can fully expose bytecode files to running code. And we need to 
finish that fight over freeze/thaw methodologies, as constant PMCs 
would end up being frozen in the bytecode.

As for the actual declaration of the constants... That's going to be 
somewhat interesting. I can see one of two ways of doing it:

1) we execute the initialization code at compiletime and freeze the result
2) We compile the initialization code and execute it at runtime to 
create the PMC

Both have their drawbacks when it comes to more complex PMCs. For 
simple stuff it's not a big deal one way or the other, and for the 
base PMC types we can even cheat and teach imcc how to create the 
freeze format directly, but that's not tenable as a full solution.
--
Dan

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

Re: set_string_native

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:04 PM +0200 4/19/04, Leopold Toetsch wrote:
>>
>>I'm not sure if we need the two different get vtable methods though. At
>>least there isn't any usage for these ;)

> Well, think of aggregates (where it's most likely to be used)

That was the next question, you'd snipped away :)

  setSx, Py
  assign Sx, Py

don't access aggregates.

The assign forms

  setSx, Py[Iz]# implemented
  assign Sx, Py[Iz]# needed?

  newSx, Py[Iz]# or even
  newPx, Py[Iz]# these 2?

and the PMC variants (and different _keyed variants) are missing.

All the assigned get can be done (or should at least) with an additional
instruction, which could be a shallow clone. The set vs assign "set"
instruction can't be emulated. I'm still in favour of keeping the opcode
count as small as needed. Parrot's opcode dispatch is fast enough to
deal with that. Cache misses due to huge opfiles are issues, which
can't be delt with. The same idea holds for vtable size.

leo

Re: Minor confusion

[Larry Wall]

On Mon, Apr 19, 2004 at 01:02:36PM -0500, Jonathan Scott Duff wrote:
: Quoting A12...
: > Note that an attribute declaration of the form
: > 
: > has Tail $wagger .= new(...)
: > 
: > might not do what you want done when you want it done, if what you
: > want done is to create a new Dog object each time an object is built.
: > For that you'd have to say:
: > 
: > has Tail $wagger = { .new(...) }
: > 
: > or equivalently,
: > 
: > has Tail $wagger will build { .new(...) }
: 
: Since $wagger is meant to be an object attribute, shouldn't it have a
: dot?  And is omitting the dot an error?
: 
:   has Tail $.wagger = { .new(...) }   # right?

Yes, and yes.

: Also, based on the earlier assertion that closure valued attributes
: get the attribute as the topic, shouldn't the text say "to create a
: new Tail object" rather than "Dog"?  i.e.,
: 
:   has Tail $.wagger = { .new(...) }   # is the same as
:   has Tail $.wagger = { $.wagger.new(...) }
: 
: which does some appropriate magic to call Tail.new because $.wagger
: hasn't been initialized yet. Or is Tail also a Dog somehow? What happens
: if the attribute is untyped? Presumably that's an error.

Yes, it should have said "Tail".

Larry

Re: A12: Naming Police - "P6opaque"

[Larry Wall]

On Mon, Apr 19, 2004 at 02:04:55PM -0400, John Siracusa wrote:
: >From page 7:
: 
: > In any event, strings are reserved for other object layouts. We could
: > conceivably have things like:
: >
: >return $class.bless("Cstruct", *%_);
: >
: > So as it happens, 0 is short for the layout "P6opaque".
: 
: I feel like "we" have pretty well staked out the letters p-e-r-l, but
: anything else is still up for grabs.  (I think I brought this up before on
: the internals list regarding the PL_ prefix.)

Well, this is all from the viewpoint of Perl anyway...it's probably an
enum internally in any event, and any language can give the values any
names they please.

: The C language probably has a good claim on "C",

Does that mean I can't use "Class".  :-)

: but I think it's unwise for
: us try to squat on P\d+, especially when this is such a rare use (first arg
: to bless) and three extra characters are not the end of the world.  What
: happens in 5 years when the super-popular "P6" language starts sweeping the
: nation?  Oops.  Also, "Perl6" makes for better documentation than "P6".
: 
: So, how about "Perl6opaque" (or "Perl6Opaque"), just to be safe :)

How 'bout just "Opaque", meaning Parrot's native object type, or whatever
the native opaque type is for the platform in question.

But I really don't care, as long as I have the 0 shortcut.

Larry

Re: A12: Naming Police - "P6opaque"

[John Siracusa]

On 4/19/04 3:36 PM, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 02:04:55PM -0400, John Siracusa wrote:
> : So, how about "Perl6opaque" (or "Perl6Opaque"), just to be safe :)
> 
> How 'bout just "Opaque", meaning Parrot's native object type, or whatever
> the native opaque type is for the platform in question.
> 
> But I really don't care, as long as I have the 0 shortcut.

I'm disappointed that you didn't suggest 0paque ;)

I'm fine with Opaque too.  I just object to needless (and possibly
ambiguous) abbreviation.

-John

RE: A12: default accessors and encapsulation

[Austin Hastings]

> -Original Message-
> From: John Siracusa [mailto:[EMAIL PROTECTED]
> Sent: Monday, 19 April, 2004 02:21 PM
> To: Perl 6 Language
> Subject: A12: default accessors and encapsulation
>
>
> Let's say I have a class with some attributes:
>
> class Dog;
>
> has $.name is rw;
> has $.age is rw;
> has $.gender is rw;
>
> I initially decide to accept the default accessors.
>
> $dog.name = 'Ralph';
> print $dog.age;
>
> This works well for a while, but then I decide to update Dog so
> that setting
> the name also sets the gender.
>
> $dog.name = 'Susie'; # also sets $dog.gender to 'female'
>
> How do I write such a name() method?  Do I just check the arg, set the
> gender, and then return $.name as an "lvalue" or something?

class Afghan
is Dog
{
does Hunter;
does AKC;

has $.name is rw
will STORE { .set_name($^name); };

has $.taliban is OppressiveGovernment;

method set_name($self: String $name) {
DESTROY unless $.taliban.approves($name);

given ($name) {
when  {
...
}

...
}
}
}


>
> If so, what happens if, some time down the road, the $.name attribute goes
> away entirely?  I can't return it as an lvalue now, can I?

method name(String ?$name) {...}

>
> Basically, I'm wondering how much of the object's internals I'm
> exposing by accepting the default accessors.

Since lvalue subs/methods are easy, and $obj.attr looks like $obj.method
with no args, it should be pretty trivial to drop in a replacement if you
decide you don't like the attribute-based solution.

You are a little committed, since <$dog.name = "fred"> does assume that
you've got a reference to something you can pass back, but that's about it.

You can leave the "name" attribute around as a placeholder and let the STORE
block update the "official" location, or you could return some sort of
proxy-lvalue object that wasn't really a part of Dog:

class WeaselDog
is Dog
{
class PhonyAttr
{
$.store;
$.fetch;

method STORE { $.store($^value); return $_; }
method FETCH { return $.fetch(); }
}

method set_name(String $name) {...}
method get_name() {...}

method name is rw {
return new PhonyAttr(
object => $_,
store => { .set_name $^name; },
fetch => { .get_name; }
);
}
}


=Austin

Re: A12: default accessors and encapsulation

[John Siracusa]

On 4/19/04 3:58 PM, Austin Hastings wrote:
>> I initially decide to accept the default accessors.
>> 
>> $dog.name = 'Ralph';
>> print $dog.age;
>> 
>> This works well for a while, but then I decide to update Dog so that setting
>> the name also sets the gender.
>> 
>> $dog.name = 'Susie'; # also sets $dog.gender to 'female'
>> 
>> How do I write such a name() method?
>
> has $.name is rw
> will STORE { .set_name($^name); };

The "will STORE" stuff covers the easy cases, but can I extend it all the
way up to a name() that's a multimethod with a ton of optional args?  I
supposed you can (technically) do all of that with "will STORE", but it
seems an odd place for what would more naturally be code in the name()
method itself.

> You can leave the "name" attribute around as a placeholder and let the STORE
> block update the "official" location, or you could return some sort of
> proxy-lvalue object that wasn't really a part of Dog

Heh, getting progressively more scary :)

>From the point of view of the person coding the new, fancier name() method,
it would be nice if some magic would make all existing calls to

$dog.name = 'foo';

look like this inside the new name() method

$dog.name('foo');

but I supposed that really hoses the meaning of "=" :)

The alternate techniques suggested are powerful, but they also strike me as
slightly heroic.  I can imaging using them to patch or extend some existing
code, but starting a Perl 6 class from scratch, I'd really have to think
about the costs of using the default accessors at all.

One work-around might be an alternate kind of default accessor that doesn't
allow assignment:

$dog.name # get
$dog.name('foo')  # set
$dog.name = 'foo' # compile-time error

That is a lot more directly (and simply) "future-proof" than the "is rw"
accessor.

I'd either like a way to more cleanly extend the default accessor's
assignment behavior down the road (i.e. by just writing a new name() method,
not by hacking away at STORE traits and adding private worker subs) or a way
to auto-generate the slightly more "boring" default accessor shown above.

I'd prefer the former since I'm hoping to avoid the likes of
Class::MethodMaker as long as possible in the world of Perl 6 :)

In the absence of both, I can imaging that 5 years into the life of 6PAN, a
substantial portion of the Perl 6 modules will have STORE hooks on what they
originally thought would be "simple" attributes that don't need full-blown
accessors... :)

-John

Re: backticks (or slash, maybe)

[Angel Faus]

Miércoles 14 Abril 2004 14:18, Juerd wrote:
> I propose to use ` as a simple hash subscriptor, as an alternative
> to {} and <<>>. It would only be useable for \w+ keys or perhaps
> -?\w+. As with methods, a simple "atomic" (term exists only in
> perlreftut, afaix, but I don't know another word to describe a
> simple scalar variable) scalar should be usable too.

If we really need a ultra-huffman encoding for hash subscriptors, I 
have always dreamt of being able to do:

  %hash/key
  $hashref/foo/bar/baz/quux
  ...

If only because of the filesystem analogy. Because a filesystem is 
really just a very big tied hash, isn't it?

The idea would be be to replace the %hash{'key'} notation by the slash 
one, thus making {} always mean a closure without nothing to do with 
subscripting.

It would work just like with methods so we would have:

   %hash/key # like $obj.method
   %hash/$key   # like $obj.$method

   %hash/{ some_func() } # dynamic key
   %hash/«key1 key2» # hash slice
   %hash/['key', 'key2']  # the same

The benefits I see in terms of clarity are:

   * {} means one thing (closure) and just one

   * « and » have only two meanings (literal array and hyperoperator) 
instead of three

   * «a b» and ['a', 'b'] are always substitutable, ever

The cultural assumption of / as a subscripter is further reinforced 
with the omnipresence of xpath these days. We could play some tricks 
with this, too. A xml library could make every node a tied hash, 
effectively embedding a good portion of xpath within perl:

  my $price = $doc/books[14]/price;

  for $doc/books -> $book {
 print "Price is $book/price and title is $book/title";
  }
  
(scalar and array context with help us to overcome the "an xpath 
expression always returns a sequence syndrome")

Pushing the analogy a bit too further away, one could hack the grammar 
so that a leading / does indicate the root directory in the system 
(and a leading ./ indicates the current directory), thus letting me 
write:

   for /home/angel -> $file {
print $file;  
   }

   
Which looks cute for shell scripting, althought a bit dangerous maybe.

And so on...

The beauty (?) of this is not so much in that we should play these 
tricks, but in that we are reusing a good deal of cultural background 
in them.

Oh, and saving a few keystrokes when you are dealing with hashes the 
whole day (say, because you are using DBI, or extracting some data 
from an XML document, or whatever) is not totally unpleasing.

-angel

Re: backticks (or slash, maybe)

[Juerd]

Angel Faus skribis 2004-04-19 22:43 (+0200):
> If we really need a ultra-huffman encoding for hash subscriptors, I 
> have always dreamt of being able to do:
>   %hash/key
>   $hashref/foo/bar/baz/quux
>   ...

I'd hate to give up dividing slash. It's one of the few operators that I
sometimes type without whitespace. Simple because 1/10 is good enough
and 1 / 10 is very wide.

Other than that, I like it. But it isn't really doable.

>%hash/{ some_func() } # dynamic key
>%hash/«key1 key2» # hash slice
>%hash/['key', 'key2']  # the same

I think this is not a good idea. 

>* «a b» and ['a', 'b'] are always substitutable, ever

Only because they are here, doesn't mean they are everywhere.

> A xml library could make every node a tied hash, effectively embedding
> a good portion of xpath within perl

Hmm... If only the slash weren't used by something extremely important.

>for /home/angel -> $file {

That would mean giving up // for regexes (i.e. making the m mandatory).
And I think having quotes for strings other than very simple ones
(anything containing a / is not a simple string imho) is good for
readability.


Juerd

Re: backticks (or slash, maybe)

[Sean O'Rourke]

[EMAIL PROTECTED] (Juerd) writes:

> Angel Faus skribis 2004-04-19 22:43 (+0200):
>> If we really need a ultra-huffman encoding for hash subscriptors, I 
>> have always dreamt of being able to do:
>>   %hash/key
>>   $hashref/foo/bar/baz/quux
>>   ...
>
> I'd hate to give up dividing slash. It's one of the few operators that I
> sometimes type without whitespace. Simple because 1/10 is good enough
> and 1 / 10 is very wide.

You can have both, though.

>>for /home/angel -> $file {
>
> That would mean giving up // for regexes (i.e. making the m
> mandatory).

Since modifiers have to be up front, and since hash slices won't have
a trailing '/', I don't think there's any ambiguity -- anything ending
in a '/' is a regex, anything otherwise is a hash slice.

/s

package DH;
require Tie::Hash;

@ISA = 'Tie::StdHash';

sub TIEHASH {
return bless {}, 'DH';
}

sub SCALAR {
return shift;
}

sub STORE {
my ($h, $k, $v) = @_;
$h->{$k} = $v;
}

use overload '/' => sub {
my ($x, $y, $rev) = @_;
if (!$rev) {
if (ref $y eq 'ARRAY') {
return [EMAIL PROTECTED]@$y}];
} else {
return $x->{$y};
}
} else {
return $y / keys %$x;
}
};

package main;

my %h;
tie %h, 'DH';
%h = qw(a 1 b 2 c 3);

my $xs = %h / [qw(a c)];
print %h / 'a', "\n";
print "@$xs\n";

Re: backticks (or slash, maybe)

[Juerd]

Sean O'Rourke skribis 2004-04-19 15:11 (-0700):
> > I'd hate to give up dividing slash. It's one of the few operators that I
> > sometimes type without whitespace. Simple because 1/10 is good enough
> > and 1 / 10 is very wide.
> You can have both, though.

But not in a way that makes $foo/$bar divide $foo by $bar, if $foo is a
hashref.

> > That would mean giving up // for regexes (i.e. making the m
> > mandatory).
> Since modifiers have to be up front, and since hash slices won't have
> a trailing '/', I don't think there's any ambiguity -- anything ending
> in a '/' is a regex, anything otherwise is a hash slice.

I don't understand. Could you give some examples? Is this in the context
of bare /path/to/foo, even?


Juerd

Re: backticks (or slash, maybe)

[Sean O'Rourke]

[EMAIL PROTECTED] (Juerd) writes:

> Sean O'Rourke skribis 2004-04-19 15:11 (-0700):
>> > I'd hate to give up dividing slash. It's one of the few operators that I
>> > sometimes type without whitespace. Simple because 1/10 is good enough
>> > and 1 / 10 is very wide.
>> You can have both, though.
>
> But not in a way that makes $foo/$bar divide $foo by $bar, if $foo is a
> hashref.

I'm saying "division" is now defined such that when the numerator is
a hash(-ref), the result is the set of values associated with the
denominator.  I've never tried to divide a hash or hashref by
something without it being a bug.

>> > That would mean giving up // for regexes (i.e. making the m
>> > mandatory).
>> Since modifiers have to be up front, and since hash slices won't have
>> a trailing '/', I don't think there's any ambiguity -- anything ending
>> in a '/' is a regex, anything otherwise is a hash slice.
>
> I don't understand. Could you give some examples? Is this in the context
> of bare /path/to/foo, even?

Sure:

/foo/   # trailing slash -- so it's a regexp (m/foo/)
/foo\/bar/  # trailing slash -- syntax error (m/foo/ bar/)
/foo/a  # hash-path -- no trailing slash ($_.{'foo'}{'a'})
/foo\/bar   # hash-path -- no trailing slash ($_.{'foo/bar'})
/foo\/  # hash-path -- no trailing slash ($_.{'foo/'})


/s

Re: backticks (or slash, maybe)

[Matthijs van Duin]

On Mon, Apr 19, 2004 at 03:34:13PM -0700, Sean O'Rourke wrote:
in a '/' is a regex, anything otherwise is a hash slice.
I don't understand. Could you give some examples? Is this in the context
of bare /path/to/foo, even?
   /foo/   # trailing slash -- so it's a regexp (m/foo/)
   /foo\/bar/  # trailing slash -- syntax error (m/foo/ bar/)
   /foo/a  # hash-path -- no trailing slash ($_.{'foo'}{'a'})
   /foo\/bar   # hash-path -- no trailing slash ($_.{'foo/bar'})
   /foo\/  # hash-path -- no trailing slash ($_.{'foo/'})
I think this is highly ambiguous.

$x = /foo * $bar/and +bar();

would that be:

$x = m/foo* $bar/ && (+bar());
 or
$x = $_.{'foo'} * $bar.{'and'} + bar();
?

As much as I see the appeal of this syntax, the / is simply too heavily used 
already.

--
Matthijs van Duin  --  May the Forth be with you!

Re: backticks (or slash, maybe)

[Juerd]

Sean O'Rourke skribis 2004-04-19 15:34 (-0700):
> I'm saying "division" is now defined such that when the numerator is
> a hash(-ref), the result is the set of values associated with the
> denominator.  I've never tried to divide a hash or hashref by
> something without it being a bug.

I understand now. But that means the meaning of the / is unknown until
runtime, which means $foo/0 can't be a compile time error.

And it doesn't quote the thing after it, which means still doing a lot
of typing.

$foo/bar should be a compile time error (Perl 6 has no barewords) if
$foo is not a hashref, but be $foo{'bar'} if it is. Waiting for runtime
is bad, I think.

> /foo/   # trailing slash -- so it's a regexp (m/foo/)
> /foo\/bar/  # trailing slash -- syntax error (m/foo/ bar/)
> /foo/a  # hash-path -- no trailing slash ($_.{'foo'}{'a'})
> /foo\/bar   # hash-path -- no trailing slash ($_.{'foo/bar'})
> /foo\/  # hash-path -- no trailing slash ($_.{'foo/'})

Thanks. Now I'm sure I don't like the bare path idea. After a hash,
perhaps it's doable, and even "if -r /etc/passwd" is doable, but there
are too many allowed characters in filenames (on my system: any
character except \0 and /).


Juerd

Re: A12: default accessors and encapsulation

[John Siracusa]

On 4/19/04 4:47 PM, [EMAIL PROTECTED] wrote:
>> On 4/19/04 3:58 PM, Austin Hastings wrote:
>> One work-around might be an alternate kind of default accessor that doesn't
>> allow assignment:
>> 
>> $dog.name # get
>> $dog.name('foo')  # set
>> $dog.name = 'foo' # compile-time error
> 
> I think we already have this.  Just define a non-rw attribute and then
> add your own writer as a multi-method.
> 
> has Str $.name;
> multi method name(Str $n) {$.name = $n;}

Yeah, that's exactly what I don't want to type over and over :)  It's not
much better than the old Perl 5 standby:

sub name { @_ > 1 ? $_[0]->{'name'} = $_[1] : $_[0]->{'name'} }

since once I have to write something, the time and effort savings is pretty
much cancelled out.

-John

ICU Win32 Issues

[Marcus Thiesen]

Hi,

most of you might have recognized it by now but M$ released it's compiler to 
the public yesterday (I know it has been there before, but everybody sells it 
as real news). As I'm currently at my fathers place I had the time and 
resources to do some cygwin and native win32 testing.

I can't get it to work under Cygwin since the ICU changes because it tries to 
do some linking stuff that fails, I believe the important parts are:
/usr/bin/ar: creating libicuctestfw.a
/usr/bin/ar: creating libicutoolutil.a
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: 
cannot find -licutoolutil26
collect2: ld returned 1 exit status
make[2]: *** [makeconv.exe] Error 1
make[1]: *** [all-recursive] Error 2
make: *** [blib/lib/libicuuc.a] Error 2

As I couldn't find any icutoolutil26* file and didn't find a cygwin version I 
stopped for today. 

Next I tried native Win32, where I got another ICU issue (do we *really* need 
unicode? :-). It seems as if ICU needs not only a (n)make and a compiler, but 
depends on msdev.exe, which seems to be the executable for the M$ Devel 
Studio which can also be used on the command line. It alway complains about 
the missing file, and as I didn't have an MS Dev studio, I stopped for today.

So, after a hard days work, no real success :-(

Have fun,
Marcus

-- 
 :: Marcus Thiesen :: www.thiesen.org :: ICQ#108989768 :: 0x754675F2 :: 

Time is an illusion. Lunchtime doubly so
Douglas Adams

Duplicated code

[Ovid]

As part of our refactoring project, we'd like to find duplicated code.  Our 
hand-rolled scripts do
a decent job, but could use a lot of work.  Rather than do a lot of work, I'm curious 
to know if
anyone knows of any tools already out there for that.

Any suggestions?  I'd be rather curious to hear about something that operates on the 
op-code level
and can possibly cope with renamed variables as a result.

Cheers,
Ovid

=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

Re: Duplicated code

[Adrian Howard]

On 19 Apr 2004, at 21:03, Ovid wrote:

As part of our refactoring project, we'd like to find duplicated code. 
 Our hand-rolled scripts do a decent job, but could use a lot of work. 
 Rather than do a lot of work, I'm curious to know if anyone knows of 
any tools already out there for that.

Any suggestions?  I'd be rather curious to hear about something that 
operates on the op-code level and can possibly cope with renamed 
variables as a result.
[snip]

I don't know of anything Perl specific, certainly not at the opcode 
level.

I've had some success throwing everything through perltidy to normalise 
the code then applying comparator 
. This is all purely textual but 
works surprisingly well, and has the bonus of involving almost no 
actual work :-)

You may want to take a look at CPD 
, which does duplicate code 
detection for Java, C, C++, and PHP. Details on the algorithm at 
.

Cheers,

Adrian

Re: A12: default accessors and encapsulation

[Luke Palmer]

John Siracusa writes:
> On 4/19/04 3:58 PM, Austin Hastings wrote:
> >> I initially decide to accept the default accessors.
> >> 
> >> $dog.name = 'Ralph';
> >> print $dog.age;
> >> 
> >> This works well for a while, but then I decide to update Dog so that setting
> >> the name also sets the gender.
> >> 
> >> $dog.name = 'Susie'; # also sets $dog.gender to 'female'
> >> 
> >> How do I write such a name() method?
> >
> > has $.name is rw
> > will STORE { .set_name($^name); };
> 
> The "will STORE" stuff covers the easy cases, but can I extend it all the
> way up to a name() that's a multimethod with a ton of optional args?  I
> supposed you can (technically) do all of that with "will STORE", but it
> seems an odd place for what would more naturally be code in the name()
> method itself.

I think a role on the attribute is not the right place to put it.  What
you're doing is returning a proxy object that knows how to set both the
name and the gender.  Here are a couple of implementations:

class Dog {
has $.name;
has $.gender;

method name() {
return my $dummy 
is Proxy( 
for => $.name,
STORE => sub ($in) {
$.gender = // ?? 'male' :: 'female';
$.name = $in;
},
);
}
}

Yuck.  Much nicer:

class Dog {
has $.name;
has $.gender;

method name()
will get { $.name }
will set -> $in { 
$.gender = // ?? 'make' :: 'female';
$.name = $in;
}
{ }
}

This is nothing new.  So, for fun, here's the implementation of C
and C:

role get {
multi sub trait_auxiliary:is(get $trait, &code: ?$arg) {
wrap &code: {
my $result := call;
return my $dummy
is Proxy(
for => $result,
FETCH => $arg,
);
};
}
}

role set {
multi sub trait_auxiliary:is(set $trair, &code: ?$arg) {
wrap &code: {
my $result := call;
return my $dummy
is Proxy(
for => $result,
STORE => $arg,
);
};
}
}

Luke

Re: A12: default accessors and encapsulation

[Damian Conway]

John Siracusa wrote:

> I'd either like a way to more cleanly extend the default accessor's
> assignment behavior down the road (i.e. by just writing a new name() method,
> not by hacking away at STORE traits and adding private worker subs) or a way
> to auto-generate the slightly more "boring" default accessor shown above.
There *is* a way to do the latter. In A12, Larry implies that the declarators 
in the body of a class definition are actually method calls on an instance of 
MetaClass:

http://www.perl.com/pub/a/2004/04/16/a12.html?page=3#use_of_classes
http://www.perl.com/pub/a/2004/04/16/a12.html?page=19#new_grammatical_categories
So, presumably, by defining a new C, you would be able 
to override the default accessor-generating behaviour.

The least scary way to do this would be to encapsulate it in a trait that is 
applied to (and has its way with ;- the class declaration:

class Dog is getset {
has $.name is rw;
...
}
or perhaps is applied instead to individual attribute declarations:

class Dog {
has $.name is getset;
...
}
Alternatively, you could just *cheat* and define a macro (putting it in a
lexically-scoped module for convenience and safety):
module GetSet;

macro getset is export(:MANDATORY)
 is parsed(rx:words/ ? /)
 ($attr)
{
my $accessor = substr $attr{attr_var}, 2;
return "method set_$accessor ($attr{type} $attr{$attr_var}) {} "
 ~ "method get_$accessor () { return $attr{attr_var} } "
 ~ "has $attr{type} $attr{attr_var}"
 ;
}
and then:

class Dog {
use GetSet;
getset $.name;
...
}
Damian

Re: backticks (or slash, maybe)

[Damian Conway]

Sean O'Rourke wrote:

> I'm saying "division" is now defined such that when the numerator is
> a hash(-ref), the result is the set of values associated with the
> denominator.  I've never tried to divide a hash or hashref by
> something without it being a bug.
Right...in Perl 5.

In Perl 6, a hash in a numeric context returns the number of entries it 
contains. So I can readily imagine:

sub decimate_hash (%hash is rw) {
for 1..%hash/10 {
delete %hash{ pick any(keys %hash) };
}
}
Damian

Re: A12: Required Named Parameters Strike Back!

[Larry Wall]

On Mon, Apr 19, 2004 at 01:44:53PM -0400, John Siracusa wrote:
: On 4/19/04 1:30 PM, Larry Wall wrote:
: > On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
: > : I know we are running out of special characters, but I really, really think
: > : that required named parameters are a natural fit for many common APIs.  A12
: > : has reinforced that belief.  Save me, Dami-Wan Wallnobi, you're my only
: > : hope...
: > 
: > Well, actually, we saved you last summer when we decided to make +
: > mean that the parameter must be named.
: 
: ...named and required, or named and optional?  IOW, is this all true?
: 
: sub foo(+$a, +$b) { ... }
: 
: foo();  # compile-time error!
: foo(1, 2);  # compile-time error!
: foo(a => 1, 2); # compile-time error!
: foo(a => 1);# compile-time error!
: 
: foo(a => 5, b => 7); # ok
: foo(b => 1, a => 2); # ok

Well, no, we're still stuck at run-time validation of that.  In the case
of methods you can't really do anything else anyway, generally speaking.
For subs, we could make the compiler pay attention to something in the
declaration:

sub foo(+$a is req, +$b is req) { ... }
sub foo(+$a = fail, +$b = fail) { ... }

But I still don't think it rates a strange character of its own.

Possibly there's something going on with multi subs and invocants.
I'm not sure what 6.0.0 will make of a declaration like:

multi sub foo(+$a, +$b: +$c) { ... }

since we've told the Parrot people they don't have to worry about
anything but positional parameters for 6.0.0.

But none of this has much bearing on BUILD routines, which are shielded
from positional semantics anyway by the fact that .bless() doesn't
take any extra positional parameters.

Larry

Re: A12: Required Named Parameters Strike Back!

[Damian Conway]

John Siracusa asked:

Well, actually, we saved you last summer when we decided to make +
mean that the parameter must be named.
...named and required, or named and optional?
Named and optional, by default.

 IOW, is this all true?

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

foo();  # compile-time error!
No.

foo(1, 2);  # compile-time error!
Yes.

foo(a => 1, 2); # compile-time error!
Yes.

foo(a => 1);# compile-time error!
No.


foo(a => 5, b => 7); # ok
foo(b => 1, a => 2); # ok
Yes. Yes.

You want:

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

Damian

Re: A12: default accessors and encapsulation

[Larry Wall]

On Mon, Apr 19, 2004 at 06:53:29PM -0400, John Siracusa wrote:
: Yeah, that's exactly what I don't want to type over and over :)

I really don't understand what you're getting at here.  First you
complain that you'd rather write an ordinary method, and then you
complain that you have to.  Have I met someone lazier than me?  :-)

Larry

A12 - Protected Attributes and Methods

[Joe Gottman]

   Apocalypse 12 was very clear about the difference between private and
public class members, but it didn't say anything about protected ones?  How
can you define a protected member?   Do you have to do the following?
has $.foo is protected;
method bar() is protected;

   Maybe we could have another secondary sigil to mark a protected method or
attribute.  I'd suggest the semicolon, but I'm afraid it would cause havoc
with the parser.

Joe Gottman

[perl #28981] [PATCH src/exec_start.c] Fix Compilation Error

[via RT]

# New Ticket Created by  chromatic 
# Please include the string:  [perl #28981]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28981 >


I played with making executables today (to no avail; it's having trouble
with load_bytecode ops, but that's a different issue).  Here's a patch
to src/exec_start.c to make it compile.

I think it's a bit naive, but it's no worse than some of the other
examples of string_make() in the code.

-- c


Index: src/exec_start.c
===
RCS file: /cvs/public/parrot/src/exec_start.c,v
retrieving revision 1.10
diff -u -u -r1.10 exec_start.c
--- src/exec_start.c	3 Mar 2004 10:13:00 -	1.10
+++ src/exec_start.c	20 Apr 2004 03:33:31 -
@@ -68,7 +68,7 @@
 for (i = 0; i < argc; i++) {
 /* Run through argv, adding everything to @ARGS. */
 STRING *arg = string_make(interpreter, argv[i], strlen(argv[i]),
-  0, PObj_external_FLAG, 0);
+  "iso-8859-1", PObj_external_FLAG);
 
 if (Interp_flags_TEST(interpreter, PARROT_DEBUG_FLAG)) {
 PIO_eprintf(interpreter, "\t%vd: %s\n", i, argv[i]);

SDL Parrot Status

[chromatic]

Since Piers needs fodder to summarize regularly

I've created a small webpage with the current status and downloadable
snapshots for SDL Parrot:

http://wgz.org/chromatic/parrot/sdl/

You'll probably see a link to my PDX.pm talk from earlier this month. 
It's not ground-breakingly new, but it does show off a few things that
aren't necessarily obvious:

http://wgz.org/chromatic/talks/parrot_sdl/

I do plan to check in the new bindings shortly, just as soon as Dan
gives the yay to Leo's "implicitly passing a PMC to the initializer"
scheme -- or checks in an alternate scheme.

Enjoy,
-- c

Re: ICU Win32 Issues

[George R]

Your concerns are valid for versions of ICU before 3.0.  ICU 3.0 will 
allow you to build with Cygwin with gcc or MSVC's cl compiler.

The toolutil library is located in icu/source/tools/toolutil.  If you 
used the --disabled-shared configure option as Parrot's README states 
(not ICU's readme), you won't be able to build ICU on several 
platforms.  Cygwin is one of them.  ICU still requires that you build 
the shared libraries, even if you only want the static libraries.  Don't 
use --disabled-shared.

Marcus Thiesen wrote:

Hi,

most of you might have recognized it by now but M$ released it's compiler to 
the public yesterday (I know it has been there before, but everybody sells it 
as real news). As I'm currently at my fathers place I had the time and 
resources to do some cygwin and native win32 testing.

I can't get it to work under Cygwin since the ICU changes because it tries to 
do some linking stuff that fails, I believe the important parts are:
/usr/bin/ar: creating libicuctestfw.a
/usr/bin/ar: creating libicutoolutil.a
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: 
cannot find -licutoolutil26
collect2: ld returned 1 exit status
make[2]: *** [makeconv.exe] Error 1
make[1]: *** [all-recursive] Error 2
make: *** [blib/lib/libicuuc.a] Error 2

As I couldn't find any icutoolutil26* file and didn't find a cygwin version I 
stopped for today. 

Next I tried native Win32, where I got another ICU issue (do we *really* need 
unicode? :-). It seems as if ICU needs not only a (n)make and a compiler, but 
depends on msdev.exe, which seems to be the executable for the M$ Devel 
Studio which can also be used on the command line. It alway complains about 
the missing file, and as I didn't have an MS Dev studio, I stopped for today.

So, after a hard days work, no real success :-(

Have fun,
Marcus