Re: the CGI.pm in Perl 6

[Juerd]

Larry Wall skribis 2006-09-20 16:34 (-0700):
> That should work but my preference is just
> my @bar = $q.param[];
> That is, empty .[] has the same arrayifying semantics as @.  (This is
> currently b0rken in pugs though.)  Likewise .{} is equivalen to %.

Nice, but what's the syntax for an empty slice then?
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)

[Juerd]

Mark Stosberg skribis 2006-09-16 21:32 (-0500):
> In theory, "use perl5:CGI" could be a fine solution. In practice, it
> hasn't worked out well for me.Even something that seems simple like
> passing a hashref to Perl 5 is not documented now.

I base my thoughts on Perl 6, not Pugs specifically. It's known that
Pugs doesn't implement all of Perl 6 perfectly yet, and Perl 5
compatibility is one of the many things that needs improvement. Give it
some time, and don't draw conclusions already.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Juerd]

Aankhen skribis 2006-09-20 18:32 (-0700):
> 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.

Because they speak the same language. That is: they know about arguments
passed via forms, and the preferred output language (xhtml? html?).

use Web :type :html <$web>;
...;
print img(...);   # 

I'm dreaming that :type does the following things:

1. Set the MIME-type to application/xhtml+xml
2. Set the output encoding to UTF-8 again, because application/*
   implied raw
3. Make begin_html (or whatever it'll be called) smart enough to
   output the correct XML header doctype too
4. Make all html generation methods (requested with ":html" in my
   example. Should perhaps be renamed to :htmlgen?) output XHTML
   compatible tags.

If Web::HTML (Web::HTMLgen) is a role to Web, all this can come
naturally. If it's a module somewhere else, it's not so obvious that
it'll play nicely with the rest. 

Putting it in the Web namespace, and making it use information from the
Web object (which mostly delegates to its .request and .response),
doesn't have to mean it can't be used stand-alone.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Fagyal Csongor]

Randal L. Schwartz wrote:


"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, it feels wrong that they are
Fagyal> there.

You've never made a sticky form then.


Erm... what makes you think so?

Not with CGI.pm, but I use HTML::FillInForm for the basic cases (which 
is simply a per-page config parameter in my framework, and which has the 
advantage of using simple HTML markup without any coding), and my own 
module (PET::Filter::UtilXmlMap) for more comples cases when forms are 
pre-populated from DB. E.g.:




(Note: this generates [% Util.ehtml.bodySelect('array', subst.pages, 
'name', 'page', selected, QUERY.page %] at compile time.)


I think JSP tag libraries had a too strong effect on me :)

- Fagzal

Web development II: Code

[Juerd]

Some pseudo-code for illustration. Maybe we should put this on version
control or wiki, and collectively hack on it. If we can agree on any
certain route.

If anyone wants to go ahead and implement things, don't wait for me
please. I unfortunately do not have the tuits to do this in full. I
don't even have the tuits to write this up :)

class HTTP::Headers {
does Hash;

...
}

class HTTP::Message {
has HTTP::Headers $.headers  handles   .= new;
has buf8  $.content  is rw;
has HTTP::Message @.partsis rw;
has Str   $.protocol is rw;

...
}

class HTTP::Argument {
does Array;
does Str;

# Possibly, does HTTP::Argument::Upload

...
}

class HTTP::Request { 
is HTTP::Message;
does Hash;  # %post{$key} // %get{$key}

has HTTP::Argument %.get;
has HTTP::Argument %.post;  # lazy if .method eq 'POST' and
# .headers
# > $arbitrary_yet_configurable
has Str%.cookies
has Str$.method where { $_ eq any  };
has URI$.uri;

...
}

role HTTP::Argument::Upload {
...
}

class HTTP::Response {
is HTTP::Message;
has $.encoding = 'UTF-8' is rw;
...
}

class Web::Request {
is HTTP::Request;
}

class Web::Response {
is HTTP::Response;

has $.type where { $_ eq any  } is rw;
# sets Content-Type too, assumes UTF-8

# do something with .headers to extract charset
# kill .content, because we're streaming
# add .print
}

role Web::Session {
has %.session;

...
}

role Web::Tags {
method tag_end () {
given $.response.type {
when 'html'  { return '>' }
when 'xhtml' { return '/>' }
when 'wml'   { return '/>' }
}
}

method img (...) {
return '  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: the CGI.pm in Perl 6

[David Cantrell]

On Tue, Sep 19, 2006 at 08:16:26AM -0700, Randal L. Schwartz wrote:
> > "David" == David Cantrell <[EMAIL PROTECTED]> writes:
> >> But don't throw out the simplicity of CGI.pm's basic task handling: parsing
> >> the incoming parameters (including file upload), and generating sticky 
> >> forms
> >> and other common HTML elements.
> David> That's two tasks.  It should be two modules.
> No, it's an *integrated* task.  The form-generation stuff needs tight coupling
> with the getting (and setting) of the incoming param values.

Gosh, maybe that's why my next paragraph was:

" I suppose you could argue that generating  tags specifically and
  all their baggage like s might fall under its remit (they are,
  after all, what generates the fancy requests that are CGI's bread and
  butter), but generating  tags is most definitely not anything to do
  with CGI. "

-- 
David Cantrell | Nth greatest programmer in the world

comparative and superlative explained:

 worse, worser, worsest, worsted, wasted

Re: Web development II: Code

[Steffen Schwigon]

Juerd <[EMAIL PROTECTED]> writes:
> Some pseudo-code for illustration. Maybe we should put this on
> version control or wiki

Just to state this somewhere: if anyone needs a subversion repository
for such Perl6 related stuff, I'm willing to setup svn repositories
and users on our Dresden Perl Mongers server. Just ask me, now or in
future. Might be good, for instance, if the projects feel too early or
experimental to be hosted on major Perl/Pugs/Feather/Sourceforge
resources.

GreetinX
Steffen 
-- 
Steffen Schwigon 
Dresden Perl Mongers 

Re: call, call(), .call, and captures

[Markus Laire]

On 9/20/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:

Larry Wall wrote:
> 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 ;)


That would be quite close to [\+] [\,] etc.. from S03:

S03> say [\+] 1..*  #  (1, 3, 6, 10, 15, ...)

--
Markus Laire

Dumb list-flattening question.

[Mark J. Reed]

Ok, I dkimmed through the synopses again and didn't see this offhand.

If I have two arrays @a and @b and I wish to create a two-element list
out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the 
correct way to do
that in Perl6?   If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then 
what do we call what
the \ is doing there, now that references are supposed to be a
behind-the-scenes  automagical thing?

--
Mark J. Reed <[EMAIL PROTECTED]>

Re: Dumb list-flattening question.

[Juerd]

Mark J. Reed skribis 2006-09-21  9:53 (-0400):
> If I have two arrays @a and @b and I wish to create a two-element list
> out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the 
> correct way to do
> that in Perl6?   If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then 
> what do we call what
> the \ is doing there, now that references are supposed to be a
> behind-the-scenes  automagical thing?

They're captures.

I personally wouldn't mind unary $, to supplement unary @ and %.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Captures: Synopsis update

[Aaron Sherman]

[EMAIL PROTECTED] wrote:


   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



+|   capture/arguments/match



+|$args; # all of the above


I'll read that as "conversation terminated".

Can you please update S03's "Junctive operators" section to note how the 
 ambiguity of the following are resolved:


 a|$b
 a | $b
 a |$b

I presume that it will be based on whitespace, but they could also be 
based on an inspection of a's signature (if a takes no parameters, then 
the only useful meaning of C is C(a(), $b)>, I think).


I further presume that such an update will be required for the pugs/v6 
team to correctly implement this.

Re: Dumb list-flattening question.

[Aaron Sherman]

Mark J. Reed wrote:

Ok, I dkimmed through the synopses again and didn't see this offhand.

If I have two arrays @a and @b and I wish to create a two-element list
out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the 
correct way to do
that in Perl6?   If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then 
what do we call what
the \ is doing there, now that references are supposed to be a
behind-the-scenes  automagical thing?


To expand on the previous answer, unary backslash as described in S03 
captures its argument and various representations can be extracted. In 
this case, you are capturing an array, and creating a list of arrays. 
This is done by reference, we presume, but that detail is not available 
to the programmer the way it was in P5.


Other forms of capture:

\$var; # Capture a scalar
\%var; # Capture a hash
\(...); # Capture parameters

\\$foo (as in Perl 5) is not a "capture to a capture", it simply acts 
like \$foo.

Re: Dumb list-flattening question.

[Mark J. Reed]

Mark J. Reed wrote:
> Ok, I dkimmed through the synopses again and didn't see this offhand.


That's what I get for dkimming instead of reading.  Or even skimming.

OK, so "Capture objects fill the ecological niche of references in
Perl 6."  Got it.  Perhaps we should also mention the use of Captures
to prevent list flattening somewhere in S09.

So now we have | as the "all of the above" dereferencer. I like the
mnemonic association with junctions, since |$x is logically similar to
($$x|@$x|%$x).

I dislike adding yet more whitespace-resolved ambiguity to the grammar, though.

--
Mark J. Reed <[EMAIL PROTECTED]>

Re: Captures: Synopsis update

[Larry Wall]

On Thu, Sep 21, 2006 at 10:29:57AM -0400, Aaron Sherman wrote:
: I'll read that as "conversation terminated".

The conversation is never terminated.  However, every now and then I
make feeble attempts to be decisive.  :)

: Can you please update S03's "Junctive operators" section to note how the 
:  ambiguity of the following are resolved:
: 
:  a|$b
:  a | $b
:  a |$b
: 
: I presume that it will be based on whitespace, but they could also be 
: based on an inspection of a's signature (if a takes no parameters, then 
: the only useful meaning of C is C(a(), $b)>, I think).

There's no whitespace dwimmery here.  Either 'a' takes an argument list or
it doesn't, based on its signature.  If it doesn't, all those are infix:<|>.
If it does, they are all prefix:<|>, except that we specifically outlaw
the first; list operators in Perl 6 require a space after them.

: I further presume that such an update will be required for the pugs/v6 
: team to correctly implement this.

Don't think so.  The situation is exactly analogous to:

a+$b
a + $b
a +$b

and even more exactly analogous to:

a%$b
a % $b
a %$b

The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.
If you see a bare function name you should generally assume it
has arguments in Perl 6.  We could probably go as far as to issue
an optional warning on the middle cases above based on whitespace
dwimmery and on whether the program gets in trouble later.  But it
would be a mistake to base the actual parsing on that.  That's the sort
of trick Perl 5 would have attempted, and I hope I know better now.

Larry

Re: Captures: Synopsis update

[Mark J. Reed]

On 9/21/06, Larry Wall <[EMAIL PROTECTED]> wrote:

: note how the ambiguity of the following are resolved:
:
:  a|$b
:  a | $b
:  a |$b
:



Don't think so.  The situation is exactly analogous to:

a%$b
a % $b
a %$b

The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.


Which means that argumentless subroutine calls will presumably be rare
in P6 code, but what about methods?  Methods with no arguments (apart
from the invocant) will always be commonplace, and it seems to me that
you have exactly the same ambiguity there:

$o.a%$b
$o.a % $b
$o.a %$b

--
Mark J. Reed <[EMAIL PROTECTED]>

Re: Captures: Synopsis update

[Larry Wall]

On Thu, Sep 21, 2006 at 12:16:26PM -0400, Mark J. Reed wrote:
: Which means that argumentless subroutine calls will presumably be rare
: in P6 code, but what about methods?  Methods with no arguments (apart
: from the invocant) will always be commonplace, and it seems to me that
: you have exactly the same ambiguity there:
: 
: $o.a%$b
: $o.a % $b
: $o.a %$b

A method never takes arguments unless you use : or (), so those are
all infix.  The design team worked Really Hard to get rid of that
particular ambiguity in Perl 6.  Argumentless methods parse more
like variables than like functions.

Incidentally, this is why all the optional arg functions that default
to $_ turned into methods, so you have use .print if you want to print
$_ by default.  Unlike a bare "print", a ".print" doesn't expect more
arguments unless you put : or (), so it simplifies parsing greatly.

Larry

Re: Captures: Synopsis update

[Mark J. Reed]

On 9/21/06, Larry Wall <[EMAIL PROTECTED]> wrote:

A method never takes arguments unless you use : or (), so those are
all infix.


Well, all righty then.  Yay for unambiguity!  Or disambiguation.  Or
nonambiguosity.  Or whatever...


The design team worked Really Hard to get rid of that particular ambiguity in 
Perl 6.


Thank you, design team.


--
Mark J. Reed <[EMAIL PROTECTED]>

The bare constants bear

[Aaron Sherman]

All sounds good up to:

Larry Wall wrote:


The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.
If you see a bare function name you should generally assume it
has arguments in Perl 6.


Well, in that case, should pi, e, et al. become $pi, $e, @et al.? ;)

Seriously, though, I think we discussed this before, and we kept those 
constants as bare, but if there's a cultural shift, then those would 
probably be its poster-children. I'm also in favor of the $π type 
Unicode equivalents for uniformity. Boolean constants are more 
questionable, as is the zeroary undef, which is pretty hard-coded in the 
brain of the average Perl programmer.


Right now, in the Math::Basic API doc, we have:



=head2 Constants

To export the constants provided by C use the C<:constants>
tag when importing:

 use Math::Basic :constants;

=over

=item e

 constant Num Math::Basic::e

The constant C, roughly equal to C<2.71828182845905>.

=item euler_constant

 constant Num Math::Basic::γ
 constant Num Math::Basic::euler_constant

The Euler constant (or Euler-Mascheroni constant or simply γ), roughly
equal to C<0.57721566490153286>. This constant should not be confused
with C.

=item golden_ratio

 constant Num Math::Basic::φ
 constant Num Math::Basic::phi
 constant Num Math::Basic::golden_ratio

The golden ratio, roughly equal to C<1.6180339887498948>.

=item i

 constant Complex Math::Basic::i

The constant C, which is defined as the square root of C<-1>.

=item one

 constant Complex Math::Basic::one

The constant value C<1>.

=item pi

 constant Num Math::Basic::π
 constant Num Math::Basic::pi

The constant C, roughly equal to C<3.14159265358979>.

=item zero

 constant Complex Math::Basic::zero

The constant value C<0>.

=back



Yes, I've spotted the bug in one and zero being complex for no good reason.

If you think that we should change to sigiled constants, then I will 
make it:




=head2 Constants

To export the constants provided by C use the C<:constants>
tag when importing:

 use Math::Basic :constants;

=over

=item $e

 constant Num $Math::Basic::e

The constant C, roughly equal to C<2.71828182845905>.

=item $euler_constant

 constant Num $Math::Basic::γ
 constant Num $Math::Basic::euler_constant

The Euler constant (or Euler-Mascheroni constant or simply γ), roughly
equal to C<0.57721566490153286>. This constant should not be confused
with C.

=item $golden_ratio

 constant Num $Math::Basic::φ
 constant Num $Math::Basic::phi
 constant Num $Math::Basic::golden_ratio

The golden ratio, roughly equal to C<1.6180339887498948>.

=item $i

 constant Complex $Math::Basic::i

The constant C, which is defined as the square root of C<-1>.

=item $one

 constant Int $Math::Basic::one

The constant value C<1>.

=item $pi

 constant Num $Math::Basic::π
 constant Num $Math::Basic::pi

The constant C, roughly equal to C<3.14159265358979>.

=item $zero

 constant Int $Math::Basic::zero

The constant value C<0>.

=back

[perl #40392] [CAGE] convert C to C

[via RT]

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


parrot's source is littered with internal_exception() calls, the bulk
(all?) of which should be converted to real_exception() calls.
internal exceptions are uncatchable, and might as well be called
C. that's bad, ya dig?

there are plenty of examples of calls to real_exception() so it should
be an easy task for the willing. look in
F for a list of exception constants.
convert to E_FooError types where possible.

for an example commit of a modification, C, or if
you don't have svn 1.4.0 yet (why not?) C
~jerry

Re: [perl #40371] [PATCH] as2c.pl C-file coda fix

[Paul Cochrane]

On 9/20/06, Jerry Gay via RT <[EMAIL PROTECTED]> wrote:

thanks, applied as r14673, with a minor fix:

-$print_coda();
+&print_coda();


Doh!  Should have got that one right...  Thanks for spotting it.  :-)

Paul

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Aankhen]

On 9/21/06, Juerd <[EMAIL PROTECTED]> wrote:

Because they speak the same language. That is: they know about arguments
passed via forms, and the preferred output language (xhtml? html?).


Ah, I didn't think of that.  My bad.  Roles for all these things sound
great to me. :-)

Aankhen

Re: the CGI.pm in Perl 6

[Juerd]

Larry Wall skribis 2006-09-21 15:24 (-0700):
> : > That is, empty .[] has the same arrayifying semantics as @.  (This is
> : > currently b0rken in pugs though.)  Likewise .{} is equivalen to %.
> : Nice, but what's the syntax for an empty slice then?
> Oh, I expect .[()] would work for that.  Why you'd want one beats me.

Generated code. It's nice that Perl usually isn't picky about such
things, because it saves you a lot of special cases when you're
generating code.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: the CGI.pm in Perl 6

[Larry Wall]

On Thu, Sep 21, 2006 at 10:10:04AM +0200, Juerd wrote:
: Larry Wall skribis 2006-09-20 16:34 (-0700):
: > That should work but my preference is just
: > my @bar = $q.param[];
: > That is, empty .[] has the same arrayifying semantics as @.  (This is
: > currently b0rken in pugs though.)  Likewise .{} is equivalen to %.
: 
: Nice, but what's the syntax for an empty slice then?

Oh, I expect .[()] would work for that.  Why you'd want one beats me.
Certainly it would work as a degenerate case of [EMAIL PROTECTED] as well.

Larry

Re: the CGI.pm in Perl 6

[Larry Wall]

On Fri, Sep 22, 2006 at 12:34:47AM +0200, Juerd wrote:
: Larry Wall skribis 2006-09-21 15:24 (-0700):
: > : > That is, empty .[] has the same arrayifying semantics as @.  (This is
: > : > currently b0rken in pugs though.)  Likewise .{} is equivalen to %.
: > : Nice, but what's the syntax for an empty slice then?
: > Oh, I expect .[()] would work for that.  Why you'd want one beats me.
: 
: Generated code. It's nice that Perl usually isn't picky about such
: things, because it saves you a lot of special cases when you're
: generating code.

Well, sure, and for related reasons 1..0 is an empty list rather than
a reversed list.  On the other hand, we do use negative subscripts assuming
the user intended them.  For the empty slice I expect the usual solution
would end up looking like .[,] unless the code generator outsmarts itself
by using join to suppress the trailing comma.

Larry

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Randal L. Schwartz]

> ""A" == "A Pagaltzis" <[EMAIL PROTECTED]> writes:

"A> * Randal L. Schwartz  [2006-09-20 19:30]:
>> "Fagyal" == Fagyal Csongor <[EMAIL PROTECTED]> writes:
>>> yet I never needed those HTML generating methods.
>> 
>> You've never made a sticky form then.

"A> False dilemma. You can create sticky forms conveniently without
"A> using CGI.pm’s HTML generation stuff. You can use HTML::Template,
"A> HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on?

"A> C’mon merlyn, you’ve been around long enough to know about CPAN
"A> and realise that your statement is transparently fallacious.

However, HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not*
in core.  CGI.pm was.  One stop shopping.  Easy to describe to people.

We need the same thing for Perl6: "If you're going to do simple web stuff,
please use MUMBLE module".  And MUMBLE better have tight integration of param
processing and sticky form generation, as well as good header generation for
cookies and redirects.  In other words, at least two thirds of what CGI.pm
does for me now.  And MUMBLE better be included *with* Perl6.

Without that, people will *hand code* that stuff, and get it wrong, and we'll
get the reputation of Perl6 being horrible for the web.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 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: CGI Session management (was Re: the CGI.pm in Perl 6)

[Juerd]

Randal L. Schwartz skribis 2006-09-21  9:15 (-0700):
> We need the same thing for Perl6: "If you're going to do simple web stuff,
> please use MUMBLE module".  And MUMBLE better have tight integration of param
> processing and sticky form generation, as well as good header generation for
> cookies and redirects.  In other words, at least two thirds of what CGI.pm
> does for me now.  And MUMBLE better be included *with* Perl6.

To a certain extent, I agree.

What do you think of the Web MUMBLE that I proposed? I think I've
expressed it in enough detail now, for you to form an opinion.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[Randy W. Sims]

Randal L. Schwartz wrote:

And MUMBLE better be included *with* Perl6.


I disagree. Anything that can be left out of the base Perl6 distro 
should be.


* It's too inflexible, so it doesn't allow for a new improved module to 
come along to replace it.


* It requires more from the Perl6 maintainers.

* It's impossible for everyone to agree on what should be core because 
everyone uses Perl6 for different applications.


* It's unnecessary bloat.

But this has all been "discussed" before...

Randy.

Re: CGI Session management (was Re: the CGI.pm in Perl 6)

[A. Pagaltzis]

* Randal L. Schwartz  [2006-09-22 01:25]:
> HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not* in
> core. CGI.pm was. One stop shopping. Easy to describe to
> people.

That still doesn’t prove that tight coupling is necessary between
parameter parsing and HTML generation.

The concept of core is getting a do-over for Perl 6 anyway.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Udates to "Perl 6 and Parrot Essentials"

[Sam Vilain]

Agent Zhang wrote:
> On 9/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>   
>> Have there been any significant changes since the 2nd. edition of "Perl 6
>> and Parrot Essentials"?
>>
>> If so, where should I look for a summary?
>>
>> 
>
> Yes, there have. That book is completely out of date. Please check out
> http://perlcabal.org/syn for the latest Synopses and other helpful
> documentation there.
>   

Having just read the second edition, I think "completely out of date" is
a bit harsh.  I think the best plan is to make sure as you go along that
all of the code snippets work as expected; as when you would when
normally working through a text, ie take the examples, run them, play
with them, etc in order to understand them.  There is always this list
to ask when you get stuck.

I actually think that as far as compact, easy to read summaries of Perl
6 go, this book is a treasure.

Sam.

Re: Good list-flattening question.

[Mark Stosberg]

Mark J. Reed wrote:
> Ok, I dkimmed through the synopses again and didn't see this offhand.
> 
> If I have two arrays @a and @b and I wish to create a two-element list
> out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the 
> correct way to do
> that in Perl6?   If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then 
> what do we call what
> the \ is doing there, now that references are supposed to be a
> behind-the-scenes  automagical thing?

I think it's a good question, considering this is worked for me in Perl 6:

my @c = ([EMAIL PROTECTED], [EMAIL PROTECTED]);

I'm not sure how to reconcile that with the spec I found for "\":

"The unary backslash operator captures its arguments, and returns an
object representing those arguments."

   Mark

Re: Capture sigil

[Sam Vilain]

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.
>   

Also;

  role type parameters

Sam.

Capture Literals

[Jonathan Lang]

How would I construct a capture literal that has both an invocant and
at least one positional argument?  How do I distinguish this from a
capture literal that has no invocant and at least two positional
arguments?

Gut instinct: if the first parameter in a list is delimited from the
rest using a colon instead of a comma, treat it as the invocant;
otherwise, treat it as the first positional argument.

This would mean that the rules for capturing are as follows:

* Capturing something in scalar context: If it is a pair, it is
captured as a named argument; otherwise, it is captured as the
invocant.

* Capturing something in list context: Pairs are captured as named
arguments; the first non-pair is captured as the invocant if it is
followed by a colon, but as a positional argument otherwise; all other
non-pairs are captured as positional arguments.

So:

 $x = /$a;  # $$x eqv $a
 $x = /:foo;# %$x eqv { foo => 1 }
 $x = /($a,);   # @$x eqv ( $a ); is the comma neccessary, or are the
() enough?
 $x = /($a:);   # $$x eqv $a
 $x = /(:foo);  # %$x eqv { foo => 1 }; assuming that adverbs can go
inside ().
 $x = /($a, $b)  # @$x eqv ($a, $b)
 $x = /($a: $b)  # $$x eqv $a; @$x eqv ($b)
 $x = /:foo ($a: $b, $c):bar <== $d, $e <== flag => 0; # results
on next three lines:
   # $$x eqv $a
   # @$x eqv ($b, $c, $d, $e)
   # %$x eqv { foo => 1, bar => 'baz', flag => 0 }

Note that this approach makes it impossible for a pair to end up
anywhere other than as a named argument in the capture object; while
this makes sense when the capture object is being used as a proxy
argument list, it makes less sense when it is being used as the
equivalent of perl 5's references, and thus is probably a bug.

--
Jonathan "Dataweaver" Lang

Re: Capture sigil

[Jonathan Lang]

Two questions:

1. How would the capture sigil affect the use of capture objects as
replacements for perl5's references?

2. With the introduction of the capture sigil, would it be worthwhile
to allow someone to specify a signature as a capture object's 'type'?
That is:

   my :(Dog: Str $name, Num :legs) |x = /($spot: "Spot"):legs<4>;

in analogy to 'my Dog $spot'?

--
Jonathan "Dataweaver" Lang

Re: Capture Literals

[Larry Wall]

On Thu, Sep 21, 2006 at 10:03:45PM -0700, Jonathan Lang wrote:
: How would I construct a capture literal that has both an invocant and
: at least one positional argument?  How do I distinguish this from a
: capture literal that has no invocant and at least two positional
: arguments?
: 
: Gut instinct: if the first parameter in a list is delimited from the
: rest using a colon instead of a comma, treat it as the invocant;
: otherwise, treat it as the first positional argument.

That is correct.

: This would mean that the rules for capturing are as follows:
: 
: * Capturing something in scalar context: If it is a pair, it is
: captured as a named argument; otherwise, it is captured as the
: invocant.
: 
: * Capturing something in list context: Pairs are captured as named
: arguments; the first non-pair is captured as the invocant if it is
: followed by a colon, but as a positional argument otherwise; all other
: non-pairs are captured as positional arguments.

Capture literals ignore their context like [...] does.

: So:
: 
:  $x = \$a;  # $$x eqv $a
:  $x = \:foo;# %$x eqv { foo => 1 }
:  $x = \($a,);   # @$x eqv ( $a ); is the comma neccessary, or are the
: () enough?

I think the () is probably enough.

:  $x = \($a:);   # $$x eqv $a
:  $x = \(:foo);  # %$x eqv { foo => 1 }; assuming that adverbs can go
: inside ().
:  $x = \($a, $b)  # @$x eqv ($a, $b)
:  $x = \($a: $b)  # $$x eqv $a; @$x eqv ($b)
:  $x = \:foo ($a: $b, $c):bar <== $d, $e <== flag => 0; # results
: on next three lines:
:# $$x eqv $a
:# @$x eqv ($b, $c, $d, $e)
:# %$x eqv { foo => 1, bar => 'baz', flag => 0 }

Ignoring the syntax error, yes.

: Note that this approach makes it impossible for a pair to end up
: anywhere other than as a named argument in the capture object; while
: this makes sense when the capture object is being used as a proxy
: argument list, it makes less sense when it is being used as the
: equivalent of perl 5's references, and thus is probably a bug.

If you say "flag" => 0 it comes in as a pair rather than a named arg.

Larry

Re: Capture sigil

[Larry Wall]

On Thu, Sep 21, 2006 at 10:20:20PM -0700, Jonathan Lang wrote:
: Two questions:
: 
: 1. How would the capture sigil affect the use of capture objects as
: replacements for perl5's references?

I don't see how it would have any effect at all, unless the P5 ref happened
to be to a typeglob, or had both array and hash semantics tied to it.
The regular $$x, @$x, and %$x look much like they do in P5.

: 2. With the introduction of the capture sigil, would it be worthwhile
: to allow someone to specify a signature as a capture object's 'type'?
: That is:
: 
:my :(Dog: Str $name, Num :legs) |x = \($spot: "Spot"):legs<4>;
: 
: in analogy to 'my Dog $spot'?

There are a several syntax errors in there, and we currently don't
allow assignment to a capture, only binding.  Semantically, I don't
know what such a construct would buy you over the already defined:

my (|x Dog: Str $name, Num :$legs) := \($spot: "Spot", :legs(4));

Larry