Re: renaming grep to where
Jonathan Lang skribis 2006-09-19 16:39 (-0700):
Anyway, it's not clear to me that grep always has an exact opposite.
I don't see why it ever wouldn't: you test each item in the list, and
the item either passes or fails. 'select' would filter out the items
that fail the test, while 'reject' would filter out the ones that pass
it.
There's a neat trick for this: .grep:{ not ... }
HTH :)
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
[svn:perl6-synopsis] r12239 - doc/trunk/design/syn
Author: audreyt
Date: Wed Sep 20 02:41:02 2006
New Revision: 12239
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: As code.call() is specified to take one single
Capture argument, fix the example in which the
argument was erroneously flattened.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Sep 20 02:41:02 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 21 Mar 2003
- Last Modified: 13 Sept 2006
+ Last Modified: 20 Sept 2006
Number: 6
- Version: 54
+ Version: 55
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -2124,7 +2124,7 @@
CCode object by passing the CCapture to its Ccall method:
# Transparently redirect all calls to thermo to other_thermo
-thermo.wrap( - \$args { other_thermo.call([,] =$args) } );
+thermo.wrap( - \$args { other_thermo.call($args) } );
Outside a wrapper, Ccall implicitly calls the next-most-likely method
or multi-sub; see S12 for details.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
It sounds like the name of HTTP is more appropriate: HTTP::Request ...uri, pathinfo, params, method, headers, etc. HTTP::Request::Session ...adds to HTTP::Request to provide session() method HTTP::Response ...response code, content, headers, etc. HTTP::Response::JSON ...extends response.write() to encode JSON Maybe CGI.pm could adapt these to the CGI environment and ecapsulate their functionality. Maybe it's too servlety. On 9/17/06, Juerd [EMAIL PROTECTED] wrote: Mark Stosberg skribis 2006-09-16 22:04 (-0500): As far as I'm aware, no work on CGI::Session for Perl 6 has started yet. I'm happy about that, because this module must not have CGI in its name. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] -- Ian Langworth
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Ian Langworth skribis 2006-09-19 19:02 (-0700): It sounds like the name of HTTP is more appropriate: HTTP::Request ...uri, pathinfo, params, method, headers, etc. (etc) Well, yes and no. HTTP is today's web protocol standard, but may not be with us forever. I was thinking of getting these HTTP modules from LWP (and Perl6-ify them, and change some method names), and then letting Web::Blah inherit from HTTP::Blah as a first implementation. Maybe CGI.pm could adapt these to the CGI environment and ecapsulate their functionality. Maybe I think that that should absolutely not belong in a root namespace. Though yes, CGI.pm could be in a directory, like Web/CGI.pm :) Maybe it's too servlety. No, it's perfect, if we change just a few things (mostly the number of convenience methods that are just delegations, and introduce some real convenience instead.) -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Ian Langworth wrote:
It sounds like the name of HTTP is more appropriate:
HTTP::Request
...uri, pathinfo, params, method, headers, etc.
HTTP::Request::Session
...adds to HTTP::Request to provide session() method
HTTP::Response
...response code, content, headers, etc.
HTTP::Response::JSON
...extends response.write() to encode JSON
Maybe CGI.pm could adapt these to the CGI environment and ecapsulate
their functionality.
Maybe it's too servlety.
It is :)
It is probably the *proper* way, but definetely not the *efficient* way.
You rarely do real HTTP handling when you use CGI.
A general, simple CGI handling module fits into 200 lines, including
POD. Imagine like
sub parseQueryStupidAndWrong {
my $self = shift;
$ENV{'QUERY_STRING'} || return {};
my @pairs = split(//, $ENV{'QUERY_STRING'});
my %query;
foreach my $pair (@pairs) {
my ($key, $value) = split (/=/, $pair);
$key =~ tr/+/ /;
$key = whatever::url_decode($key);
$value =~ tr/+/ /;
$value = whatever::url_decode($value);
if ($query{$key}) {
$query{$key} .= , $value;
} else {
$query{$key} = $value;
}
}
return \%query;
}
You don't really need more. IMHO a CGI module
parses/preprocesses/decodes/etc. all incoming parameters (POST, GET,
COOKIES), and that's it. It might give some useful other routines (e.g.
url encoding / decoding, various ways to mix GET+POST, set content types
more easily, etc.), but other than that, it should be very lightweight
and easy to use.
- Cs.
Re: renaming grep to where
Just to point out that it's probably worth going back and rereading the
earlier iterations of this discussion, in December 2002 (subject: purge: the
opposite of grep) and November 2005 (subject: Classification syntax). That
way, those who repeat history are condemned to study it. ;-)
In summary, when we last left this discussion, Larry was inclined to retain
the name 'grep', and to add a 'classify' built-in that would allow positional
or named partitioning of a list. For example (in updated syntax):
(:@sheep, :@goats) := classify { /baaa/ ?? 'sheep' !! 'goats' } @list;
(@x, @y, @huh).pairs := classify { /she/ ?? 0 !! /he/ ?? 1 !! 2 } @list;
%people_who_use
= classify { /[EMAIL PROTECTED]/ ?? 'perl' !! /[()]/ ?? 'lisp' !!
'???' }
@people;
In other words, classify() takes a list of values, examines each in turn, and
ascribes a label value to it. The call returns a list of pairs, where each
pair key is one of the label values and each pair value is an array of all the
list values that were ascribed that label.
Personally, I don't have a problem with us keeping 'grep'. However, if we do
decide to change the name, I suspect 'keep' might be readable, short, SWIM,
and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
Damian
[svn:perl6-synopsis] r12246 - doc/trunk/design/syn
Author: audreyt
Date: Wed Sep 20 03:22:42 2006
New Revision: 12246
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: TreyHarris++ pointed out another slurpy-star legacy.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Sep 20 03:22:42 2006
@@ -15,7 +15,7 @@
Date: 21 Mar 2003
Last Modified: 20 Sept 2006
Number: 6
- Version: 55
+ Version: 56
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -2118,7 +2118,7 @@
It can then be passed to Ccall as C*$args:
# Double the return value for thermo
-thermo.wrap( - \$args { call(*$args) * 2 } );
+thermo.wrap( - \$args { call([,] =$args) * 2 } );
The wrapper is not required to call the original routine; it can call another
CCode object by passing the CCapture to its Ccall method:
[svn:perl6-synopsis] r12247 - doc/trunk/design/syn
Author: audreyt
Date: Wed Sep 20 03:27:09 2006
New Revision: 12247
Modified:
doc/trunk/design/syn/S06.pod
Log:
* Ditto.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Sep 20 03:27:09 2006
@@ -2115,7 +2115,7 @@
temp thermo.wrap( { call($^t + 273.16) } );
The entire argument list may be captured by the C\$args parameter.
-It can then be passed to Ccall as C*$args:
+It can then be passed to Ccall as C[,] =$args:
# Double the return value for thermo
thermo.wrap( - \$args { call([,] =$args) * 2 } );
call, call(), .call, and captures
From S06:
sub bar ($a,$b,$c,:$mice) { say $mice }
sub foo (\$args) { say $args.perl; bar.call($args); }
The C.call method of CCode objects accepts a single CCapture
object, and calls it without introducing a CCALLER frame.
And from S12:
In addition to Cnext METHOD, the special function Ccall dispatches
to the next candidate, possibly with a new argument list:
call; # calls with the original arguments
call(); # calls with no arguments
call(1,2,3);# calls with a different set of arguments
And back in S06:
The entire argument list may be captured by the C\$args parameter.
It can then be passed to Ccall as C[,] =$args:
# Double the return value for thermo
thermo.wrap( - \$args { call([,] =$args) * 2 } );
The inconsistency between these three things called call is vexing to
me. One is a method and takes a capture and only a capture. The second is
a special function and takes an argument list, but also has a special
arglistless form that passes on the original arguments. The third is a
function that takes only a function list, but apparently lacks a
arglistless form (otherwise, why bother with capturing an arglist in the
example?).
I believe the current spec works. I just think the inconsistency is
bad--the three things called call do very similar things, but take
completely different arguments. I suspect this is just historical smear
and we just need to back up and normalize.
(Let me quickly note here that I don't think it's possible to write a
subroutine or method that can take either a bare argument list or a
Capture and treat them the same, because of the intractable ambiguity that
would arise in the case of an argument list that actually contains a
single capture as its only positional element. If I'm mistaken, then
other avenues open up. But I don't think I am.)
Audrey confirmed to me on IRC that the motivation for the arglistless form
was that passing on the original arguments will likely be one of the most
common uses of call. And I certainly can't argue with that, I agree.
But why, then, does .call not have an argumentless form? (Because we
can't write user-defined methods, short of Cis parsed tricks, that
differentiate between .meth and .meth()? We can't write user-defined subs
that do that either, AFAIK...)
Might I propose the following normalization:
1. .call, method definition call(), and .wrap call all take captures.
2. .call() and both types of call() all pass on the arguments of the
current subroutine.
3. To call with no arguments, use .call(\()) and call(\()).
4. Introduce some syntax for getting a capture of the current argument
list explicitly. Perhaps $?ARGS or $?_ or $?CAPTURE. One shouldn't
have to choose between repeating your 20 parameters in order to take a
capture of them, and eliminating your nice self-documenting 20
parameter names so you can use the easy \$arglist trick.
Trey
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor schrieb: Ian Langworth wrote: A general, simple CGI handling module fits into 200 lines, including POD. [..] You don't really need more. IMHO a CGI module parses/preprocesses/decodes/etc. all incoming parameters (POST, GET, COOKIES), and that's it. I can support this statement: In a ~30k lines (incl POD) web project I actually use CGI.pm mostly for parameter parsing: $ grep -ri 'cgi-' * | grep -v new | wc -l 97 Wehereas I hardly use for anything else: $ grep -ri 'cgi-' * | grep -v new | grep -v param | wc -l 7 4 of these 7 matches address file upload handling, the other 3 match in an other custom module with the name *::CGI - not CGI.pm. But I think that it would be a good idea to create a clean, servlety foundation, upon which you still can implement a 200 lines CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks. Regards -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
[perl #40370] [PATCH] code_coda.t update
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40370]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40370
Hi,
Attached is a patch for the code_coda.t test. The test now accepts
files passed in at the command line as advertised, and the regular
expression check has been fixed (I won't say improved as I think it
could be better, but it matches the coda at the end of the C files
now). Included in the regular expression is a somewhat more pedantic
version of the coda check, but I've commented this one out as I don't
know how picky people want to be (in other words, hack the patch at
will).
Files affected:
t/codingstd/code_coda.t
Regards,
Paul
Index: t/codingstd/code_coda.t
===
--- t/codingstd/code_coda.t (revision 14668)
+++ t/codingstd/code_coda.t (working copy)
@@ -38,27 +38,51 @@
my @files = @ARGV ? @ARGV : source_files();
my @comments;
+# process all files given to the script
foreach my $file ( @files ) {
my $buf;
-my $path = $file-path;
+my $path;
+
+## get the full path of the file
+# if we have command line arguments, the file is the full path
+if (@ARGV 0) {
+$path = $file;
+}
+# otherwise, use the relevant Parrot:: path method
+else {
+$path = $file-path;
+}
+
+# slurp in the file
open(my $fh, '', $path)
or die Cannot open '$path' for reading: $!\n;
{
local $/;
$buf = $fh;
}
+
+# append to the comments array if the code doesn't match
push @comments = $path\n
-unless $buf =~ m{\Q
-/*
- * Local variables:
- * c-file-style: parrot
- * End:
- * vim: expandtab shiftwidth=4:
- */\E
- \n* \z
+unless $buf =~ m{
+#/ \* \s*
+#\* [ ] Local [ ] variables: \s*
+#\* [ ] [ ] [ ] c-file-style: [ ] parrot \s*
+#\* [ ] End: \s*
+#\* [ ] vim: [ ] expandtab [ ] shiftwidth=4: \s*
+#\* /
+#\n* \z
+/ \* \s*
+ \* \s* Local \s* variables: \s*
+ \* \s* c-file-style: \s* parrot \s*
+ \* \s* End: \s*
+ \* \s* vim: \s* expandtab \s* shiftwidth=4: \s*
+ \* /
+\n* \z
}x;
+
}
+
ok(!scalar(@comments), 'C code coda')
or diag(C code coda missing in .scalar @comments. files:[EMAIL PROTECTED]);
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor skribis 2006-09-20 11:28 (+0200): You rarely do real HTTP handling when you use CGI. You may not, but many people do a lot of these things. And when you don't, the datastructures are currently parsed and filled anyway, so I don't know why you say it'd be too inefficient. A general, simple CGI handling module fits into 200 lines, including POD. Imagine like That's not CGI handling, that's form parameter parsing. CGI, and web programming, is much more than that. You don't really need more. I think you mean: I don't really need more. Many people do need a whole lot more, and CGI.pm does do a whole lot more. Just not in a nicely organized set of classes. It's unfortunate that it mostly lets the user handle headers that are communicated through ENV, precisely because that's part of the CGI spec, and not common to other kinds of web programming, so it's specifically a job for a module called CGI.pm It might give some useful other routines (e.g. url encoding / decoding, various ways to mix GET+POST, set content types more easily, etc.), but other than that, it should be very lightweight and easy to use. I agree that things should be lightweight and easy to use. But in Perl 6, that doesn't mean that you should avoid nicely structured OO. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Thomas Wittek wrote: [...] But I think that it would be a good idea to create a clean, servlety foundation, upon which you still can implement a 200 lines CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks. That sounds nice. - Cs.
Re: renaming grep to where
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a label value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that label.
Personally, I don't have a problem with us keeping 'grep'. However, if
we do decide to change the name, I suspect 'keep' might be readable,
short, SWIM, and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
OK then. Just so that I can type of the final result in S29, let's see
if everyone agrees to several points that have been made in this thread:
1. classify is the real grep
2. convenience function, keep is probably a macro
3. use List :compat will get you a grep just as it will likely get
you mv on the OS module, etc.
Is any of this going to break the bank? If not, I'll get it in today.
Re: renaming grep to where
Aaron (): OK then. Just so that I can type of the final result in S29, let's see if everyone agrees to several points that have been made in this thread: 1. classify is the real grep 2. convenience function, keep is probably a macro 3. use List :compat will get you a grep just as it will likely get you mv on the OS module, etc. Is any of this going to break the bank? If not, I'll get it in today. You mean grep is going away? I'd had hoped that enough people had expressed their I like grep and Don't fix what isn't broken opinions for it not to... Oh well. I'll miss it. -- masak
Re: renaming grep to where
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, keep implies throwing
the rest away,I.e., modifying the list. Select has the advantage of
lacking that connotation. To avoid dissonance with the two perl5
selects, we could go with a synonym like choose or, in the 4-char
category, pick. But my vote is still to keep grep as grep.
On 9/20/06, Aaron Sherman [EMAIL PROTECTED] wrote:
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a label value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that label.
Personally, I don't have a problem with us keeping 'grep'. However, if
we do decide to change the name, I suspect 'keep' might be readable,
short, SWIM, and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
OK then. Just so that I can type of the final result in S29, let's see
if everyone agrees to several points that have been made in this thread:
1. classify is the real grep
2. convenience function, keep is probably a macro
3. use List :compat will get you a grep just as it will likely get
you mv on the OS module, etc.
Is any of this going to break the bank? If not, I'll get it in today.
--
Mark J. Reed [EMAIL PROTECTED]
Re: renaming grep to where
[EMAIL PROTECTED] wrote: I still don't think we have a consensus that grep needs to be renamed, much less what it should be renamed to. To me, keep implies throwing the rest away,I.e., modifying the list. Select has the advantage of lacking that connotation. To avoid dissonance with the two perl5 selects, we could go with a synonym like choose or, in the 4-char category, pick. But my vote is still to keep grep as grep. I don't know that we have consensus, I was just trying to bring this thread in for a landing so I can write it up. As S29 stands now, there is a grep, and there is no classify. At least the latter needs to be fixed, per Damian pointing out lost history that I should have been on top of. I'll wait on the removal of grep for any(@larry) to make a clear statement to that effect.
Re: call, call(), .call, and captures
Trey Harris wrote: Might I propose the following normalization: 1. .call, method definition call(), and .wrap call all take captures. 2. .call() and both types of call() all pass on the arguments of the current subroutine. 3. To call with no arguments, use .call(\()) and call(\()). I have no problem with that, but the original form should probably exist too. I don't know if that's called invoke or what, but something that takes an arglist and constructs the capture to pass on would be very helpful to most users. 4. Introduce some syntax for getting a capture of the current argument list explicitly. Perhaps $?ARGS or $?_ or $?CAPTURE. One shouldn't have to choose between repeating your 20 parameters in order to take a capture of them, and eliminating your nice self-documenting 20 parameter names so you can use the easy \$arglist trick. I like the idea in 4, even though I'm not sure that I follow the rest of your logic. Having access to a variable that contains the current argument list called $?ARGS seems to be in line with the rest of the $? state variables that are provided. So, in general, I think the only thing missing is something like invoke so that: invoke(1,2,3); is identical to: call(\(1,2,3)); and: invoke([,] =$?ARGS); is identical to: call($?ARGS); is identical to: call(); Certainly a distinction on call vs call() is not what Perl 6 programmers will come to expect from the rest of the language, and I see no pressing reason to introduce it here.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Juerd wrote: Fagyal Csongor skribis 2006-09-20 11:28 (+0200): You rarely do real HTTP handling when you use CGI. You may not, but many people do a lot of these things. Actually me, too. Not with CGI.pm, though. I tend to use CGI::Simple for form/param parsing, Template.pm for template processing, LWP::Simple for... well, HTTP handling (kind of...) and so on and so on. And when you don't, the datastructures are currently parsed and filled anyway, so I don't know why you say it'd be too inefficient. Inefficient was probably a bad choice of word. I would rather say: I would not like to see Perl6's CGI.pm as a monster module, which has one part everyone uses, and one hundred other parts that some uses, because I feel those parts should be put into other modules. I just feel quilty when I use (Perl5's) CGI.pm for such trivial tasks as parameter parsing. Feels like... say, using MIME::Lite for *sending* mail not *constructing*. Or maybe... you know, I have a Windows XP installed at home. The one thing I use it for is to run dvdsrhink :)) That's a big price for 10G of discspace :) As a side note I also have to add that I really dislike the html-functions CGI.pm currently has. Creating the representation is the task of the designer, not the programmer. It's almost like echo in PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP, mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those HTML generating methods. To me, imhoit feels wrong that they are there/imho. A general, simple CGI handling module fits into 200 lines, including POD. Imagine like That's not CGI handling, that's form parameter parsing. CGI, and web programming, is much more than that. That I know :) That's what I do for a living :), for almost like 10 years now. And I started with cgi-lib.pl :) ...which makes me think CGI.pm should not do much more than that old horse. But please see below. You don't really need more. I think you mean: I don't really need more. Many people do need a whole lot more, and CGI.pm does do a whole lot more. My public domain framework's dispatcher class starts something like: use strict; use FCGI; use Template; use Template::Stash; use CGI::Simple::Cookie; use CGI::Simple; use Config::General; use Data::Dumper; use Time::HiRes; use Digest::MD5; use PET::GCONF; use HTML::FillInForm; use LWP::Simple; use MIME::Base64 qw/encode_base64/; use PET::Filter; use PET::Util; use PET::Log; use PET::CacheControl; use Storable; use Carp qw/croak cluck carp/; use UNIVERSAL; use BSD::Itimer; use POSIX qw/setuid setgid/; use BSD::Resource; And that's just the dispatcher - the framework uses every third module from CPAN, so to say :) So I am also between those people who need a lot more - yet I think CGI.pm should only do parameter parsing. But no, that is not correct. What I really want to say is that I have no problem with any parts of the original CGI.pm, *except for* the HTML generation stuff. CGI/Lite.pm is ~1200 lines. CGI.pm is ~7500 lines. And what is missing? From the man page of CGI::Simple: CGI::Simple provides a relatively lightweight drop in replacement for CGI.pm. It shares an identical OO interface to CGI.pm for parameter parsing, file upload, cookie handling and header generation. This mod- ule is entirely object oriented, however a complete functional interface is available by using the CGI::Simple::Standard module. Essentially everything in CGI.pm that relates to the CGI (not HTML) side of things is available. There are even a few new methods and additions to old ones! If you are interested in what has gone on under the hood see the Compatibility with CGI.pm section at the end. Just not in a nicely organized set of classes. If you put it that way, I can certanly agree. It's unfortunate that it mostly lets the user handle headers that are communicated through ENV, precisely because that's part of the CGI spec, and not common to other kinds of web programming, so it's specifically a job for a module called CGI.pm It might give some useful other routines (e.g. url encoding / decoding, various ways to mix GET+POST, set content types more easily, etc.), but other than that, it should be very lightweight and easy to use. I agree that things should be lightweight and easy to use. But in Perl 6, that doesn't mean that you should avoid nicely structured OO. If we talk about nicely structured OO, I can see a few ways: - CGI.pm include something like CGI::HTML, to get rid of the HTML generating part, or maybe even separating CGI::HTML and CGI::Request - now that I write it down, for me it feels more natural to have something like HTML::CGI : # imagine something like: $cgi = new CGI; $html = HTML::CGI-new($cgi); $html-popup_menu( ... ); # I won't do this, but others might... :) ...and still I think that a module named CGI should handle the CGI 1.1
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Erm...
Sorry for the bandwith usage again, but what about something like
class CGI
is CGI::Base
does CGI::ParamParser
does CGI::HTML
{ ... }
?
To make CGI.pm kind of backward compatible, but separates the layers.
(Please excuse my bad syntax/semantics.)
- Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor wrote: # imagine something like: $cgi = new CGI; $html = HTML::CGI-new($cgi); $html-popup_menu( ... ); # I won't do this, but others might... :) My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? I'd love the Perl 6 version to have a compatibility mode where it returned the methods we're all used to, but encouraged something which was more intuitive. Perhaps that would be better in two modules which essentially did the same thing though. All the best, J
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor skribis 2006-09-20 15:43 (+0200):
Inefficient was probably a bad choice of word.
I would rather say: I would not like to see Perl6's CGI.pm as a monster
module, which has one part everyone uses, and one hundred other parts
that some uses, because I feel those parts should be put into other
modules.
Perl 6's Web toolkit, even with all these classes, is likely to be much
lighter than Perl 5's CGI.pm with :standard.
But note that especially if it is a well designed bundle of
classes/roles, you can pick exactly those things that you need, and
leave all others out. That's part of the reason why you should separate
things.
As a side note I also have to add that I really dislike the
html-functions CGI.pm currently has. Creating the representation is
the task of the designer, not the programmer.
That's an ideal world. Many programmers have to hack some HTML
themselves. I do think that they're far better off with raw HTML, but
there are people who prefer the generation methods, and we should try to
make everyone happy, not just ourselves.
To me, imhoit feels wrong that they are there/imho.
It *is* wrong to have them in CGI.pm. It wouldn't be wrong to have them
in a Web toolkit. In any case, I think they should only be loaded on
request.
And that's just the dispatcher - the framework uses every third module
from CPAN, so to say :) So I am also between those people who need a lot
more - yet I think CGI.pm should only do parameter parsing.
I think CGI.pm, as in Perl 5, should not ever be written for Perl 6.
I think Web::CGI could handle CGI requests well, but not just parameter
parsing. It should also do ENV parsing. If you want to implement only
parameter parsing, don't ask for CGI, because CGI is more than that.
generation stuff. CGI/Lite.pm is ~1200 lines. CGI.pm is ~7500 lines. And
Please don't measure things in lines. For starters, your line counts
include documentation. These numbers are meaningless.
If we talk about nicely structured OO, I can see a few ways:
- CGI.pm include something like CGI::HTML, to get rid of the HTML
generating part, or maybe even separating CGI::HTML and CGI::Request
s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except
perhaps for its compatibility syntax), and neither does HTTP::Daemon. We
should write generic code, suitable for any implementation.
I'm thinking of:
Web::Init::CGI # Initializer for CGI requests
Web::Init::FastCGI # Initializer for FastCGI requests
Web::Init::ModPerl # Initializer for ModPerl requests
Web::Request# Request objects
Web::Response # Response objects
Web::Session# Session objects
Web::HTML # HTML generation
Web::Util # HTML-entities, URI-encoding, etc
Web # utility module that mostly loads other modules
- now that I write it down, for me it feels more natural to have
something like HTML::CGI :
# imagine something like:
$cgi = new CGI;
$html = HTML::CGI-new($cgi);
$html-popup_menu( ... ); # I won't do this, but others might... :)
use Web $web :html;
$web.popup_menu(...);
implemented by something like
class Web {
has $.request;
...
}
role Web::HTML {
method popup_menu(...) {
# something with .request
}
}
...and still I think that a module named CGI should handle the CGI 1.1
(1.2) specification (read *STDIN, write to *STDOUT, parse %ENV , that
is) and do nothing more.
That's a good idea, and I agree. But CGI.pm should only be a tiny part
of our web toolkit.
You know... as the matter of fact, I think we are only arguing about
namespace usage here :))
Yes. I'm talking about a web development toolkit, that does at least
what CGI.pm did, and not about CGI as a namespace, because I think
that's an incredibly bad thing anyway.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? Yes, this needs to be redesigned completely. Are you volunteering? I'd love the Perl 6 version to have a compatibility mode where it returned the methods we're all used to, but encouraged something which was more intuitive. Perhaps that would be better in two modules which essentially did the same thing though. The compatibility mode is perl5:CGI, that loads the old Perl 5 CGI.pm. There's little need for us to port bad things to Perl 6. Peoplo who really want or need to use them can, and we should concentrate on creating something that's GOOD for new code. This said, I do think it'd be wise to document changes in accessible tables. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Trying to make a new operator
Thanks for help. For anyone else, the following works.
sub infix:grew_by_to {...};
(32 grew_by_to 48).say;
sub infix:grew_by_to ($left, $right) {
return ($right/$left - 1) * 100 ~ '%';
};
Yuval Kogman wrote:
On Sun, Sep 17, 2006 at 16:35:39 +0100, Daniel Hulme wrote:
What am I doing wrong?
Sounds like you need to define (or at least declare) the new operator
before you use it. Perl 6, like Perl 5 compiles with a single pass, so
when you are using your random operator, it hasn't yet read the
declaration further down the file.
s/use/parse/;
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Juerd wrote: [...] Fagyal Csongor skribis 2006-09-20 15:43 (+0200): Inefficient was probably a bad choice of word. I would rather say: I would not like to see Perl6's CGI.pm as a monster module, which has one part everyone uses, and one hundred other parts that some uses, because I feel those parts should be put into other modules. Perl 6's Web toolkit, even with all these classes, is likely to be much lighter than Perl 5's CGI.pm with :standard. I guess that's one of the reasons we are heading from 5 to 6 :) But note that especially if it is a well designed bundle of classes/roles, you can pick exactly those things that you need, and leave all others out. That's part of the reason why you should separate things. And here is another reason :) [...] If we talk about nicely structured OO, I can see a few ways: - CGI.pm include something like CGI::HTML, to get rid of the HTML generating part, or maybe even separating CGI::HTML and CGI::Request s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except perhaps for its compatibility syntax), and neither does HTTP::Daemon. We should write generic code, suitable for any implementation. I'm thinking of: Web::Init::CGI # Initializer for CGI requests Web::Init::FastCGI # Initializer for FastCGI requests Web::Init::ModPerl # Initializer for ModPerl requests Web::Request# Request objects Web::Response # Response objects Web::Session# Session objects Web::HTML # HTML generation Web::Util # HTML-entities, URI-encoding, etc Web # utility module that mostly loads other modules Hmmm. A very sound idea. Reorganising the CPAN namespace :) (This CGI/HTTP/LWP/HTML/etc. got a bit confusing as it grew.) I would say, maybe add Web::Tools::* so that others can add various useful (and not that useful) modules without mixing up everything. And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. So is Web::Init::* class supposed to be selected by Web, and Web::Init(::*) used by e.g. Web::Request Web::Response, so it all becomes transparent? Yes. I'm talking about a web development toolkit, that does at least what CGI.pm did, and not about CGI as a namespace, because I think that's an incredibly bad thing anyway. I absolutely agree. - Fagzal
Perl6 style-guide
Hi, I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. I am afraid that when I will be starting to write Perl6 code, it will be too much Perl5-ish, and I will end up rewriting my code in every 3 months because I hate when my code is not elegant (at least to my own standards). I was wondering that some - maybe @Larry - already have (mosf ot) Perl6 in their heads, so they could create such a document/recommendation before Perl6 gets used widely, and the coding style gets distorted. Or shall we just leave this to the community? Maybe this documentation shouldn't/can't be written yet? Shall we let Perl6-style grow from usage in 1-2 years, and create a guide like this then, when things mature? - Fagzal
Re: Perl6 style-guide
On 9/20/06, Fagyal Csongor [EMAIL PROTECTED] wrote: I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. yes, there should be. I am afraid that when I will be starting to write Perl6 code, it will be too much Perl5-ish, and I will end up rewriting my code in every 3 months because I hate when my code is not elegant (at least to my own standards). i think that's a problem you'll share with many other folks, as *very few* have written anything of substance in perl 6 so far... and the design is still changing. I was wondering that some - maybe @Larry - already have (mosf ot) Perl6 in their heads, so they could create such a document/recommendation before Perl6 gets used widely, and the coding style gets distorted. i think larry's pretty busy doing what he should be doing at this point... designing. Or shall we just leave this to the community? Maybe this documentation shouldn't/can't be written yet? Shall we let Perl6-style grow from usage in 1-2 years, and create a guide like this then, when things mature? don't just leave this to the community. take part! take advantage of the perl 6 wiki (http://rakudo.org/perl6/index.cgi) and create a page describing the task. write some code yourself. ask folks to contribute, and fix the existing code or add their own. create an outline of what you'd like to see there... and have fun! be the community. ~jerry
Re: Perl6 style-guide
On 9/20/06, jerry gay [EMAIL PROTECTED] wrote: don't just leave this to the community. take part! take advantage of the perl 6 wiki (http://rakudo.org/perl6/index.cgi) and create a page describing the task. write some code yourself. ask folks to contribute, and fix the existing code or add their own. create an outline of what you'd like to see there... and have fun! be the community. ~jerry Would a plausible idea be to have a section on the wiki devoted to free coding? All developers, including those brand new to Perl 6, could start writing random test code, which the more experienced in the Perl 6 world could then tweak so that eventually, we should have a very broad sample of code that the community has decided looks right. Michael
[perl #40373] [PATCH] C coda fix in parrot/config/gen
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40373] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40373 Hi, This patch adds the C-specific emacs/vim coda to all C-language files under parrot/config/gen. Regards, Paul Files affected by this patch: config/gen/platform/netbsd/math.c config/gen/platform/cygwin/math.c config/gen/platform/win32/time.c config/gen/platform/win32/dl.c config/gen/platform/win32/threads.h config/gen/platform/win32/stat.h config/gen/platform/win32/misc.h config/gen/platform/win32/signal.h config/gen/platform/win32/begin.c config/gen/platform/win32/exec.c config/gen/platform/win32/env.c config/gen/platform/win32/misc.c config/gen/platform/win32/stat.c config/gen/platform/win32/io.h config/gen/platform/win32/signal.c config/gen/platform/darwin/dl.c config/gen/platform/darwin/begin.c config/gen/platform/darwin/memalign.c config/gen/platform/ansi/time.c config/gen/platform/ansi/dl.c config/gen/platform/ansi/exec.c config/gen/platform/ansi/io.h config/gen/platform/openbsd/misc.h config/gen/platform/openbsd/memexec.c config/gen/platform/openbsd/math.c config/gen/platform/platform_interface.h config/gen/platform/generic/math.h config/gen/platform/generic/time.c config/gen/platform/generic/threads.h config/gen/platform/generic/dl.c config/gen/platform/generic/dl.h config/gen/platform/generic/stat.c config/gen/platform/generic/io.h config/gen/platform/generic/signal.c config/gen/platform/generic/stat.h config/gen/platform/generic/signal.h config/gen/platform/generic/memexec.c config/gen/platform/generic/exec.c config/gen/platform/generic/env.c config/gen/platform/generic/memalign.c config/gen/platform/generic/itimer.c config/gen/platform/generic/math.c config/gen/platform/solaris/time.c config/gen/platform/solaris/math.c config/gen/cpu/i386/memcpy_mmx_in.c config/gen/cpu/i386/memcpy_sse.c config/gen/cpu/i386/memcpy_sse_in.c config/gen/cpu/i386/memcpy_mmx.c
[perl #40372] [PATCH] C coda fix in parrot/compilers
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40372]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40372
Hi,
This is a patch of all .c and .h files found by
t/codingstd/code_coda.t that reside under parrot/compilers to add the
required emacs and vim coda. This patch partially adresses bug:
#40279 [CAGE] C coding standards coda. The files affected are listed
below.
Regards,
Paul
Files affected:
compilers/ast/astparser.c
compilers/ast/node.c
compilers/ast/astlexer.c
compilers/ast/astparser.h
compilers/ast/ast_main.c
compilers/ast/ast.h
compilers/imcc/cfg.c
compilers/imcc/parser.h
compilers/imcc/pbc.c
compilers/imcc/instructions.c
compilers/imcc/cfg.h
compilers/imcc/symreg.c
compilers/imcc/pbc.h
compilers/imcc/instructions.h
compilers/imcc/symreg.h
compilers/imcc/optimizer.c
compilers/imcc/unit.h
compilers/imcc/imcparser.c
compilers/imcc/debug.c
compilers/imcc/optimizer.h
compilers/imcc/reg_alloc.c
compilers/imcc/imcparser.h
compilers/imcc/debug.h
compilers/imcc/pcc.c
compilers/imcc/imclexer.c
compilers/imcc/imc.c
compilers/imcc/imc.h
compilers/imcc/sets.c
compilers/imcc/sets.h
compilers/imcc/main.c
compilers/imcc/parser_util.c
compilers/imcc/reg_alloc_bc.c
compilers/bcg/include/bcg.h
compilers/bcg/src/bcg_emitter_pasm.c
compilers/bcg/src/bcg_reg_alloc_vanilla.c
compilers/bcg/src/bcg_op.c
compilers/bcg/src/bcg_logger.c
compilers/bcg/src/bcg_unit.c
compilers/bcg/src/bcg.c
compilers/bcg/src/bcg_utils.c
Index: compilers/ast/astparser.c
===
--- compilers/ast/astparser.c (revision 14669)
+++ compilers/ast/astparser.c (working copy)
@@ -1758,3 +1758,10 @@
}
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: compilers/ast/node.c
===
--- compilers/ast/node.c (revision 14669)
+++ compilers/ast/node.c (working copy)
@@ -1286,11 +1286,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: compilers/ast/astlexer.c
===
--- compilers/ast/astlexer.c (revision 14669)
+++ compilers/ast/astlexer.c (working copy)
@@ -1755,3 +1755,10 @@
int yywrap(void) { return 1; }
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: compilers/ast/astparser.h
===
--- compilers/ast/astparser.h (revision 14669)
+++ compilers/ast/astparser.h (working copy)
@@ -96,3 +96,10 @@
#endif
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: compilers/ast/ast_main.c
===
--- compilers/ast/ast_main.c (revision 14669)
+++ compilers/ast/ast_main.c (working copy)
@@ -165,10 +165,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: compilers/ast/ast.h
===
--- compilers/ast/ast.h (revision 14669)
+++ compilers/ast/ast.h (working copy)
@@ -68,3 +68,10 @@
#endif /* PARROT_AST_H_GUARD */
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: compilers/imcc/cfg.c
===
--- compilers/imcc/cfg.c (revision 14669)
+++ compilers/imcc/cfg.c (working copy)
@@ -1171,10 +1171,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: compilers/imcc/parser.h
===
--- compilers/imcc/parser.h (revision 14669)
+++ compilers/imcc/parser.h (working copy)
@@ -71,10 +71,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: compilers/imcc/pbc.c
===
--- compilers/imcc/pbc.c (revision 14669)
+++ compilers/imcc/pbc.c (working copy)
@@ -1340,11 +1340,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: compilers/imcc/instructions.c
===
--- compilers/imcc/instructions.c (revision 14669)
+++
[perl #40371] [PATCH] as2c.pl C-file coda fix
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40371]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40371
Hi,
Attached is a patch for tools/dev/as2c.pl which adds a new subroutine
print_coda() which attaches the C coda to the autogenerated C files
and gets them to pass the code_coda.t test. This was patched against
revision 14669.
Regards,
Paul
Index: tools/dev/as2c.pl
===
--- tools/dev/as2c.pl (revision 14669)
+++ tools/dev/as2c.pl (working copy)
@@ -14,6 +14,7 @@
create_s($cmd);
parse_s($src.s);
add_glue($src.c);
+$print_coda();
sub print_header {
my $s = shift;
@@ -27,6 +28,19 @@
EOT
}
+
+sub print_coda {
+print EOT;
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+*/
+EOT
+}
+
sub create_s {
my $cmd = shift;
my $r = system($cmd);
Re: [perl #40360] [PATCH] implement loadlib(NULL)
Am Dienstag, 19. September 2006 11:51 schrieb Dmitry Karasik: dlopen(NULL,...) on linux returns NULL, and consequently dlsym(NULL,...) can be used to access shared objects of the main executable. However, on freebsd dlsym(NULL,...) server somewhat different purpose, and to access the main executable dlsym(dlopen(NULL,...),...) must be used instead. Great. Thanks, applied - r14670. leo
Re: [perl #40364] [PATCH] line endings of perl .t test files
On 9/19/06, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40364 This patch changes the line endings of the files listed below from dos to unix. thanks, applied by bernhard, r14667. ~jerry
[perl #40374] [PATCH] C coda fix in parrot/include
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40374] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40374 Hi, This patches all C-language files in parrot/include that require the C emacs/vim coda. This patch partially addresses bug #40279 [CAGE] C coding standards coda. I think parrot/src can wait until another day... Regards, Paul Files affected by this patch: include/parrot/sub.h include/parrot/misc.h include/parrot/slice.h include/parrot/smallobject.h include/parrot/oplib.h include/parrot/tsq.h include/parrot/parrot.h include/parrot/cclass.h include/parrot/exit.h include/parrot/resources.h include/parrot/embed.h include/parrot/stm/backend.h include/parrot/hll.h include/parrot/hash.h include/parrot/register.h include/parrot/atomic/fallback.h include/parrot/atomic/gcc_pcc.h include/parrot/atomic/gcc_x86.h include/parrot/atomic/sparc.h include/parrot/encoding.h include/parrot/debug.h include/parrot/caches.h include/parrot/enums.h include/parrot/charset.h include/parrot/global.h include/parrot/settings.h include/parrot/string_funcs.h include/parrot/events.h include/parrot/dod.h include/parrot/thr_windows.h include/parrot/memory.h include/parrot/pic.h include/parrot/list.h include/parrot/atomic.h include/parrot/inter_call.h include/parrot/pmc.h include/parrot/exec.h include/parrot/intlist.h include/parrot/key.h include/parrot/pobj.h include/parrot/builtin.h include/parrot/string.h include/parrot/io.h include/parrot/stat.h include/parrot/headers.h include/parrot/op.h include/parrot/global_setup.h include/parrot/string_primitives.h include/parrot/longopt.h include/parrot/warnings.h include/parrot/objects.h include/parrot/datatypes.h include/parrot/vtables.h include/parrot/interpreter.h include/parrot/thr_pthread.h include/parrot/library.h include/parrot/thread.h include/parrot/nci.h include/parrot/compiler.h include/parrot/dynext.h include/parrot/mmd.h include/parrot/packfile.h include/parrot/pmc_freeze.h include/parrot/exceptions.h include/parrot/extend.h include/parrot/stacks.h Index: include/parrot/sub.h === --- include/parrot/sub.h (revision 14669) +++ include/parrot/sub.h (working copy) @@ -156,10 +156,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: include/parrot/misc.h === --- include/parrot/misc.h (revision 14669) +++ include/parrot/misc.h (working copy) @@ -193,10 +193,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: include/parrot/slice.h === --- include/parrot/slice.h (revision 14669) +++ include/parrot/slice.h (working copy) @@ -37,10 +37,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: include/parrot/smallobject.h === --- include/parrot/smallobject.h (revision 14669) +++ include/parrot/smallobject.h (working copy) @@ -177,10 +177,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: include/parrot/oplib.h === --- include/parrot/oplib.h (revision 14669) +++ include/parrot/oplib.h (working copy) @@ -61,10 +61,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: include/parrot/tsq.h === --- include/parrot/tsq.h (revision 14669) +++ include/parrot/tsq.h (working copy) @@ -62,10 +62,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: include/parrot/parrot.h === --- include/parrot/parrot.h (revision 14669) +++ include/parrot/parrot.h (working copy) @@ -311,10 +311,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: include/parrot/cclass.h === --- include/parrot/cclass.h (revision
[perl #40375] [PATCH] C coda fix in parrot/config/gen
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40375]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40375
Hi,
It seems I forgot to attach the patch to this email. Many apologies!
Here it is again.
Regards,
Paul
This patch adds the C-specific emacs/vim coda to all C-language files
under parrot/config/gen.
Files affected by this patch:
config/gen/platform/netbsd/math.c
config/gen/platform/cygwin/math.c
config/gen/platform/win32/time.c
config/gen/platform/win32/dl.c
config/gen/platform/win32/threads.h
config/gen/platform/win32/stat.h
config/gen/platform/win32/misc.h
config/gen/platform/win32/signal.h
config/gen/platform/win32/begin.c
config/gen/platform/win32/exec.c
config/gen/platform/win32/env.c
config/gen/platform/win32/misc.c
config/gen/platform/win32/stat.c
config/gen/platform/win32/io.h
config/gen/platform/win32/signal.c
config/gen/platform/darwin/dl.c
config/gen/platform/darwin/begin.c
config/gen/platform/darwin/memalign.c
config/gen/platform/ansi/time.c
config/gen/platform/ansi/dl.c
config/gen/platform/ansi/exec.c
config/gen/platform/ansi/io.h
config/gen/platform/openbsd/misc.h
config/gen/platform/openbsd/memexec.c
config/gen/platform/openbsd/math.c
config/gen/platform/platform_interface.h
config/gen/platform/generic/math.h
config/gen/platform/generic/time.c
config/gen/platform/generic/threads.h
config/gen/platform/generic/dl.c
config/gen/platform/generic/dl.h
config/gen/platform/generic/stat.c
config/gen/platform/generic/io.h
config/gen/platform/generic/signal.c
config/gen/platform/generic/stat.h
config/gen/platform/generic/signal.h
config/gen/platform/generic/memexec.c
config/gen/platform/generic/exec.c
config/gen/platform/generic/env.c
config/gen/platform/generic/memalign.c
config/gen/platform/generic/itimer.c
config/gen/platform/generic/math.c
config/gen/platform/solaris/time.c
config/gen/platform/solaris/math.c
config/gen/cpu/i386/memcpy_mmx_in.c
config/gen/cpu/i386/memcpy_sse.c
config/gen/cpu/i386/memcpy_sse_in.c
config/gen/cpu/i386/memcpy_mmx.c
Index: config/gen/platform/netbsd/math.c
===
--- config/gen/platform/netbsd/math.c (revision 14669)
+++ config/gen/platform/netbsd/math.c (working copy)
@@ -48,3 +48,10 @@
return u.i[2] 0;
}
#endif
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: config/gen/platform/cygwin/math.c
===
--- config/gen/platform/cygwin/math.c (revision 14669)
+++ config/gen/platform/cygwin/math.c (working copy)
@@ -46,3 +46,10 @@
return u.i[2] 0;
}
#endif
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: config/gen/platform/win32/time.c
===
--- config/gen/platform/win32/time.c (revision 14669)
+++ config/gen/platform/win32/time.c (working copy)
@@ -71,3 +71,10 @@
{
return strcpy(buffer, asctime(tm));
}
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: config/gen/platform/win32/dl.c
===
--- config/gen/platform/win32/dl.c (revision 14669)
+++ config/gen/platform/win32/dl.c (working copy)
@@ -41,3 +41,10 @@
return FreeLibrary(handle)? 0: 1;
}
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: config/gen/platform/win32/threads.h
===
--- config/gen/platform/win32/threads.h (revision 14669)
+++ config/gen/platform/win32/threads.h (working copy)
@@ -1,3 +1,10 @@
#include parrot/thr_windows.h
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: config/gen/platform/win32/stat.h
===
--- config/gen/platform/win32/stat.h (revision 14669)
+++ config/gen/platform/win32/stat.h (working copy)
@@ -21,3 +21,10 @@
#ifndef S_ISDIR
# define S_ISDIR(m) ((m S_IFMT) == S_IFDIR)
#endif
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: config/gen/platform/win32/misc.h
===
--- config/gen/platform/win32/misc.h (revision 14669)
+++ config/gen/platform/win32/misc.h (working copy)
@@ -12,3 +12,10 @@
#pragma warning( disable: 4505 ) /* disables 'unreferenced local function has
* been removed' warnings in header files */
#endif /* defined(_MSC_VER) */
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
Index: config/gen/platform/win32/signal.h
[perl #40377] [PATCH] C coda fix in parrot/examples
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40377] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40377 Hi, This patch adds the C emacs/vim coda to the C-language files under parrot/examples, and partially addresses bug #40279 [CAGE] C coding standards coda. Regards, Paul Files affected by this patch: examples/c/test_main.c examples/compilers/japhc.c examples/nci/PQt.C examples/mops/mops.c Index: examples/c/test_main.c === --- examples/c/test_main.c (revision 14669) +++ examples/c/test_main.c (working copy) @@ -290,11 +290,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: examples/compilers/japhc.c === --- examples/compilers/japhc.c (revision 14669) +++ examples/compilers/japhc.c (working copy) @@ -183,3 +183,10 @@ sub_data-name = string_from_cstring(interpreter, JaPHC, 0); return sub; } + +/* + * Local variables: + * c-file-style: parrot + * End: + * vim: expandtab shiftwidth=4: + */ Index: examples/nci/PQt.C === --- examples/nci/PQt.C (revision 14669) +++ examples/nci/PQt.C (working copy) @@ -140,3 +140,10 @@ =cut */ + +/* + * Local variables: + * c-file-style: parrot + * End: + * vim: expandtab shiftwidth=4: + */ Index: examples/mops/mops.c === --- examples/mops/mops.c (revision 14669) +++ examples/mops/mops.c (working copy) @@ -116,10 +116,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: parrot * End: - * * vim: expandtab shiftwidth=4: */
[perl #40370] [PATCH] code_coda.t update
thanks, applied as r14671. ~jerry
[perl #40371] [PATCH] as2c.pl C-file coda fix
thanks, applied as r14673, with a minor fix: -$print_coda(); +print_coda(); i'm not sure tools/dev/as2c.pl is used, as the only makefile that calls it isn't generated (config/gen/cpu/i386/Makefile), it's not platform-independent, and the files it generates are committed to the repository. but, that's for another ticket. ~jerry
[perl #40379] [TODO] investigate use of tools/dev/as2c.pl
# New Ticket Created by Jerry Gay # Please include the string: [perl #40379] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40379 i'm not sure tools/dev/as2c.pl is used, as the only makefile that calls it isn't generated (config/gen/cpu/i386/Makefile), it's not platform-independent, and the files it generates are committed to the repository. ~jerry
[perl #40372] [PATCH] C coda fix in parrot/compilers
thanks, applied as r14674. ~jerry
Re: renaming grep to where
Quoth [EMAIL PROTECTED]: On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. I would second that strongly. Perl6 is already different enough from Perl5 for good reasons; making it different for bad reasons seems to me a really bad idea. If this sort of change is on the cards, then for consistency a serious effort should be made to remove *all* Unixisms from Perl (unlink, flock, fork, and all the signal stuff spring to mind; a case could be made for the filetest ops as well). I think that that level of culture- and history-loss would be a real shame; I can see however that others may think it more important to make Perl more platform-agnostic in character as well as in implementation. Ben -- 'Deserve [death]? I daresay he did. Many live that deserve death. And some die that deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends.' [EMAIL PROTECTED]
[perl #40373] [PATCH] C coda fix in parrot/config/gen
thanks, applied as r14675. nice work, paul. ~jerry
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes: Fagyal As a side note I also have to add that I really dislike the Fagyal html-functions CGI.pm currently has. Creating the representation is Fagyal the task of the designer, not the programmer. It's almost like echo Fagyal in PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP, Fagyal mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those Fagyal HTML generating methods. To me, imhoit feels wrong that they are Fagyal there/imho. You've never made a sticky form then. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: renaming grep to where
Just a perl 5 physicist here. I had to run to the Camel book to find out that grep existed in the world of perl. But I have done this (from memory): $stuff_in_lines = `grep suntide *.txt`; I never thought about the potential for serious ambiguity in interpretation. The UNIX grep tool is really dissimilar considering that it uses a different regular expression syntax. -- -- Halloween == Oct 31 == Dec 25 == Christmas --
Re: the CGI.pm in Perl 6
Steve == Steve Pitchford [EMAIL PROTECTED] writes:
Steve To be honest I'm not sure I follow your argument. Why does populating a
form
Steve from incoming form data require closer integration
Steve than, say, pulling it out of a database and populating a form for further
Steve editing?.
It's the stickiness, which is a handy feature of error-page generation.
Using the existing CGI.pm, I can say:
print textfied('first_name', 'default value');
and the first_name field will have 'default value' *unless* there's also a
param('first_name'), in which case it'll come from there. Of course, I can
specify override = 1, or even delete the param as needed, if I don't want the
sticky behavior.
To get this to work right, whatever I use for HTML generation needs to know
how to get incoming params. Admittedly, the interface is simple, but it would
have to know if I'm using a functional form with a hidden object (use CGI
qw/param/) or an explicit object (my $q = CGI-new). And if it's an
explicit object, how will the HTML generation find it? This works
even for select-multiple forms, which is very nice.
That's why the *tight* integration of incoming parameters and HTML
form generation is a Good Thing. 90% of the time, it just Works.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
[perl #40374] [PATCH] C coda fix in parrot/include
thanks, applied as r14676. ~jerry
Re: renaming grep to where
On 20 Sep 2006, at 18:41, Doug McNutt wrote: I never thought about the potential for serious ambiguity in interpretation. The UNIX grep tool is really dissimilar considering that it uses a different regular expression syntax. (perl grep doesn't have to be used with an RE of course) I guess there's a fine line between renaming things in Perl 6 because it's possible and because it's desirable. Once you're off the leash of the old language there's a perceived obligation to give everything the name that best represents its purpose - but things inhabit the names they're given. The Beatles probably sounded like a really dumb name for a band once. Is there a serious objection to letting it be? 'select' has POSIX and SQL meaning, 'where' has a SQL meaning, 'grep' has a Unix command connotation - but 'grep' has the benefit that it also has an existing perl connotation. -- Andy Armstrong, hexten.net
[perl #40380] [PATCH] errors on 'make install' - src/pdb.c
# New Ticket Created by Herbert Poul # Please include the string: [perl #40380] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40380 hi, 'make install' failed due to a change in compilers/imcc/parser.h (rev. 14633) which added a second parameter to do_yylex_init: src/pdb.c src/pdb.c: In function `main': src/pdb.c:139: warning: passing arg 1 of `do_yylex_init' from incompatible pointer type src/pdb.c:139: error: too few arguments to function `do_yylex_init' make: *** [src/pdb.o] Error 1 here is a very simple patch which got it working for me: Index: src/pdb.c === --- src/pdb.c (revision 14634) +++ src/pdb.c (working copy) @@ -136,7 +136,7 @@ PDB_t *pdb; void *yyscanner; -do_yylex_init ( yyscanner ); +do_yylex_init ( NULL, yyscanner ); /*Parrot_set_config_hash(); TODO link with cfg */ debugger = Parrot_new(NULL); cu, herbert poul Index: src/pdb.c === --- src/pdb.c (revision 14634) +++ src/pdb.c (working copy) @@ -136,7 +136,7 @@ PDB_t *pdb; void *yyscanner; -do_yylex_init ( yyscanner ); +do_yylex_init ( NULL, yyscanner ); /*Parrot_set_config_hash(); TODO link with cfg */ debugger = Parrot_new(NULL);
Re: call, call(), .call, and captures
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote: : Trey Harris wrote: : Might I propose the following normalization: : : 1. .call, method definition call(), and .wrap call all take captures. : : 2. .call() and both types of call() all pass on the arguments of the :current subroutine. : : 3. To call with no arguments, use .call(\()) and call(\()). : : I have no problem with that, but the original form should probably exist : too. I don't know if that's called invoke or what, but something that : takes an arglist and constructs the capture to pass on would be very : helpful to most users. It would be suboptimal to give something so related a name that is completely unrelated. If we had such a thing it should callv or callargs or some such. But it's not yet clear to me that this is frequent enough to deserve the sugar over call(\(...)). By the way, call() is just short for nextroutine().call() or some such, where nextroutine() is a mystical call that retrieves the next candidate based on what kind of dispatcher we're in. : 4. Introduce some syntax for getting a capture of the current argument :list explicitly. Perhaps $?ARGS or $?_ or $?CAPTURE. One shouldn't :have to choose between repeating your 20 parameters in order to take a :capture of them, and eliminating your nice self-documenting 20 :parameter names so you can use the easy \$arglist trick. : : I like the idea in 4, even though I'm not sure that I follow the rest of : your logic. Having access to a variable that contains the current : argument list called $?ARGS seems to be in line with the rest of the $? : state variables that are provided. Uh, no, $? variables are supposed to be compile-time constants. That's why there's no $?SELF anymore. Since individual constraints within the siglet are considered to be anded, it might be possible to declare both a capture and the rest of the parameters like this:: sub foo (\$args $a, $b, $c) In other words we relax the constraint that \$x has to come at the end, so \$x would just take a snapshot of the rest of the args and keep processing the binding to any remaining parameters. : So, in general, I think the only thing missing is something like invoke : so that: : : invoke(1,2,3); : : is identical to: : : call(\(1,2,3)); : : and: : : invoke([,] =$?ARGS); : : is identical to: : : call($?ARGS); : : is identical to: : : call(); We might prefer a three-way distinction just to avoid user confusion: call; no args allowed, always uses existing parameters callcap($capture) one arg, must be capture (plus named?) callargs($a: $b, $c)same as callcap(\($a: $b, $c)); (plus the corresponding dot forms). Alternately, just keep callargs and force callcap to be written callargs([,] =$capture). After all, if you're going to do anything with the args, you're usually not interested in the whole original capture by itself. What we really need is a unary operator that is sugar for [,](=(...)). Just don't anyone suggest *. :-) Candidates: callargs(`$foo) callargs(_$foo) callargs(|$foo) callargs(¢$foo) Another approach would be to give captures a sigil that autoinserts, and you'd have to \ it to suppress that, much like @foo always interpolates into list context. Then we just get something like callargs(¢x) and the mixed declaration above would be sub foo (¢args $a, $b, $c) : Certainly a distinction on call vs call() is not what Perl 6 programmers : will come to expect from the rest of the language, and I see no pressing : reason to introduce it here. Yes, that would be a mistake. Macros that abuse () are a design smell. Larry
Re: renaming grep to where
On Wed, Sep 20, 2006 at 06:54:11PM +0100, Andy Armstrong wrote: : The Beatles probably sounded like a really dumb name for a band once. : : Is there a serious objection to letting it be? Let it be. :) Larry
Re: renaming grep to where
On 20 Sep 2006, at 19:05, Larry Wall wrote: Let it be. :) I could just as easily have called for a revolution :) -- Andy Armstrong, hexten.net
Re: Trying to make a new operator
Richard Hainsworth [EMAIL PROTECTED] writes:
Thanks for help. For anyone else, the following works.
sub infix:grew_by_to {...};
(32 grew_by_to 48).say;
sub infix:grew_by_to ($left, $right) {
return ($right/$left - 1) * 100 ~ '%';
};
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.
(*) The senior ones of us possibly remember the good old days:
http://www.perl.org/yapc/2002/movies/themovie/
GreetinX
Steffen
--
Steffen Schwigon [EMAIL PROTECTED]
Dresden Perl Mongers http://dresden-pm.org/
Re: call, call(), .call, and captures
Larry Wall wrote:
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote:
: Trey Harris wrote:
: Might I propose the following normalization:
:
: 1. .call, method definition call(), and .wrap call all take captures.
:
: 2. .call() and both types of call() all pass on the arguments of the
:current subroutine.
:
: 3. To call with no arguments, use .call(\()) and call(\()).
:
: I have no problem with that, but the original form should probably exist
: too. I don't know if that's called invoke or what, but something that
: takes an arglist and constructs the capture to pass on would be very
: helpful to most users.
It would be suboptimal to give something so related a name that is
completely unrelated. If we had such a thing it should callv or
callargs or some such. But it's not yet clear to me that this is
frequent enough to deserve the sugar over call(\(...)).
invoke is just a very commonly used name in places like parrot and XS,
so I thought of it right off the bat.
I think your call, callargs and callcap are fine looking things.
As for $?ARGS, you're right, I was forgetting that it's not compile-time
constant.
Would $?ROUTINE have access to its current invocation? In other words,
could $?ROUTINE.args or $?ROUTINE.invocation.args find the current
invocation and ask for its capture? Why do I ask for that when you've
already said that signatures could include a capture? Macros. A macro
might want to do something with its caller's arguments, but doesn't know
what localized name it will have been given. If it can ask for its
$?ROUTINE, then it's always going to work.
macro debug() {
if $*ENVDEBUG {
q:code{
say(DEBUG: , $?ROUTINE.name,
called with: ,
Dumper($?ROUTINE.args))
};
} else {
q:code{1};
}
}
What we really need is a unary operator that is sugar for [,](=(...)). Just
don't anyone suggest *. :-)
I was thinking about that. I wonder if [\] would make sense, or is that
just begging to have in-editor parsers fall over screaming ;)
Other options might be (in decreasing order of my fondness for them):
callargs(-- $foo) -- a nice inverse to -
callargs($\ $foo)-- mnemonic: Dereference this capture
callargs(.* $foo)-- Ok, only to be passive-aggressive ;)
callargs(*\ $foo)-- kind of the same idea as $\
Candidates:
callargs(`$foo)
callargs(_$foo)
callargs(|$foo)
callargs(¢$foo)
None of these LOOK like capture-expansion to me other than _ which I'm
always hesitant to mess with. | seems too confusing.
Another approach would be to give captures a sigil that autoinserts, and
you'd have to \ it to suppress that, much like @foo always interpolates
into list context. Then we just get something like
callargs(¢x)
and the mixed declaration above would be
sub foo (¢args $a, $b, $c)
I've been a Perl programmer for 15 years, so I don't know why adding a
sigil would bother me, but it does... Can't give you a good reason,
though, so perhaps it's moot. Unicode sigils might have a valid ickiness
factor, though. I can't figure out what the ascii form of ¢ would be...
Certainly most expansions involving c and/or | are going to have
ambiguity problems.
Re: renaming grep to where
names they're given. The Beatles probably sounded like a really dumb name for a band once. But maybe less dumb than 'The Quarrymen', which was the original name of the band. (They all went to Quarry Bank school, now Calderstones.) Perhaps the renaming, unfettered by their history or by a desire to not fix what ain't broken, helped them along their way to superstardom. I'm not sure if there is a lesson to be learned here. As I haven't previously spoken on the subject, I'll weigh in to express a slight preference for the name grep, though I like Larry's idea of a generalised 'divvy'. Last year, teaching ML, I taught the definition of the 'filter' function as 'grep', simply because I'd forgotten that it was called 'filter' in ML. Mind you, as it had been a year or two since I'd last used ML, I'd also forgotten a few of the other keywords, a problem I have with other languages too. Do you 'throw' or 'raise' an exception? Do you use 'else if', 'elseif', 'elsif', or 'elif'? I can see how aliases can be a Bad Thing, but when my mind is elsewhere I would appreciate some loan words from other languages. -- And for mile after mile you'll never see me tire/You'll never me me slow down for a while/'Cause I am the fox, like it or not/I'm always gonna be there running over the rock/ Yes I am the fox, a fascinating cross/ Of sharp as a whip and tough as an ox Bernie Taupin, 'The Fox' pgpZ9WSwhrmmN.pgp Description: PGP signature
Capture sigil
Okay, I think this is worth bringing up to the top level. Fact: Captures seem to be turning into a first-class data structure that can represent: argument lists match results XML nodes anything that requires all of $, @, and % bits. Fact: We're currently going through contortions to try to get these to behave when they're stored in a scalar variable: [,] =$capture Fact: This contrasts with the ease with which we can request arrayness and hashness using the @ and % sigils. Conjecture: We need a corresponding sigil to request captureness. As with @ and %, you can store a capture in a $ to hide it, but we don't have the ability to have capture variables that know how to behave like captures without fakey syntactic help. Bikeshed: What should that sigil be? And if it's in Latin-1, what's the ASCII workaround? Latin-1 candiates: ¡ 00A1INVERTED EXCLAMATION MARK ¢ 00A2CENT SIGN £ 00A3POUND SIGN ¤ 00A4CURRENCY SIGN ¥ 00A5YEN SIGN ¦ 00A6BROKEN BAR § 00A7SECTION SIGN ¨ 00A8DIAERESIS © 00A9COPYRIGHT SIGN ª 00AAFEMININE ORDINAL INDICATOR « 00ABLEFT-POINTING DOUBLE ANGLE QUOTATION MARK ¬ 00ACNOT SIGN 00ADSOFT HYPHEN ® 00AEREGISTERED SIGN ¯ 00AFMACRON ° 00B0DEGREE SIGN ± 00B1PLUS-MINUS SIGN ² 00B2SUPERSCRIPT TWO ³ 00B3SUPERSCRIPT THREE ´ 00B4ACUTE ACCENT µ 00B5MICRO SIGN ¶ 00B6PILCROW SIGN The obvious ASCII for ¢ would be c/ or C/ or c| or c| or maybe just |. The obvious ASCII for © would be (c), I suppose. Or instead of going for visual lookalikes, we could go for semantic likenesses. If @@ is multiple arrays, then @% or %@ could be an array mixed with a hash (and a scalar, but let's not go that far). Which leads me to wonder if there's a Latin-1 synonym for @@, like § maybe for sectional, or µ for multidimensional, or ® for, er, repetitious or something. Hmm, then ®©foo could take the multidimensional feeds out of capture foo. Maybe µ¢foo looks better though. Or maybe we could work the € in there somewhere for extra dimensional... ☺ On the other hand, we could just make |foo a capture because it inclusive-ORs several other structures. Main downside is that it looks too much like an ell. That's probably not a showstopper in practice. Much of the time we'd be using it to qualify other variables anyway, so instead of scattering [,] all over the place we would have things like foo(|$foo) foo(|@foo) foo(|%foo) foo(|foo) Visually it kinda works as an insert this here marker too. And most of the places you'd use it wouldn't be using | operators. Another factor is that it kind of resonates visually with the \ that makes captures. Larry
Re: Capture sigil
In a message dated Wed, 20 Sep 2006, Larry Wall writes: The obvious ASCII for ¢ would be c/ or C/ or c| or c| or maybe just |. I like ¢,but: c/$foo # ASCII of ¢$foo d/$foo # d() divided by $foo is rather confusing. (Same goes for |). So the Term Term exclusion makes me rather lean towards |. Whether it's the canonical sigil or the ASCII of ¢ doesn't much matter to me. Trey
Re: Capture sigil
Oops, I hate typos that result in my writing exactly the opposite of what I meant: In a message dated Wed, 20 Sep 2006, Trey Harris writes: In a message dated Wed, 20 Sep 2006, Larry Wall writes: The obvious ASCII for ¢ would be c/ or C/ or c| or c| or maybe just |. I like ¢,but: c/$foo # ASCII of ¢$foo d/$foo # d() divided by $foo is rather confusing. (Same goes for |). Oops, I meant same goes for c|. I like |: So the Term Term exclusion makes me rather lean towards |. Whether it's the canonical sigil or the ASCII of ¢ doesn't much matter to me. Trey
Re: Capture sigil
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
This is quite true, and worth thinking about. Captures are useful beasts.
Fact: We're currently going through contortions to try to get these to behave
when they're stored in a scalar variable: [,] =$capture
Fact: This contrasts with the ease with which we can request arrayness
and hashness using the @ and % sigils.
Consider this the first test of the first-classness of objects in Perl
6. You have an object that's something not entirely unlike:
class Capture { has $.scalar; has @.array; hash %.hash }
I think the addition of a sigil is the wrong way to go for several
reasons, but most important among them is that there are going to be a
lot of scalars that contain objects that are awfully capture-like, and
they'll need whatever semantics we deem appropriate for captures too.
For this reason, I'd suggest putting away the Latin-1 glyphset and
instead focusing on developing operators to act on containers with
multiple access methods and their expanded forms.
First of all, I need a word. I'm going to call an expanded capture a
signature even though that's a bit too metaish. I don't encourage
others to use this term, but it helps me to get my head around this. A
signature is a bit like a list. It has no data type that you can point
to directly. Signatures are also probably lazy like lists.
When we want to turn a capture that is stored in a scalar into a
signature, we need an operator that performs that action, and
unambiguously does NOT perform the action of turning it into a list. I
suggested some in my previous message (such as -- and $\).
Subroutines just so happen to take signatures, so you can invoke them
with one:
foo(-- $capture);
foo($\ $capture);
Now, you need to be able to go in the other direction. You need to be
able to assemble a signature and convert it into a capture. This, we
already have:
$cap = \(-- $othercap, $a, :$b)
$cap = \($\ $othercap, $a, :$b)
This would transform $othercap from a capture to a signature, add in a
positional and a named value and then re-integrate the resulting
signature as a new capture.
Calling subroutines with such a thing looks nice and clean:
$values = \([EMAIL PROTECTED], [EMAIL PROTECTED], $c, :mean1);
$avg1 = avg(-- $values, :undefignore);
$avg2 = avg(-- $values, :undefiszero);
That's as simple as you can get, and we didn't have to promote captures
to a new kind of sigil type to do it.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
* Randal L. Schwartz merlyn@stonehenge.com [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. False dilemma. You can create sticky forms conveniently without using CGI.pm’s HTML generation stuff. You can use HTML::Template, HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on? C’mon merlyn, you’ve been around long enough to know about CPAN and realise that your statement is transparently fallacious. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
* Randal L. Schwartz merlyn@stonehenge.com [2006-09-20 19:30]: To get this to work right, whatever I use for HTML generation needs to know how to get incoming params. Admittedly, the interface is simple, but it would have to know if I'm using a functional form with a hidden object (use CGI qw/param/) Which is seriously awful anyway. Have you read the `self_or_default` sub in CGI.pm? I’d never put such a thing in my own code. CGI::Simple does this correctly – the default interface is OO only, and if you want exports then you use CGI::Simple::Standard. or an explicit object (my $q = CGI-new). And if it's an explicit object, how will the HTML generation find it? This works even for select-multiple forms, which is very nice. Uuuu… maybe you’d just pass the query object to the form generator constructor? You’ve seen HTML::FillInForm and HTML::Template, haven’t you? With roles in P6, you can even make this even simpler. You could make the HTML generator a role which can be composed onto any object that `does ParamQuery`. That's why the *tight* integration of incoming parameters and HTML form generation is a Good Thing. 90% of the time, it just Works. You keep stating this as if it were true despite conclusive evidence to the opposite. I don’t know what you are trying to achieve. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
A. Pagaltzis skribis 2006-09-20 22:01 (+0200): With roles in P6, you can even make this even simpler. You could make the HTML generator a role which can be composed onto any object that `does ParamQuery`. I think it's time we moved away from the param method, and started using a hash. In fact, two hashes, get and post. use Web $web; $web.getfoo; $web.postfoo; $webfoo; # shorthand form for $web.postfoo // $web.getfoo -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Perl6 style-guide
* Fagyal Csongor [EMAIL PROTECTED] [2006-09-20 17:00]: I am afraid that when I will be starting to write Perl6 code, it will be too much Perl5-ish, Even with a style guide, your Perl 6 code will still be Perl-5-ish. And even once it’s not anymore, six months later you will discover that it’s not really Perl-6-ish either. Until you become fluent in the language, your code is going to be less elegant than it could be. A style guide can give you a bag of broad hints for the most obvious things, but fluency is something that comes from practice, and that inevitably takes time. and I will end up rewriting my code in every 3 months because I hate when my code is not elegant (at least to my own standards). That’s an urge that bedevils many a programmer (myself included). Learn to curb it. (I am trying to; I have already gotten much better about it.) “Improving” old code that works and isn’t being developed, purely for the sake of aesthetics, is a waste of time. If you ever need to touch old code again for a particular reason, then you have justification for cleaning it up. But code comes and goes; if you focus on writing your new code better, your body of code will automatically improve over time. Also, don’t sweat the small stuff. When you write a grocery list, you don’t expend a lot of thought on making it worthy of Shakespear either. All this is not to say there shouldn’t be a style guide for Perl 6 or that it wouldn’t help you. There absolutely should be and it certainly would. But don’t be fooled about how much so. Entirely aside from all these points, I think it is a bit early to be writing a Perl 6 style guide. There are a number of features in the language that have never been tried in the wild in this combination, and I expect it will take a year or two at least until the first proper best practices start to crystalise in the community. Any guide written now would be obsolete very soon. That said, a cheatsheet with broad tips for arrivals from Perl 5 could already be written and will age well. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
* Juerd [EMAIL PROTECTED] [2006-09-20 22:25]:
I think it's time we moved away from the param method, and
started using a hash.
I don’t know about that. The `param` method has the nice property
that it allows you to pretend everything’s a single value or to
use multi-valued params, at your own discretion, at any time,
with no change of syntax.
my $foo = $q-param( 'foo' );
my @bar = $q-param( 'bar' );
If you tried to do this with a hash, you’d get
my $foo = $q-param-{ 'foo' }[0];
# my ( $foo ) = @{ $q-param-{ 'foo' } };
my @bar = @{ $q-param-{ 'bar' } };
You could try making the type of the value depend on arity and be
either a scalar or an arrayref, but then you get V*E*R*Y U*G*L*Y
client code that needs to constantly check whether it’s dealing
with one or the other.
Does Perl 6 offer any help in making access to a HoL look like
the first example? If not, then no, let’s please stick with the
`param` protocol.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
OT: Re: Web development I: Web::Toolkit
A. Pagaltzis schrieb: On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). At least without CSS. You can use those tags to create a more semantic markup which can be styled using CSS. Of course there is more than just design. The cite attribute of the blockquote tag isn't supported by any browser AFAIK. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: [PATCH] as2c.pl C-file coda fix
On Wednesday 20 September 2006 09:53, Jerry Gay via RT wrote: thanks, applied as r14673, with a minor fix: -$print_coda(); +print_coda(); I wouldn't mind seeing the '' go away entirely. It's syntactic noise in this case. -- c
Re: [PATCH] as2c.pl C-file coda fix
On 9/20/06, chromatic [EMAIL PROTECTED] wrote: On Wednesday 20 September 2006 09:53, Jerry Gay via RT wrote: thanks, applied as r14673, with a minor fix: -$print_coda(); +print_coda(); I wouldn't mind seeing the '' go away entirely. It's syntactic noise in this case. you're right, of course. fixed, with other style nits, r14678. ~jerry
Re: Capture sigil
On 9/20/06, Larry Wall [EMAIL PROTECTED] wrote: Conjecture: We need a corresponding sigil to request captureness. As with @ and %, you can store a capture in a $ to hide it, but we don't have the ability to have capture variables that know how to behave like captures without fakey syntactic help. Once upon a time I had an unproposed proposal that the thing that distinguished @ from $ is that @ auto-flattens. So perhaps captures as well as arrays can be stored in @-variables, if you define flattening as the [,] operator. The reason I didn't propose it is because I couldn't figure out what to do with %. Luke
Re: Perl6 style-guide
Aristotle (): That said, a cheatsheet with broad tips for arrivals from Perl 5 could already be written and will age well. Oh, have a look at docs/other/porting_howto in the pugs svn tree. If nothing else, it's a good starting point. http://svn.openfoundry.org/pugs/docs/other/porting_howto -- masak
[perl #40379] [TODO] investigate use of tools/dev/as2c.pl
The plan behind of as2c.pl is and was to create compiler independant machine code for an architecture. masm, gas, nasm, whatever syntax doesn't fit all compilers. Therefore as2c.pl translates gas syntax to a bytestring, which is then used as the asm code. as2c's usage is indeed scarce: when the code is generated once and checked in, there's usually no need to change it later. leo
Re: Capture sigil
On Wed, Sep 20, 2006 at 12:28:10PM -0700, Larry Wall wrote: Bikeshed: What should that sigil be? And if it's in Latin-1, what's the ASCII workaround? The one that springs out to me is: ¤ 00A4CURRENCY SIGN Probably because it looks like a container with something captured inside it, or trying to break out, and because we use currency to pass value(s) between individuals. I don't have an ASCII suggestion. -kolibrie
Re: the CGI.pm in Perl 6
A. Pagaltzis skribis 2006-09-20 22:39 (+0200):
* Juerd [EMAIL PROTECTED] [2006-09-20 22:25]:
I think it's time we moved away from the param method, and
started using a hash.
I don???t know about that. The `param` method has the nice property
that it allows you to pretend everything???s a single value or to
use multi-valued params, at your own discretion, at any time,
with no change of syntax.
Thinking that one variable has only one interface is *so* Perl 5 :)
my $foo = $q-param( 'foo' );
my @bar = $q-param( 'bar' );
If you tried to do this with a hash, you???d get
my $foo = $q-param-{ 'foo' }[0];
# my ( $foo ) = @{ $q-param-{ 'foo' } };
my @bar = @{ $q-param-{ 'bar' } };
In Perl 5, yes.
But in Perl 6:
my $foo = $webfoo;
say $foo;
say $foo[1]; # heck, why not.
my @foo = $webfoo;
say @foo[1];
All we need is a very simple type that does both Str and Array. We can
handle this, *easily*.
And I wouldn't want the nullbyte mistake again. Let's just stick to the
last given value instead.
Also, I want parameters to be able to do a certain Upload role, which
adds terribly useful methods for file uploads. Let's escape the
primitive world and add some REAL dwimmery, the kind that doesn't
confuse people all the time :)
Does Perl 6 offer any help in making access to a HoL look like
the first example?
No, but it does offer help to make it look a whole lot nicer than that.
:)
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
PS
Note that your code, if literally translated to Perl 6, is already
nicer:
my $foo = $q-param-{ 'foo' }[0];
my $foo = $q.paramfoo[0];
my @bar = @{ $q-param-{ 'bar' } };
my @bar = $q.parambar.'@';
my @bar = @ $q.parambar;
Re: Perl6 style-guide
A. Pagaltzis skribis 2006-09-20 22:29 (+0200): * Fagyal Csongor [EMAIL PROTECTED] [2006-09-20 17:00]: I am afraid that when I will be starting to write Perl6 code, it will be too much Perl5-ish, Even with a style guide, your Perl 6 code will still be Perl-5-ish. And even once it???s not anymore, six months later you will discover that it???s not really Perl-6-ish either. Until you become fluent in the language, your code is going to be less elegant than it could be. A style guide can give you a bag of broad hints for the most obvious things, but fluency is something that comes from practice, and that inevitably takes time. I've been thinking in Perl 6 terms for quite a while now, and while Pugs hasn't implemented enough to bring life to all my ideas, I do notice that there is a sharp distinction between Perl 5-ishness and Perl 6-ishness. A good example is the way you thought about param's dual function in terms of arity/context, while my first thought nowadays is to use a type that simply implements two kinds of access. With all due respect, I already consider the former old fashioned :) A style guide is very hard to write. It indeed boils down to fluency. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Perl6 style-guide
At 4:56 PM +0200 9/20/06, Fagyal Csongor wrote: I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. I have found that Damian's Perl Best Practices still works very well for Perl 6 code, so I still apply that where reasonably possible. And in fact, I expect that PBP was written to be forward compatible to Perl 6, as it could describe styles that should be natural in Perl 6, even if less so in Perl 5. -- Darren Duncan
Re: Perl6 style-guide
On Wed, Sep 20, 2006 at 04:16:32PM -0700, Darren Duncan wrote: : And in fact, I expect that PBP was written to be forward compatible : to Perl 6, as it could describe styles that should be natural in Perl : 6, even if less so in Perl 5. Indeed, I know for a fact that it was. (Though the treatment of /m ends up making ^ and $ mean the wrong thing from a P6 point of view.) Larry
Re: the CGI.pm in Perl 6
* Juerd [EMAIL PROTECTED] [2006-09-21 00:45]: And I wouldn't want the nullbyte mistake again. Let's just stick to the last given value instead. Nobrainer. The nullbyte thing was a Perl-4-ism. Also, I want parameters to be able to do a certain Upload role, which adds terribly useful methods for file uploads. Let's escape the primitive world and add some REAL dwimmery, the kind that doesn't confuse people all the time :) But let’s also be careful not to go *too* overboard with the new stuff. Last time someone was all gung-ho to use new features to make things more automagical, we got [EMAIL PROTECTED] = qw( Exporter );`. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Perl6 style-guide
* Juerd [EMAIL PROTECTED] [2006-09-21 00:50]: I've been thinking in Perl 6 terms for quite a while now, I won’t dismiss this claim, but the [EMAIL PROTECTED] = qw( Exporter );` example I mentioned in the other mail cautions me from believing that anyone is particularly fluent with Perl 6 quite yet. Learning to use the new stuff is not the problem; learning how not to overuse will be. Good design is about restraint. There’s a bit of a road ahead. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Web development I: Web::Toolkit
On 9/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Aankhen [EMAIL PROTECTED] [2006-09-17 21:00]: XHTML 1.0 and 1.1 offer no practical benefits over HTML, but tangible disadvantages. To be fair, XHTML does let you embed MathML and SVG (as well as XForms, pending browser support) in your markup, which is a great boon where applicable. But that's the only benefit XHTML provides as of yet. Not XHTML 1.0 and XHTML 1.1... there you need to use the compound document types, e.g. XHTML + SVG + MathML. Since we're being fair, XHTML 1.1 also offers specific elements for Ruby[1]. If the XHTML produced by the module adheres to the W3C standard, there won't be any elements that only work in certain browsers (with the exception of abbr... no others I can think of offhand). Plenty. IE6 doesn't understand `q`, off the top of my head. I know there are several more, plus a few that *no* browser supports. On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). IE doesn't render q correctly, but the content of the element is still available. As far as the attributes go, that's a UI problem with the browsers. :-) Come to think of it, as long as those attributes show up in the DOM correctly, I don't see how you could not support them. Perhaps we could say no *useful* browser support? [1] http://www.w3.org/TR/2001/REC-ruby-20010531/ Aankhen
Re: Web development I: Web::Toolkit
* Aankhen [EMAIL PROTECTED] [2006-09-21 03:15]: On 9/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). as long as those attributes show up in the DOM correctly, I don't see how you could not support them. Perhaps we could say no *useful* browser support? I did qualify my statement. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On 9/20/06, Fagyal Csongor [EMAIL PROTECTED] wrote: And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. If those are modules to generate markup, I don't see why they should under the Web namespace. There needs to be a Web.pm toolkit (or something similar), but that's mostly an amalgamation of other modules. Aankhen
Re: Web development I: Web::Toolkit
On 9/20/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I did qualify my statement. I'm sorry, I must have missed it. :-) Aankhen
Re: the CGI.pm in Perl 6
On Thu, Sep 21, 2006 at 12:43:41AM +0200, Juerd wrote:
: my @bar = @{ $q-param-{ 'bar' } };
:
: my @bar = $q.parambar.'@';
: my @bar = @ $q.parambar;
That should work but my preference is just
my @bar = $q.parambar[];
That is, empty .[] has the same arrayifying semantics as @. (This is
currently b0rken in pugs though.) Likewise .{} is equivalen to %.
Larry
Re: Capture sigil
On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote:
: Consider this the first test of the first-classness of objects in Perl
: 6. You have an object that's something not entirely unlike:
:
: class Capture { has $.scalar; has @.array; hash %.hash }
:
: I think the addition of a sigil is the wrong way to go for several
: reasons, but most important among them is that there are going to be a
: lot of scalars that contain objects that are awfully capture-like, and
: they'll need whatever semantics we deem appropriate for captures too.
I don't see how that follows. There will be lots of objects containing
lots of things that don't give a rip about having a capture interface.
: For this reason, I'd suggest putting away the Latin-1 glyphset and
: instead focusing on developing operators to act on containers with
: multiple access methods and their expanded forms.
There's already going to be such an operator, and it probably won't be
Latin-1. The only question in my mind is whether it's also a sigil.
: First of all, I need a word. I'm going to call an expanded capture a
: signature even though that's a bit too metaish. I don't encourage
: others to use this term, but it helps me to get my head around this.
That's not a good choice of term, since signatures already mean something
else entirely in Perl 6.
: A signature is a bit like a list. It has no data type that you can point
: to directly. Signatures are also probably lazy like lists.
What you're calling a signature is in fact just another capture in our
terminology.
: When we want to turn a capture that is stored in a scalar into a
: signature, we need an operator that performs that action, and
: unambiguously does NOT perform the action of turning it into a list. I
: suggested some in my previous message (such as -- and $\).
The Style Police have rated those as slightly less ugly than [,]=.
: Subroutines just so happen to take signatures, so you can invoke them
: with one:
:
: foo(-- $capture);
: foo($\ $capture);
That's foo(|$capture) now.
: Now, you need to be able to go in the other direction. You need to be
: able to assemble a signature and convert it into a capture. This, we
: already have:
:
: $cap = \(-- $othercap, $a, :$b)
: $cap = \($\ $othercap, $a, :$b)
:
: This would transform $othercap from a capture to a signature, add in a
: positional and a named value and then re-integrate the resulting
: signature as a new capture.
In my current thinking that's just \( |$othercap, $a, :$b ).
: Calling subroutines with such a thing looks nice and clean:
:
: $values = \([EMAIL PROTECTED], [EMAIL PROTECTED], $c, :mean1);
: $avg1 = avg(-- $values, :undefignore);
: $avg2 = avg(-- $values, :undefiszero);
:
: That's as simple as you can get, and we didn't have to promote captures
: to a new kind of sigil type to do it.
I think | is a lot nice-and-cleaner and simpler than --. And it
can also work as a sigil.
Larry
Re: Capture sigil
Larry Wall writes: Conjecture: We need a corresponding sigil to request captureness. As Bikeshed: What should that sigil be? What's * doing these days? Smylers
Re: Capture sigil
On Thu, Sep 21, 2006 at 12:45:46AM +0100, Smylers wrote: : Larry Wall writes: : : Conjecture: We need a corresponding sigil to request captureness. As : Bikeshed: What should that sigil be? : : What's * doing these days? Thought a lot about that one, but I think it's more useful in 0..* and such. Unfortunately the whatever use of * can't take unary argument or we fail to parse things like 0..*:by(2) correctly. Besides, people would accuse us of reintroducing typeglobs. :-) Which they aren't quite, but they're similar enough that a P5 person would think of *foo as a typeglob and be thoroughly confused. Oh, and we'd also have to rethink our use of * as a shorthand for GLOBAL::. Larry
Re: renaming grep to where
On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote: On 20 Sep 2006, at 19:05, Larry Wall wrote: Let it be. :) I could just as easily have called for a revolution :) No, you should have quoted differently: On 20 Sep 2006, at 19:05, Larry Wall whispered words of wisdom: Let it be. :) --
Re: renaming grep to where
On Wed, Sep 20, 2006 at 11:44:49PM -0400, John Macdonald wrote:
: On Wed, Sep 20, 2006 at 07:11:42PM +0100, Andy Armstrong wrote:
: On 20 Sep 2006, at 19:05, Larry Wall wrote:
: Let it be. :)
:
: I could just as easily have called for a revolution :)
:
: No, you should have quoted differently:
:
: On 20 Sep 2006, at 19:05, Larry Wall whispered words of wisdom:
: Let it be. :)
my Yellow sub marine { @we.all.live }
Larry
Re: Capture sigil
Larry Wall wrote: On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote: : For this reason, I'd suggest putting away the Latin-1 glyphset and : instead focusing on developing operators to act on containers with : multiple access methods and their expanded forms. There's already going to be such an operator, and it probably won't be Latin-1. The only question in my mind is whether it's also a sigil. Well, that sounds reasonable enough. Let me take the last point, then, which I'm only slightly convinced I have a good answer for: They just don't seem important enough to pump out another sigil for. Filehandles are FAR more valuable and potentially semantically rich, so I would expect them to get their own sigil long before captures. If captures have an expand-o-op, then I think they have everything they need to be on-par with features like filehandles. : When we want to turn a capture that is stored in a scalar into a : signature, we need an operator that performs that action, and : unambiguously does NOT perform the action of turning it into a list. I : suggested some in my previous message (such as -- and $\). The Style Police have rated those as slightly less ugly than [,]=. My problem with [,]= is not that it's ugly (it is, a bit), but that it's two operations which are both being slightly bent out of shape for their use here. I do agree that capture expansion is something which demands its own op. : Subroutines just so happen to take signatures, so you can invoke them : with one: : : foo(-- $capture); : foo($\ $capture); That's foo(|$capture) now. Hrm... ugly is one thing, but visual ambiguity is another. With an operator like -- one can use or discard the parens at will. However, with | there is no alternative, since: x |$y could be a programmer trying to say: x() | $y I cry for a Q/A group every time I see that kind of thing go into Perl 6. It's especially unfortunate because there might be a fair amount of value to coercing simple types into captures, but we don't want to in this case, so that we can catch such errors. ... In my current thinking that's just \( |$othercap, $a, :$b ). Yep, if |$ is the capture sigil (making | the sigil prefix op) then this is a fairly obvious extrapolation from your previous messages. : Calling subroutines with such a thing looks nice and clean: : : $values = \([EMAIL PROTECTED], [EMAIL PROTECTED], $c, :mean1); : $avg1 = avg(-- $values, :undefignore); : $avg2 = avg(-- $values, :undefiszero); : : That's as simple as you can get, and we didn't have to promote captures : to a new kind of sigil type to do it. I think | is a lot nice-and-cleaner and simpler than --. And it can also work as a sigil. Keep in mind that, while -- is my strongest current idea, I'm more advocating the non-ambiguous, non-sigil idea, and not championing any particular implementation of that idea. One reason that I liked -- was for the fact that it looks like -- which defines return type inside of a signature. Though it's not clear to me if knowlege of expected return type is wrapped up in a capture. If so, then perhaps this is how you re-dispatch with a forced/overridden context: callargs(-- $args --Int); Though I admit that's going to catch HTML/XML programmers off-guard ;)
Re: Capture sigil
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
Fact: We're currently going through contortions to try to get these to behave
when they're stored in a scalar variable: [,] =$capture
Fact: This contrasts with the ease with which we can request arrayness
and hashness using the @ and % sigils.
Conjecture: We need a corresponding sigil to request captureness.
As with @ and %, you can store a capture in a $ to hide it, but we
don't have the ability to have capture variables that know how to
behave like captures without fakey syntactic help.
Let me see if I'm following you correctly:
¤args = \(1,2,3,:miceblind)
Is the backslash still neccessary, or is the use of the Capture sigil
enough to indicate that the rvalue should be treated as a capture
object?
$¤args; # would this return 1 or an indication that
nothing's there?
@¤args; # would this return [1, 2, 3], or [2, 3]?
%¤args; # this would return { mice - 'blind' }
Would '¤¤args' mean anything?
Does '¤args' mean anything?
(I like '¤' for capture objects, because it reminds me of '*', and
capture objects remind me of Perl 5's typeglobs. Perhaps the ASCII
workaround could be '**'?)
'$¤args' would mean retrieve the scalar portion of the capture object
'args'; '¤$args' would mean treat the scalar object 'args' as if it
were a capture object. Right? (And what, precisely, is meant by
treating a scalar as if it were a capture object?)
Which leads me to wonder if there's a Latin-1 synonym for @@, like §
maybe for sectional, or µ for multidimensional, or (r) for, er, repetitious
or something.
Of these, I like the idea of § for Latin-1 equivalent of @@. Not only
does it have the meaning of section, but it registers in my brain as
this looks sigilish - perhaps due to its vague visual resemblance to
the dollar sign (oddly enough, ¢ doesn't look sigilish to me; I don't
know why not, but it doesn't). Do this, and the sigil set becomes:
$ scalar
@ ordered array
§ multislice view of @ (ASCII alias: @@)
% unordered hash, i.e. associative array
¤ capture object (ASCII alias: **)
code/rule/token/regex
:: package/module/class/role/subset/enum/type/grammar
Hmm, then (r)(c)foo could take the multidimensional feeds out of capture
foo. Maybe µ¢foo looks better though. Or maybe we could work
the € in there somewhere for extra dimensional... ☺
Ack! I beg you; stop the line noise!
On the other hand, we could just make |foo a capture because it
inclusive-ORs several other structures. Main downside is that it looks
too much like an ell. That's probably not a showstopper in practice.
Much of the time we'd be using it to qualify other variables anyway, so
instead of scattering [,] all over the place we would have things like
foo(|$foo)
foo(|@foo)
foo(|%foo)
foo(|foo)
I'm lost. What would '|@foo' mean?
Visually it kinda works as an insert this here marker too. And most
of the places you'd use it wouldn't be using | operators. Another factor
is that it kind of resonates visually with the \ that makes captures.
Please remind me: what does perl 6 do with '$(...)' and '@(...)'? And
oughtn't it do something analogous with '|(...)', '¤(...)', or
whatever the capture sigil turns out to be? Would that differ from
'\(...)'?
--
Jonathan Dataweaver Lang
[svn:perl6-synopsis] r12284 - doc/trunk/design/syn
Author: larry Date: Wed Sep 20 22:07:47 2006 New Revision: 12284 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S03.pod doc/trunk/design/syn/S06.pod doc/trunk/design/syn/S12.pod Log: The | sigil and operator. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podWed Sep 20 22:07:47 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 18 Sept 2006 + Last Modified: 20 Sept 2006 Number: 2 - Version: 69 + Version: 70 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -670,6 +670,7 @@ @ ordered array % unordered hash (associative array) code/rule/token/regex +| capture/arguments/match :: package/module/class/role/subset/enum/type/grammar @@ multislice view of @ @@ -817,15 +818,22 @@ $$args; # same as $args as Scalar or Scalar($args) @$args; # same as $args as Array or Array($args) %$args; # same as $args as Hash or Hash($args) +|$args; # all of the above When cast into an array, you can access all the positional arguments; into a hash, all named arguments; into a scalar, its invocant. +When stored in a variable using the C| sigil, the capture autointerpolates +into argument lists much like C@ autoflattens into lists: + +|args := \($a, @b, :option($c)); +somefunc(|args); # same as somefunc($a, @b, :option($c)) + All prefix sigil operators accept one positional argument, evaluated in scalar context as a rvalue. They can interpolate in strings if called with parentheses. The special syntax form C$() translates into C$( $/ ) to operate on the current match object; the same applies to C@(), C%() and -C*() forms. +C|() forms. CCapture objects fill the ecological niche of references in Perl 6. You can think of them as fat references, that is, references that Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podWed Sep 20 22:07:47 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 16 Sep 2006 + Last Modified: 20 Sept 2006 Number: 3 - Version: 66 + Version: 67 =head1 Changes to Perl 5 operators @@ -65,7 +65,8 @@ argument, and C+ imposes a numeric (CNum) context (as opposed to being a no-op in Perl 5). Along the same lines, C? imposes a boolean (CBool) context, and the C[,] list operator imposes -a function-arguments (CCapture) context on its arguments. +a function-arguments (CCapture) context on its arguments (as does +the C| sigil when used as an operator). Unary sigils impose the container context implied by their sigil. As with Perl 5, however, C$$foo[bar] parses as C( $($foo) )[bar], so you need C$($foo[bar]) to mean the other way. @@ -1295,11 +1296,14 @@ interpolator, by casting its operands to CCapture objects and inserting them into the current argument list. -It can be used to interpolate an CArray or CHash into the current -call, as positional and named arguments respectively. +The C| capture sigil may also be used for this when you want to +interpolate a single item. + +Either of these can be used to interpolate an CArray or CHash +into the current call, as positional and named arguments respectively. Note that those arguments still must comply with the subroutine's -signature, but the presence of C[,] defers that test until run time for +signature, but the presence of C| or C[,] defers that test until run time for that argument (and for any subsequent arguments): my @args = [EMAIL PROTECTED], @bar; @@ -1312,7 +1316,16 @@ as is this: my $args = \(@foo, @bar);# construct a Capture object -push [,] @$args; +push |$args; + +The C| sigil functions as a unary form of the C[,] +list operator, so we could have written the earlier example as: + +my @args = [EMAIL PROTECTED], @bar; +push |@args; + +To the extent possible, the C| will treat its argument as +a CCapture even if it isn't. In list context, a CScalar holding an CArray object does not flatten. Hence @@ -1320,15 +1333,16 @@ push @foo, $bar; merely pushes a single CArray object onto C@foo. You can -explicitly flatten it in either of these ways: +explicitly flatten it in one of these ways: push @foo, @$bar; push @foo, $bar[]; +push @foo, |$bar; -Those two forms work because the slurpy array in Cpush's signature +Those three forms work because the slurpy array in Cpush's signature flattens the CArray object into a list argument. -Note that those two forms also allow you to specify list context on +Note that
