typo in HTTP::Server::Simple
I was playing around with HTTP::Server::Simple in pugs and I noticed
that the port number reported at startup isn't correct if a
non-default port is used. Teeny little patch attached!
Regards,
-zack
Index: ext/HTTP-Server-Simple/lib/HTTP/Server/Simple.pm
===
--- ext/HTTP-Server-Simple/lib/HTTP/Server/Simple.pm (revision 13245)
+++ ext/HTTP-Server-Simple/lib/HTTP/Server/Simple.pm (working copy)
@@ -113,7 +113,7 @@
method run {
$.socket = $.port.listen;
-say You can connect to http://localhost:8080;;
+say You can connect to http://localhost:$.port;;
loop {
my %env = %*ENV;
$.remote = $.socket.accept;
Re: typo in HTTP::Server::Simple
Zack (): I was playing around with HTTP::Server::Simple in pugs and I noticed that the port number reported at startup isn't correct if a non-default port is used. Teeny little patch attached! Thanks, applied. -- masak
assigning to named parameters
I was looking over an example of named parameter passing: foo(:a1, :b2) And had the thought that we might be able to get away with treating named parameters as lvalues, making the above: foo(:a=1, :b=2) Would this be unreasonable? Does it break anything else? I'm not sure that subscripting-like notation would be a bad thing to have, but if we could assign an arbitrary expression to a name parameter, I think subroutine and method calls would be a heck of a lot more like their own documentation. It also makes things like this easier to write: arc(:radians=pi); If you use this syntax for something that would be auto-quoted, it's one extra character: add_user(:username=ajs); but later edits are less complicated: add_user(:username=ajs-1); Thoughts? Is it too late?
Re: META vs meta
Jonathan Scott Duff wrote:
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote:
Larry Wall wrote:
.META is more correct at the moment.
Does making it all upper caps really help? It's still a pollution of the
method space, any way that you look at it...
Yeah but perl has already has a cultural claim on ALLCAPS thingys.
So, yes, it does help.
Is the goal to avoid namespace pollution? If so, shouldn't there be a
truly metaish way of getting at the internal namespace so that someone
doesn't accidentally render an object unusable by defining the wrong
method name (which you can prevent with an error if the object is
defined in Perl, but not if it's defined in Parrot or another language)?
Imagine this code:
class HTML4::Elements {
method H1 {...}
method P {...}
method META {...}
...
}
Worse, imagine accessing it through a Ruby or Python object. How would
you say, this object has a real .META, please invoke it? WHERE is even
stickier, since its use as an SQL keyword (case insensitive) makes
conflicts much more likely, and problematic.
There are dozens of ways that we could be explicit about digging into
internal namespace. Some would be syntactic:
$object\.meta (or \.how)
$object.*meta (or .*how)
Some would involve specifying the starting-point for dispatch:
$object.::meta (or .::how)
$object.Object::meta (or .Object::how)
I can think of more, and, I'm sure I'm incapable of thinking of all of
them. Simply spelling things strangely in order to avoid namespace
collisions ignores the fact that the current need is not unique, and any
solution you present should work well across objects from any language
source.
It should also probably be very clear when you are talking to the object
system vs. when you are talking to an object. $foo.META (or .HOW)
doesn't really make that as clear as I think it should be for code clarity.
Of course, you'll probably want to have a way to re-define the object
system itself, so you need to be able to say something like:
class X { method *meta($self:) { $self.MyOO::meta }
or
class X { method meta() is internal {...} }
IMHO, the golden rule of programming languages should be: if you need a
namespace, create one.
[svn:perl6-synopsis] r11980 - doc/trunk/design/syn
Author: larry
Date: Thu Sep 14 09:28:33 2006
New Revision: 11980
Modified:
doc/trunk/design/syn/S12.pod
Log:
Added .'foo' and .bar forms to address various concerns of ajs++ and #perl6++
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podThu Sep 14 09:28:33 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 27 Oct 2004
- Last Modified: 13 Sept 2006
+ Last Modified: 14 Sept 2006
Number: 12
- Version: 24
+ Version: 25
=head1 Overview
@@ -217,6 +217,20 @@
$obj.$methodname(1,2,3)
+The method name may also be quoted with either single or double quotes:
+
+$obj.$methodname(1,2,3) # same as previous
+$obj.'$methodname'(1,2,3) # call method with $ in name!
+
+The latter is especially useful for postfix forms that might be confusing
+to the lexer or to the human reader
+
+$filename.'-e' # same as -e $filename.
+.'-e' # same as -e $_
+
+(The Cq forms of quoting are not allowed, however, since they'd be
+taken as ordinary method names.)
+
You must use a special syntax to call a private method:
$mybrain!think($pinky)
@@ -311,7 +325,9 @@
if $scalar.VAR.readonly {...}
-(But since it's a macro, CVAR is not dispatched as a real method.)
+(But since it's a macro, CVAR is not dispatched as a real method.
+To dispatch to a real C.VAR method use the indirect C$obj.VAR
+form.)
You can also get at the container through the appropriate symbol table:
@@ -558,6 +574,11 @@
$object.*meth(@args) # calls all methods (0 or more)
$object.+meth(@args) # calls all methods (1 or more)
+The method name may be quoted when disambiguation is needed:
+
+$object.+meth(@args)
+$object.'VAR'(@args)
+
Any method can defer to the next candidate method in the list by
saying Cnext METHOD. Any method can stop the progression by saying
Clast METHOD. The order and selection of the candidates may be
@@ -1512,6 +1533,22 @@
$obj.WHAT # method form of P5's ref
WHAT $obj # unary form of P5's ref
+These are all actually macros, not true operators or methods. If you get
+a foreign object from another language and need to call its C.WHERE method,
+you can say:
+
+$obj.WHERE
+
+And if you don't know the method name in advance, you'd be using the
+variable form anyway:
+
+$obj.$somemeth
+
+which also bypasses the macros.
+
+For now Perl 6 reserves the right to change how all these macros and the
+corresponding C^ forms are defined in terms of each other.
+
In general, use of these in ordinary code should be a red flag that
Something Very Strange is going on. (Hence the allcaps.) Most code
should use Perl 6's operators that make use of this information
[svn:perl6-synopsis] r11981 - doc/trunk/design/syn
Author: larry Date: Thu Sep 14 09:40:13 2006 New Revision: 11981 Modified: doc/trunk/design/syn/S03.pod Log: Now make use of .'op' to force prefix interpretation of op, removing bad dwim Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Sep 14 09:40:13 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 13 Sep 2006 + Last Modified: 14 Sep 2006 Number: 3 - Version: 63 + Version: 64 =head1 Changes to Perl 5 operators @@ -37,12 +37,15 @@ =item * All postfix operators that do not start with a dot also have an alternate form that does. (The converse does not hold--just because -you can write Cx().foo doesn't mean you can write Cx()foo.) In the -absence of a postfix interpretation, the dot form will call the corresponding -prefix operator instead. So Cx().! will call C!x() unless someone -defines a postfix C! operator. In particular, you can say things like -C$array.@ and C$filename.-e.-r, but you can't say C$fh.= because -there's a C.= operator already. +you can write Cx().foo doesn't mean you can write Cx()foo. Likewise +the ability to say C$x.'foo' does not imply that C$x'foo' will work.) + +The postfix interpretation of an operator may be overridden by +use of a quoted method call, which calls the prefix form instead. +So Cx().! is always the postfix operator, but Cx().'!' will always +call C!x(). In particular, you can say things like C$array.'@' and +C$filename.'-e'.'-r'. You may even say things like C$fh.'=', which +because of the quotes will not be confused lexically with C$fh.=new. =item * Unary C~ now imposes a string (CStr) context on its argument, and C+ imposes a numeric (CNum) context (as opposed
[svn:perl6-synopsis] r11982 - doc/trunk/design/syn
Author: larry
Date: Thu Sep 14 10:03:33 2006
New Revision: 11982
Modified:
doc/trunk/design/syn/S12.pod
Log:
clarfications of .$op indirection
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podThu Sep 14 10:03:33 2006
@@ -14,7 +14,7 @@
Date: 27 Oct 2004
Last Modified: 14 Sept 2006
Number: 12
- Version: 25
+ Version: 26
=head1 Overview
@@ -223,13 +223,24 @@
$obj.'$methodname'(1,2,3) # call method with $ in name!
The latter is especially useful for postfix forms that might be confusing
-to the lexer or to the human reader
+to the lexer or to the human reader:
$filename.'-e' # same as -e $filename.
.'-e' # same as -e $_
-(The Cq forms of quoting are not allowed, however, since they'd be
-taken as ordinary method names.)
+And in fact, if there is a choice between a unary prefix and a postfix
+operator, the indirect forms will choose the prefix operator. See S03.
+Likewise, presuming that C$op does not name an ordinary method on
+C$left, this calls any arbitrary infix operator:
+
+$left.$op($right)
+
+Of course you can force that with:
+
+$left.infix:{$op}($right)
+
+The Cq forms of quoting are not allowed for method indirection,
+since they'd be taken as ordinary method names.
You must use a special syntax to call a private method:
Re: META vs meta
Aaron Sherman wrote: replies snipped / Is the goal to avoid namespace pollution? If so, shouldn't there be a truly metaish way of getting at the internal namespace so that someone doesn't accidentally render an object unusable by defining the wrong method name (which you can prevent with an error if the object is defined in Perl, but not if it's defined in Parrot or another language)? Imagine this code: code snipped / IMHO, the golden rule of programming languages should be: if you need a namespace, create one. IANAL (Linguist? Language-designer? Larry?), but... Is there any reason these meta methods could not be part of some default function package like Math::Basic and Math::Trig? The package could be called Class::InterrogativePronouns, or Object::MetaModel, or ProgrammingLanguage::Pollution. And it could be loaded by default. Or not. That decision is far above my paygrade. I know the names I proposed are silly, but the idea is worth thought, and it would obey Aaron's golden rule, above. It might also make it a little more obvious to new folks like me where other kinds of introspection (I really can imagine WHENCE and WHITHER being useful) would be added in down the road. Does anyone else have thoughts on this they'd be willing to share? Best, -db.
[svn:perl6-synopsis] r11983 - doc/trunk/design/syn
Author: larry Date: Thu Sep 14 17:22:14 2006 New Revision: 11983 Modified: doc/trunk/design/syn/S01.pod Log: Added a bit of overview of the project plan. ['bout time!] Modified: doc/trunk/design/syn/S01.pod == --- doc/trunk/design/syn/S01.pod(original) +++ doc/trunk/design/syn/S01.podThu Sep 14 17:22:14 2006 @@ -10,19 +10,51 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 24 Oct 2005 + Last Modified: 14 Sept 2005 Number: 1 - Version: 3 + Version: 4 -This document summarizes Apocalypse 1, which covers the initial -design concept. (These Synopses also contain updates to reflect -the evolving design of Perl 6 over time, unlike the Apocalypses, -which are frozen in time as historical documents. These updates are -not marked--if a Synopsis disagrees with its Apocalypse, assume the -Synopsis is correct.) - -The other basic assumption is that if we don't talk about something in these -Synopses, it's the same as it was in Perl 5. +This document originally summarized Apocalypse 1, which covers the +initial design concept. That original summary may be found below +under Random Thoughts. However, these Synopses also contain +updates to reflect the evolving design of Perl 6 over time, unlike +the Apocalypses, which are frozen in time as historical documents. +These updates are not marked--if a Synopsis disagrees with its +Apocalypse, assume the Synopsis is correct. + +Another assumption has been that if we don't talk about something in these +Synopses, it's the same as it is in Perl 5. Soon we plan to fill in +the gaps with the Perl 5 details though. + +=head1 Project Plan + +Mostly, we're just a bunch ants all cooperating (sort of) to haul +food toward the nest (on average). There are many groups of poeple +working on various bits and pieces as they see fit, since this is +primarily a volunteer effort. + +This document does not attempt to summarize all these subprojects--see +the various websites for Parrot and Pugs and Perl 6 for such +information. What we can say here is that, unlike how it was with +Perl 5, none of these projects is designed to be the Official Perl. +Perl 6 is anything that passes the official test suite. This test +suite was initially developed under the Pugs project because that +project is the furthest along in exploring the high-level semantics +of Perl 6. (Other projects are better at other things, such as speed +or interoperability.) However, the Pugs project views the test suite +as community property, and is working towards platform neutrality, +so that Perl 6 is defined primarily by its desired semantics, not by +accidents of history. + +Another aspect of this is the Perl 6 compiler will be self-hosting. +That is, the compiler will eventually compile itself, at least down +to the point where various code-generating backends can take over. +This largely removes platform dependencies from the frontend, so that +only the backends need to worry about platform-specific issues. + +But above all, our project plan is simply to help people find a +spot where they can feel like they're creating the future, both for +themselves and for others. Around here, that's what we call fun. =head1 Random Thoughts
[svn:perl6-synopsis] r11984 - doc/trunk/design/syn
Author: larry Date: Thu Sep 14 17:29:26 2006 New Revision: 11984 Modified: doc/trunk/design/syn/S01.pod Log: type from TreyHarris++ Modified: doc/trunk/design/syn/S01.pod == --- doc/trunk/design/syn/S01.pod(original) +++ doc/trunk/design/syn/S01.podThu Sep 14 17:29:26 2006 @@ -28,7 +28,7 @@ =head1 Project Plan -Mostly, we're just a bunch ants all cooperating (sort of) to haul +Mostly, we're just a bunch of ants all cooperating (sort of) to haul food toward the nest (on average). There are many groups of poeple working on various bits and pieces as they see fit, since this is primarily a volunteer effort.
[svn:perl6-synopsis] r11985 - doc/trunk/design/syn
Author: larry Date: Thu Sep 14 17:31:33 2006 New Revision: 11985 Modified: doc/trunk/design/syn/S01.pod Log: and the date was the wrong year... Modified: doc/trunk/design/syn/S01.pod == --- doc/trunk/design/syn/S01.pod(original) +++ doc/trunk/design/syn/S01.podThu Sep 14 17:31:33 2006 @@ -10,7 +10,7 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 14 Sept 2005 + Last Modified: 14 Sept 2006 Number: 1 Version: 4
[svn:perl6-synopsis] r11986 - doc/trunk/design/syn
Author: larry Date: Thu Sep 14 17:32:58 2006 New Revision: 11986 Modified: doc/trunk/design/syn/S01.pod Log: typo from TimToady--++ Modified: doc/trunk/design/syn/S01.pod == --- doc/trunk/design/syn/S01.pod(original) +++ doc/trunk/design/syn/S01.podThu Sep 14 17:32:58 2006 @@ -29,7 +29,7 @@ =head1 Project Plan Mostly, we're just a bunch of ants all cooperating (sort of) to haul -food toward the nest (on average). There are many groups of poeple +food toward the nest (on average). There are many groups of people working on various bits and pieces as they see fit, since this is primarily a volunteer effort.
Re: the CGI.pm in Perl 6
On 9/13/06, Leon Timmermans [EMAIL PROTECTED] wrote: On the other HTML outputting functions: They never really belonged in CGI in the first place I guess. There is no reason they cannot be generalized to XML outputting and be put in an appropriate library. There is, actually. HTML ne XML. HTML is an SGML application. XHTML is an XML application. The HTML generation functions definitely don't fit in CGI.pm, but neither should they be pushed out into an XML generation module, if only for the sake of conceptual clarity. Regarding the general CGI.pm in Perl 6 topic... I was working on porting HTTP::* from LWP to Perl 6 a long time ago, but I was unable to complete that. That was probably a year or so ago; if someone would like to take over and bring it up to date with the latest syntax and tricks, be my guest. There were a few discussions with Juerd and others in #perl6 about CGI.pm in Perl 6... if anyone's interested, I'll look for the logs. The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). Rather, there needs to be proper seperation of concerns. Maybe instead of just importing CGI, you'd now import HTTP::Request::CGI and HTML::Generator (I'm throwing names out at random, although I did write HTTP::Request::CGI as a subclass of HTTP::Request whose members are populated in a manner similar to CGI.pm's parsing of %ENV). Aankhen -- I meant *our* species. You said *your* species. Evidently I am insane. May I go now?
HTTP::Request/Response (was Re: the CGI.pm in Perl 6)
At 5:00 PM -0700 9/14/06, Aankhen wrote: There were a few discussions with Juerd and others in #perl6 about CGI.pm in Perl 6... if anyone's interested, I'll look for the logs. The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). Rather, there needs to be proper seperation of concerns. Maybe instead of just importing CGI, you'd now import HTTP::Request::CGI and HTML::Generator (I'm throwing names out at random, although I did write HTTP::Request::CGI as a subclass of HTTP::Request whose members are populated in a manner similar to CGI.pm's parsing of %ENV). While I wasn't involved in that discussion, I agree with the sentiment you have expressed here, wherein there should be no CGI.pm in Perl 6. (Moreover, we should probably make an effort that no Perl 6 module will have just a top-level namespace as its name unless it is a core module or it is a framework.) Having had some prior experience in tackling this problem (eg, CGI::Portable), I will endeavour to work on / help with the Perl 6 analogy to HTTP::Request/Response, so to replace the use of corresponding aspects of CGI.pm. Note that the design strategy I had used in CGI::Portable was to have a pure container object representing a request and/or response, which was used sort of like this: 1. At start of handling an HTTP request, the main server runloop creates a new Request Container and has it populated by invoking a module function that knows about a particular environment, such as IO::Socket vs mod_perl vs CGI or whatever. 2. The main runloop calls the application's main per-request handling function; that function reads its HTTP input details from Request Container and writes its HTTP output details to Response Container. 3. At end of handling an HTTP request, the main server runloop invokes a module function that knows about a particular environment, and that function outputs whatever the Response Container represents. Note that, in the general case, the Request/Response containers would not have any ties to outside environment, though in specific cases where input and output are too large to easily fit in RAM at once, there can be enhancements. -- Darren Duncan
Re: the CGI.pm in Perl 6
Aankhen skribis 2006-09-14 17:00 (-0700): There were a few discussions with Juerd and others in #perl6 about CGI.pm in Perl 6... I've been following the discussion with great interest, and will summarize my thoughts here soon. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
