[svn:perl6-synopsis] r12342 - doc/trunk/design/syn
Author: larry Date: Fri Sep 22 23:45:40 2006 New Revision: 12342 Modified: doc/trunk/design/syn/S06.pod Log: Last ci had typo and was unclear about whether it applied only to identifiers. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Sep 22 23:45:40 2006 @@ -1763,7 +1763,8 @@ default to named unary precedence despite declaring a prefix operator. Likewise postfix operators that look like method calls are forced to default to the precedence of method calls. Any prefix operator that -requires multiple arguments default to listop precedence. +requires multiple arguments defaults to listop precedence, even if it +is not an identifier. =item C
[svn:perl6-synopsis] r12340 - doc/trunk/design/syn
Author: larry Date: Fri Sep 22 23:40:54 2006 New Revision: 12340 Modified: doc/trunk/design/syn/S06.pod Log: clarified that prefix: ops with multiple args default to listop precedence Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Sep 22 23:40:54 2006 @@ -13,9 +13,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 21 Mar 2003 - Last Modified: 20 Sept 2006 + Last Modified: 22 Sept 2006 Number: 6 - Version: 56 + Version: 57 This document summarizes Apocalypse 6, which covers subroutines and the @@ -1762,7 +1762,8 @@ default to named unary precedence despite declaring a prefix operator. Likewise postfix operators that look like method calls are forced to -default to the precedence of method calls. +default to the precedence of method calls. Any prefix operator that +requires multiple arguments default to listop precedence. =item C
[svn:perl6-synopsis] r12339 - doc/trunk/design/syn
Author: larry
Date: Fri Sep 22 23:27:00 2006
New Revision: 12339
Modified:
doc/trunk/design/syn/S02.pod
Log:
lingering postfix-to-prefix fallback
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podFri Sep 22 23:27:00 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 20 Sept 2006
+ Last Modified: 22 Sept 2006
Number: 2
- Version: 70
+ Version: 71
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -2300,7 +2300,7 @@
term:<...> $x = {...}
quote: qX/foo/
-prefix: !$x (and $x.! if no
postfix:)
+prefix: !$x (and $x.'!')
infix:<+> $x + $y
postfix:<++>$x++
circumfix:<[ ]> [ @x ]
Re: Capture sigil
Aaron Sherman wrote:
IMHO most of the confusion here goes away if capture variables ONLY
store parameter-list-like captures, and any other kind of capture
should, IMHO, permute itself into such a structure if you try to store
it into one. That way, their use is carefully constrained to the places
where Perl 6 can't already do the job.
My understanding is that perl6 treats references as subsets of the
capture object - something along the lines of the following (WARNING -
this is going to border on 'internals' territory):
When you bind a variable to an object, that variable becomes a synonym
of that object for all purposes. However, barring auto-capturing, the
variable's sigil must match the object's type: bind a scalar variable
to an object, and the object better know how to behave like a scalar,
else you have trouble. I understood that list-like objects generally
don't know how to behave like scalars, and vice versa.
A capture object is an object that's intended to allow for
indirection: it's a perl6opaque object with (at least) three
attributes inside, all of which are to be used exclusively for binding
purposes: in effect, it's something like:
role Capture {
has $invocant, @positional, %named, ::returnType;
}
Note that you don't need any & or | attributes in order to capture a
parameter list.
The '\' prefix operator constructs a Capture object and binds the
various parts of its parameter list to the appropriate attributes.
The '$' prefix operator returns the Capture object's $invocant
attribute; the '@' prefix operator returns the Capture object's
@positional attribute; the Capture object's '%' prefix operator
returns the Capture object's %named attribute; and the Capture
object's '::' prefix operator returns the Capture object's
::returnType attribute.
Such a Capture object would be unable to capture codeblocks or other
Capture objects without extending its capabilities. That is, '\&code'
wouldn't have an attribute to bind to &code. There _might_ be a way
around this without introducing a new attribute, but only if code
objects know how to behave like scalars.
I may be off in terms of some of the details; but am I on the right
course in general?
--
Jonathan "Dataweaver" Lang
Re: [perl #40402] Remove src/ops/dotgnu.ops
Bernhard Schmalhofer (via RT) wrote: http://svn.perl.org/viewcvs/parrot/trunk/src/ops/dotgnu.ops was meant for conversion ops for a C#-Implementation. It looks obsolete to me, especially as there now is languages/dotnet. Does anybody mind, if I remove it? I think remove it. I don't know how far along the C# compiler got, but my guess is not as far as languages/dotnet/ is now. I certainly know I needed to write a lot more custom ops than were in dotgnu.ops. Jonathan
Re: [perl #40402] Remove src/ops/dotgnu.ops
Am Freitag, 22. September 2006 19:22 schrieb Bernhard Schmalhofer: > Hi, > > http://svn.perl.org/viewcvs/parrot/trunk/src/ops/dotgnu.ops was meant for > conversion ops for a C#-Implementation. > > It looks obsolete to me, especially as there now is languages/dotnet. Yep. > Does anybody mind, if I remove it? See also *all* the answers re: http://www.mail-archive.com/perl6-internals%40perl.org/msg33059.html Well, the [o]ops are really in src/ops/dotgnu.ops :-) > Regards, > Bernhard leo
[perl #40393] [PATCH] C coda fix in parrot/src
From: "Paul Cochrane" (via RT) <[EMAIL PROTECTED]> Date: Thu, 21 Sep 2006 17:22:47 -0700 Hi, . . . I have a question about one file though: parrot/src/malloc-trace.c has the following part in the coda that it currently has: * compile-command: *"gcc -Wall -O -fpic -shared -o malloc-trace.so malloc-trace.c" Is this necessary? And could it just be deleted entirely? Thanks and Regards, Paul This just changes the default shell command for the M-x compile Emacs command. This particular gcc command doesn't work to compile it, but that may or may not be the fault of the command. Has anybody tried to build Parrot with "perl Configure.pl --gc=malloc-trace" lately? Does it compile OK? And if so, is the generated Makefile command any different? Assuming malloc-trace.c isn't terminally bitrotted, the default default for compile-command is "make -k ", which is usually the right thing anyway, so I don't think deleting it would hurt. -- Bob Rogers http://rgrjr.dyndns.org/
[perl #40402] Remove src/ops/dotgnu.ops
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #40402] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40402 > Hi, http://svn.perl.org/viewcvs/parrot/trunk/src/ops/dotgnu.ops was meant for conversion ops for a C#-Implementation. It looks obsolete to me, especially as there now is languages/dotnet. Does anybody mind, if I remove it? Regards, Bernhard
[perl #40393] [PATCH] C coda fix in parrot/src
thanks, applied as r14688. ~jerry
Re: [perl #40394] [PATCH] Added a test for multiple codas to t/codingstd/code_coda.t
On 9/21/06, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote: This patch gets code_coda.t to test for multiply-defined codas (for those cases when a file append or automated tool adds a coda unnecessarily). I have a feeling it's not pretty code, but my perl foo is only slowly improving. great idea for the second test. i modified this patch a bit before applying as r14686. specifically, i ~ modified plan to correct number of tests ~ renamed existing array @comments to @no_coda to better reflect use ~ simplified search for multiple codas i think you might learn a neat trick for extracting a count of matches (without using grep) from a regex if you look at the diff. thanks, and more patches welcome! :) ~jerry
Re: Trying to make a new operator
On 9/22/06, Richard Hainsworth <[EMAIL PROTECTED]> wrote:
Biggest problems are the following:
a) finding the symbols - I had to use two editors, and getting them to
show them on screen
Good place to see all of the symbols in Unicode is
http://unicode.org/charts/symbols.html (a lot of PDF-files there)
You could also try to find the proper symbol from
http://www.iam.uni-bonn.de/~alt/html/unicode_3.html
and then copy-pasting it to your editor.
This seemed to work for me with Firefox+KWrite after I changed the
encoding to UTF-8 (but my font didn't show all the symbols).
b) mixing types. My version of pugs does not respect the white space at
the start and end of strings. Also if the functions are given as <>, all the white space is excluded. Not sure if this is a
feature or a non-feature.
< text more text > creates a list, not a string, and is meant to
ignore the extra spaces because spaces are only used to delimit the
list-items.
(I'm not sure about <<...>>)
If you want to create strings, just use the quotes like here:
sub infix:<☥> {...};
sub infix:<☆> {...};
sub infix:<☺> {...};
(3 ☥ 40 ☆ 7 ☺ 50).say;
sub infix:<☥> ($l,$r) {
return "The $l wise men spent $r days";
};
sub infix:<☆> ($l,$r) {
return "$l following a star in the $r-th heaven";
};
sub infix:<☺> ($l,$r) {
return "$l to become very happy for $r days and nights"
};
--
Markus Laire
Re: Motivation for /+/ set Array not Match?
2006/9/22, Patrick R. Michaud <[EMAIL PROTECTED]>: Out of curiosity, why not: / bar bar $:=(+)/ and then one can easily look at $.from and $.to, as well as get to the arrayed elements? (There are other possibilities as well.) I'm not arguing in favor of or against the proposal, just pointing out that there are ways in the existing scheme to get at what is wanted. This aliasing would still work: / bar bar $:=(+)/ $[0] - match $[] - array of match $[0] - match ~$ - stringified capture I've been using aliasing a few times, and mostly exactly in this situation, so I thought it would be nice to have a way to express this idea with fewer words: / bar bar +/ $[0] - match $[1;*] - array of match $[1;0] - match ~$[1] - stringified capture OTOH, you lose ' @all_foo = $ ', but maybe ' @all_foo = $[] ' could be overloaded to the old behaviour. Anyway, it's just a thought. thanks! - Flavio S. Glock
Re: Trying to make a new operator
Steffen Schwigon wrote:
Thanks for reporting the solution back.
And it even works with unicode operators. Looks like we finally
really get our "ankh, pentagram, and that smiley teddy bear from
that Grateful Dead album". (*) :-) Thanks to Unicode, thanks to Pugs
So hopefully in the same spirit :
sub infix:<☥> {...};
sub infix:<☆> {...};
sub infix:<☺> {...};
(3 ☥ 40 ☆ 7 ☺ 50).say;
sub infix:<☥> ($l,$r) {
~ $l ~ < wise men spent > ~ $r ~ < days >
};
sub infix:<☆> ($l,$r) {
$l ~ < following a star in the > ~ $r ~ <-th heaven >
};
sub infix:<☺> ($l,$r) {
$l ~ < to become very happy for > ~ $r ~ < days and nights>
};
Biggest problems are the following:
a) finding the symbols - I had to use two editors, and getting them to
show them on screen
b) mixing types. My version of pugs does not respect the white space at
the start and end of strings. Also if the functions are given as <$l more text>>, all the white space is excluded. Not sure if this is a
feature or a non-feature.
Richard
Re: Motivation for /+/ set Array not Match?
On Fri, Sep 22, 2006 at 10:22:52PM +0800, Audrey Tang wrote: > Moreover: > >/ bar bar +/ > > should set $ to an Array with two Match elements, the first being a > simple match, and the second has multiple positional submatches. > > The thinking behind the separate treatment is that in a contiguous > quantified > match, it does make sense to ask the .from and .to for the entire > range, which > is very hard to do if it's an Array (which can have 0 elements, > rendering $[-1].to > dangerous). Out of curiosity, why not: / bar bar $:=(+)/ and then one can easily look at $.from and $.to, as well as get to the arrayed elements? (There are other possibilities as well.) I'm not arguing in favor of or against the proposal, just pointing out that there are ways in the existing scheme to get at what is wanted. Pm
Motivation for /+/ set Array not Match?
From S05: If a subrule appears two (or more) times in any branch of a lexical scope (i.e. twice within the same subpattern and alternation), or if the subrule is quantified anywhere within a given scope, then its corresponding hash entry is always assigned an array of C objects rather than a single C object. However, fglock and I both find the "quantified" clause very surprising. Intuitively: / bar bar / should set $ to an Array with two Match elements. However: /+/ should set $ to a single Match, with multiple positional Match elements, each one representing one match in the quantified match. Moreover: / bar bar +/ should set $ to an Array with two Match elements, the first being a simple match, and the second has multiple positional submatches. The thinking behind the separate treatment is that in a contiguous quantified match, it does make sense to ask the .from and .to for the entire range, which is very hard to do if it's an Array (which can have 0 elements, rendering $[-1].to dangerous). Also stringification for $ on a /+/ match should perhaps not be space-separated, i.e. it should follow Match semantics not Array semantics. To recap: Is it possible to amend the quantified clause to have it produce Match objects, and reserve Array only for noncontiguous same-named subrules? Thanks, Audrey
Re: Capture sigil
Jonathan Lang wrote:
Larry Wall wrote:
You don't need to use | to store a capture any more than you need @ to
store an array. Just as
$x = @b;
@$x;
gives you the original array,
Huh. I'm not used to this happening. So what would the following
code do, and why?
my @b = ('foo', 'bar');
my $x = @b;
say $x;
@b gets a list shoved into it
$x gets the array @b shoved into it
The array @b gets printed.
Arrays in a scalar context in Perl6 auto-capture themselves and the
scalar becomes a reference to the array (or hash, or even capture, for
that matter).
At a higher level, think of it this way: all data types are objects.
Assigning an array into a scalar is just a change in notation.
likewise
$x = [EMAIL PROTECTED];
@$a;
gives you the original array as well.
Err... don't you mean '@$x' instead of '@$a'?
Yes, he does.
: >we currently don't allow assignment to a capture, only binding.
:
: IOW, if you want someone to be able to say '$|x' and get '$a' as a
: result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead
: of '|x = \$a'. Right?
Yes. That's how it's currently specced, anyway. (The \ is probably
required, or it'll try to bind to the contents of $a instead.)
???
IMHO most of the confusion here goes away if capture variables ONLY
store parameter-list-like captures, and any other kind of capture
should, IMHO, permute itself into such a structure if you try to store
it into one. That way, their use is carefully constrained to the places
where Perl 6 can't already do the job.
[perl #40394] [PATCH] Added a test for multiple codas to t/codingstd/code_coda.t
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40394]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40394 >
Hi,
This patch gets code_coda.t to test for multiply-defined codas (for
those cases when a file append or automated tool adds a coda
unnecessarily). I have a feeling it's not pretty code, but my perl
foo is only slowly improving.
Regards,
Paul
Files affected by this patch:
parrot/t/codingstd/code_coda.t
Index: t/codingstd/code_coda.t
===
--- t/codingstd/code_coda.t (revision 14683)
+++ t/codingstd/code_coda.t (working copy)
@@ -46,6 +46,7 @@
my $DIST = Parrot::Distribution->new;
my @files = @ARGV ? @ARGV : source_files();
my @comments;
+my @coda_extras;
foreach my $file ( @files ) {
my $buf;
@@ -72,11 +73,36 @@
# append to the comments array if the code doesn't match
push @comments => "$path\n"
unless $buf =~ m{\Q$coda\E\n*\z};
+
+# make an array of the buffer's lines to pass to grep nicely
+my @buf_lines = split m/\n/, $buf;
+
+# check to see how often 'Local variables:' occurs
+my $emacs_coda_count = grep m{
+ \* \s* Local \s* variables: \s*
+ }gxms, @buf_lines;
+
+# check to see how often 'vim:' occurs
+my $vim_coda_count = grep m{
+\* \s* vim: \s*
+}gxms, @buf_lines;
+
+# if either the emacs or vim coda is found more than once, record the
+# file name
+print "emacs coda count: ", $emacs_coda_count, "\n";
+if (($emacs_coda_count > 1) ||
+($vim_coda_count > 1)) {
+push @coda_extras => "$path\n";
+}
}
+# check that the coda exists
ok(!scalar(@comments), 'C code coda')
or diag("C code coda missing in ".scalar @comments." files:[EMAIL PROTECTED]");
+# check for extra emacs/vim codas
+ok(!scalar(@coda_extras), 'C code coda')
+or diag("C code coda repeating in ".scalar @coda_extras." files:[EMAIL PROTECTED]");
exit;
@@ -94,4 +120,9 @@
);
}
-## vim: expandtab sw=4
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
[perl #40393] [PATCH] C coda fix in parrot/src
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40393] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40393 > Hi, This is a patch to hopefully finish off the emacs/vim C coda additions, and adds/modifies the coda in the C-language files under parrot/src; it applies to bug #40279 [CAGE] C coding standards coda, (and I guess closes it: still a n00b). I have a question about one file though: parrot/src/malloc-trace.c has the following part in the coda that it currently has: * compile-command: *"gcc -Wall -O -fpic -shared -o malloc-trace.so malloc-trace.c" Is this necessary? And could it just be deleted entirely? Thanks and Regards, Paul Files affected by this patch: src/trace.c src/smallobject.c src/byteorder.c src/utils.c src/exec_save.c src/malloc-trace.c src/trace.h src/pdb.c src/exec_save.h src/tsq.c src/parrot.c src/exit.c src/resources.c src/embed.c src/hll.c src/pbc_info.c src/pic_jit.c src/runops_cores.c src/stm/waitlist.c src/stm/stm_internal.h src/stm/backend.c src/stm/stm_waitlist.h src/pbc_merge.c src/hash.c src/register.c src/debug.c src/encoding.c src/runops_cores.h src/charset.c src/gc_gms.c src/global.c src/gc_ims.c src/exec_start.c src/events.c src/dod.c src/packout.c src/memory.c src/nci_test.c src/pic.c src/list.c src/inter_call.c src/cpu_dep.c src/pmc.c src/exec.c src/intlist.c src/key.c src/inter_run.c src/builtin.c src/string.c src/malloc.c src/charset/tables.h src/charset/iso-8859-1.c src/charset/binary.c src/charset/unicode.c src/charset/iso-8859-1.h src/charset/ascii.c src/charset/binary.h src/charset/tables.c src/charset/unicode.h src/charset/ascii.h src/interp_guts.h src/res_lea.c src/headers.c src/stack_common.c src/global_setup.c src/bignum.c src/string_primitives.c src/longopt.c src/pdump.c src/inter_cb.c src/bignum.h src/warnings.c src/encodings/ucs2.h src/encodings/utf16.c src/encodings/fixed_8.c src/encodings/utf8.c src/encodings/utf16.h src/encodings/utf8.h src/encodings/fixed_8.h src/encodings/ucs2.c src/objects.c src/disassemble.c src/unicode.h src/inter_misc.c src/packfile/pf_items.c src/datatypes.c src/vtables.c src/interpreter.c src/inter_create.c src/packdump.c src/library.c src/jit/arm/exec_dep.h src/jit/arm/jit_emit.h src/jit/ppc/exec_dep.h src/jit/ppc/jit_emit.h src/jit/ia64/jit_emit.h src/jit/skeleton/jit_emit.h src/jit/alpha/jit_emit.h src/jit/hppa/jit_emit.h src/jit/mips/jit_emit.h src/jit/sun4/jit_emit.h src/jit/i386/exec_dep.h src/jit/i386/jit_emit.h src/thread.c src/dynext.c src/mmd.c src/packfile.c src/pmc_freeze.c src/exceptions.c src/jit_debug_xcoff.c src/spf_vtable.c src/io/io_mmap.c src/io/io_buf.c src/io/io_passdown.c src/io/io_layers.c src/io/io_private.h src/io/io.c src/io/io_stdio.c src/io/io_win32.c src/io/io_unix.c src/io/io_utf8.c src/io/io_string.c src/jit.c src/spf_render.c src/extend.c src/stacks.c src/sub.c src/misc.c src/jit.h src/jit_debug.c Index: src/trace.c === --- src/trace.c (revision 14669) +++ src/trace.c (working copy) @@ -455,12 +455,10 @@ */ + /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: -*/ + */ Index: src/smallobject.c === --- src/smallobject.c (revision 14669) +++ src/smallobject.c (working copy) @@ -583,12 +583,10 @@ */ + /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: -*/ + */ Index: src/byteorder.c === --- src/byteorder.c (revision 14669) +++ src/byteorder.c (working copy) @@ -351,10 +351,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: -*/ + */ Index: src/utils.c === --- src/utils.c (revision 14669) +++ src/utils.c (working copy) @@ -904,12 +904,10 @@ */ + /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: src/exec_save.c === --- src/exec_save.c (revision 14669) +++ src/exec_save.c (working copy) @@ -803,12 +803,10 @@ */ + /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: src/malloc-trace.c === --- src/malloc-trace.c (revision 14669) +++ src/malloc-trace.
Re: [DONE] shootout example testing
Am Donnerstag, 21. September 2006 22:40 schrieb Karl Forner: > Hello, > > I've worked on the bug #40064, that was to test the shootout PIR programs > in examples/shootout.pir Great. Thanks, applied as r14684. > - pidigits.pir do not work for the required value N=27. I suppose that's > because, as I read in the comments, I don't have libGMP installed or > something like this. > How could I detect this in order not to skip it for the happy > gmp-compliants guys ? I've added skip handling based on filename and a config var. leo
Re: Capture sigil
Larry Wall wrote:
You don't need to use | to store a capture any more than you need @ to
store an array. Just as
$x = @b;
@$x;
gives you the original array,
Huh. I'm not used to this happening. So what would the following
code do, and why?
my @b = ('foo', 'bar');
my $x = @b;
say $x;
likewise
$x = [EMAIL PROTECTED];
@$a;
gives you the original array as well.
Err... don't you mean '@$x' instead of '@$a'?
: >we currently don't allow assignment to a capture, only binding.
:
: IOW, if you want someone to be able to say '$|x' and get '$a' as a
: result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead
: of '|x = \$a'. Right?
Yes. That's how it's currently specced, anyway. (The \ is probably
required, or it'll try to bind to the contents of $a instead.)
???
There's some potential non-dwimmery here - either that, or there's a
steep learning curve (that I haven't mastered) before dwimmery can be
applied[1]. I would expect $|x to refer to the scalar slot of the
capture object |x; as such, '$|x := ...' would mean 'bind the scalar
slot of |x to ...'. Likewise, I would expect '... := $a' to mean
'bind ... to the scalar variable $a'.
Or is the distinction between '$a' and 'the contents of $a' similar to
the distinction between a Unix filename and a Unix file ID? That is,
are we talking about the difference between hard links and symbolic
links in Unix?
--
Jonathan "Dataweaver" Lang
[1] I'm not sure that there's much of a difference between the two statements.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Randal L. Schwartz wrote: ""A" == "A Pagaltzis" <[EMAIL PROTECTED]> writes: "A> * Randal L. Schwartz [2006-09-20 19:30]: "Fagyal" == Fagyal Csongor <[EMAIL PROTECTED]> writes: yet I never needed those HTML generating methods. You've never made a sticky form then. "A> False dilemma. You can create sticky forms conveniently without "A> using CGI.pm’s HTML generation stuff. You can use HTML::Template, "A> HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on? "A> C’mon merlyn, you’ve been around long enough to know about CPAN "A> and realise that your statement is transparently fallacious. However, HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not* in core. CGI.pm was. One stop shopping. Easy to describe to people. We need the same thing for Perl6: "If you're going to do simple web stuff, please use MUMBLE module". And MUMBLE better have tight integration of param processing and sticky form generation, as well as good header generation for cookies and redirects. In other words, at least two thirds of what CGI.pm does for me now. And MUMBLE better be included *with* Perl6. Without that, people will *hand code* that stuff, and get it wrong, and we'll get the reputation of Perl6 being horrible for the web. I am in favour of different bundles. Then you can, for example yum install perl6-base or yum install perl6-web or yum install perl6-everything You know what I mean. The diff between perl6-base and perl6-web is a bunch of (CPAN6) modules. - Fagzal
Re: Capture Literals
Larry Wall wrote:
: This would mean that the rules for capturing are as follows:
:
: * Capturing something in scalar context: If it is a pair, it is
: captured as a named argument; otherwise, it is captured as the
: invocant.
:
: * Capturing something in list context: Pairs are captured as named
: arguments; the first non-pair is captured as the invocant if it is
: followed by a colon, but as a positional argument otherwise; all other
: non-pairs are captured as positional arguments.
Capture literals ignore their context like [...] does.
What got me thinking about this was that I couldn't find decent
documentation about Capture literals in the synopses.
: So:
:
: $x = \$a; # $$x eqv $a
: $x = \:foo;# %$x eqv { foo => 1 }
: $x = \($a,); # @$x eqv ( $a ); is the comma neccessary, or are the
: () enough?
I think the () is probably enough.
Problem: S02 explicitly states that '\3' is the same as '\(3)'. So:
both of them put 3 into the scalar slot of the capture object, or both
of them put the single-item list '(3)' into the array slot of the
capture object. Whichever way they go, how would you do the other?
: $x = \($a:); # $$x eqv $a
: $x = \(:foo); # %$x eqv { foo => 1 }; assuming that adverbs can go
: inside ().
: $x = \($a, $b) # @$x eqv ($a, $b)
: $x = \($a: $b) # $$x eqv $a; @$x eqv ($b)
: $x = \:foo ($a: $b, $c):bar <== $d, $e <== flag => 0; # results
: on next three lines:
:# $$x eqv $a
:# @$x eqv ($b, $c, $d, $e)
:# %$x eqv { foo => 1, bar => 'baz', flag => 0 }
Ignoring the syntax error, yes.
Please don't ignore the syntax error; I'm not seeing it.
: Note that this approach makes it impossible for a pair to end up
: anywhere other than as a named argument in the capture object; while
: this makes sense when the capture object is being used as a proxy
: argument list, it makes less sense when it is being used as the
: equivalent of perl 5's references, and thus is probably a bug.
If you say "flag" => 0 it comes in as a pair rather than a named arg.
I was under the impression that the left side of '=>' still gets
auto-quoted in perl 6.
Anyway, you're saying that if I capture a pair, it will be stored in
the array portion of the capture object (the 'positional args'); if I
capture an adverb, it will be stored in the hash portion of the
capture object (the 'named args'). Right?
--
Jonathan "Dataweaver" Lang
Re: Capture sigil
On Fri, Sep 22, 2006 at 12:32:27AM -0700, Jonathan Lang wrote: : Larry Wall wrote: : >Jonathan Lang wrote: : >: Two questions: : >: : >: 1. How would the capture sigil affect the use of capture objects as : >: replacements for perl5's references? : > : >I don't see how it would have any effect at all, unless the P5 ref happened : >to be to a typeglob, or had both array and hash semantics tied to it. : >The regular $$x, @$x, and %$x look much like they do in P5. : : But $x is a scalar; wouldn't you need to use '|x' to denote a capture : object, thus making the above '$|x', '@|x', and '%|x', respectively? You don't need to use | to store a capture any more than you need @ to store an array. Just as $x = @b; @$x; gives you the original array, likewise $x = [EMAIL PROTECTED]; @$a; gives you the original array as well. : >we currently don't allow assignment to a capture, only binding. : : IOW, if you want someone to be able to say '$|x' and get '$a' as a : result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead : of '|x = \$a'. Right? Yes. That's how it's currently specced, anyway. (The \ is probably required, or it'll try to bind to the contents of $a instead.) Larry
Re: Capture sigil
Larry Wall wrote: Jonathan Lang wrote: : Two questions: : : 1. How would the capture sigil affect the use of capture objects as : replacements for perl5's references? I don't see how it would have any effect at all, unless the P5 ref happened to be to a typeglob, or had both array and hash semantics tied to it. The regular $$x, @$x, and %$x look much like they do in P5. But $x is a scalar; wouldn't you need to use '|x' to denote a capture object, thus making the above '$|x', '@|x', and '%|x', respectively? we currently don't allow assignment to a capture, only binding. IOW, if you want someone to be able to say '$|x' and get '$a' as a result, you'd have to say '|x := \$a' (or perhaps '$|x := $a') instead of '|x = \$a'. Right? -- Jonathan "Dataweaver" Lang
