On Tue, Nov 25, 2003 at 01:03:19PM +1100, Damian Conway wrote:
> Schwern observed:
> >This may be a consequence of the example used
> >
> > while $n++ then $foo > $bar
> >
> >which I immediately associated with.
> >
> > if $n++ then $foo > $bar
>
> Yeah, I can certainly see that.
>
> Perh
On Mon, Jun 16, 2003 at 06:31:54PM -, Dan Sugalski wrote:
> For methods, each object is ultimately responsible for deciding what to
> do when a method is called. Since objects generally share a class-wide
> vtable, the classes are mostly responsible for dispatch. The dispatch
> method can, i
On Tue, Jun 17, 2003 at 09:44:52AM -0400, Piers Cawley wrote:
> Adam Turoff <[EMAIL PROTECTED]> writes:
> > As it *appears* today, regular dispatching and multimethod dispatching
> > are going to be wired into the langauge (as appropriate). Runtime
> > dispatch b
Damian just got finished his YAPC opening talk, and managed to allude
to dispatching and autoloading.
As it *appears* today, regular dispatching and multimethod dispatching
are going to be wired into the langauge (as appropriate). Runtime
dispatch behavior will continue to be supported, including
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
> Multimethod dispatch?
> Adam Turoff asked if multimethod dispatch (MMD) was really *the* Right
> Thing (it's definitely *a* Right Thing) and suggested that it would be
> more Perlish to allow the progr
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> And I don't see what's stopping someone from writing Dispatch::Value.
>
> use Dispatch::Value;
> sub foo($param is value('param1')) {...}
> sub foo($param is value('param2')) {...}
>
> What it seems you're wanting is it to
On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> You must not be following Perl 6 closely enough, then. Perl 6 is a
> "real" programming language now, as opposed to a "scripting" language.
Um, I've followed Perl6 closely enough to know that the distinction
between "real langauge" an
Apologies if I've missed some earlier discussions on multimethods. The
apocolypses, exegesises and synopses don't seem to say much other than
(a) they will exist and (b) wait for apocolypse 12 for more information.
Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
intent is t
On Wed, Mar 26, 2003 at 09:19:36AM +, Simon Cozens wrote:
> To what extent should the (presumably library-side) ability to parse a
> given markup language influence Perl 6's core language design? (which
> is what this list is nominally about.) I think this ought to
> approximate to "none at all
On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote:
> > "ML" == Michael Lazzaro <[EMAIL PROTECTED]> writes:
> ML> Along those lines, the closest I've been able to come so far to a
> ML> usable two-sentence definition is:
>
> ML> -- A list is an ordered set of scalar values.
>
On Tue, Jan 28, 2003 at 09:24:50AM -0800, Austin Hastings wrote:
> --- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 8:47 AM + 1/28/03, Piers Cawley wrote:
> > >> $ref[$key]
> > >>
> > >> an array or hash look-up???
> > >
> > >Decided at runtime?
> >
> > How? People use strings as array ind
On Fri, Jan 24, 2003 at 01:00:26PM -0500, Tanton Gibbs wrote:
> > The problem with cons/car/cdr is that they're fundemental operations.
> > Graham *has* learned from perl, and is receptive to the idea that
> > fundemental operators should be huffman encoded (lambda -> fn). It
> > would be easy to
On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley wrote:
> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> > I'm not a Lisp enthusiast, by and large, but I think he makes some
> > interesting observations on language design. Take a look if you're
> > feeling adventurous...
>
>
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote:
> On occasion, I have found it useful to cobble up a "little language"
> that allows me to generate a list of items, using a wild-card or some
> other syntax, as:
>
> foo[0-9][0-9] yields foo00, foo01, ...
>
> I'm wondering whether Pe
On Tue, Dec 10, 2002 at 11:37:58AM -0800, David Whipp wrote:
> I was reading the "Partially Memorized Functions" thread, and the thought
> came to mind that what we really need, is to define a different
> implementation of the method for a specific value of the arg. Something
> like:
>
> sub days_
On Mon, Dec 09, 2002 at 02:20:01PM -0800, Austin Hastings wrote:
> --- Paul Johnson <[EMAIL PROTECTED]> wrote:
> > How about the same way as one would do it now? Presumably we won't
> > all
> > forget how to program when Perl 6 comes out.
>
> I think you've missed the point. The original poster (
On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
> --- Adam Turoff <[EMAIL PROTECTED]> wrote:
> > I think you're trying to overoptimize something here. I can't see
> > a benefit to caching only sometimes. If there is, then you probably
> > w
On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
> --- Adam Turoff <[EMAIL PROTECTED]> wrote:
> > It doesn't matter whether some of the values are cheap lookups
> > while other values are "complex calculations". Once a cached sub
> > is
On Tue, Dec 10, 2002 at 01:53:28PM +1100, Damian Conway wrote:
> And in those rare cases where you really do need partial caching, the
> simplest solution is to split the partially cached subroutine into a
> fully cached sub and an uncached sub:
>
> sub days_in_month(Str $month, Int $year)
> {
On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote:
> I was wondering whether it'd be better to have this specified per
> C rather than per C. That'd permit something a long the
> lines of:
>
> sub days_in_month(Str $month, Int $year)
> {
>
> }
>
> Perhaps there are only some e
On Thu, Oct 24, 2002 at 12:26:41PM -0300, Adriano Nagelschmidt Rodrigues wrote:
> Luke Palmer writes:
> > Lisp is implemented in C, and C's macros are certainly not essential
> > to its functionality. But think of what macros in general provide:
> >
> > * Multi-platform compatability
> >
On Thu, Feb 07, 2002 at 08:40:41PM -0500, Dan Sugalski wrote:
> [...] I'm also trying to get a regular, if I'm
> lucky every issue, Parrot/Perl 6 article in The Perl Review.
Speaking on behalf of TPR, the only bottleneck here is providing
a regular article/update on Parrot/Perl6 for each issue.
On Tue, Jul 10, 2001 at 02:08:58AM -0500, David L. Nicol wrote:
> Uh, C++ virtual methods can be overloaded on a per-object basis, not
> just a per-class basis, since the object drags around its virtual jump
> table with it wherever it goes, so the jump can get compiled into
> "jump to the address
On Mon, Jul 09, 2001 at 03:48:27PM -0400, Buddha Buck wrote:
> Why can't a general-purpose programming language be augmented with XML for
> internal documentation purposes?
You mean like C#? :-)
Z.
On Mon, Jul 09, 2001 at 02:36:17PM -0400, Sam Tregar wrote:
> On Mon, 9 Jul 2001, Adam Turoff wrote:
> > Don't laugh. It's here now. It's called XSLT. :-)
>
> Um, that's not what the article was talking about The proposal is to use
> an XML syntax t
On Mon, Jul 09, 2001 at 01:37:36PM -0400, Sam Tregar wrote:
> On Mon, 9 Jul 2001, ivan wrote:
>
> > http://www.ora.com/news/vhll_1299.html
>
> Fascinating article, but his point about XML source code struck my funny
> bone. I've certainly heard the argument before - most recently in Dr.
> Dobbs
On Thu, May 10, 2001 at 12:13:13PM -0700, David Goehrig wrote:
> On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote:
> > If you talk that way, people are going to start believing it.
> [snip]
>
> Some of us are are talking that way because we already
> beleive it. You can't
On Fri, Apr 06, 2001 at 03:31:56PM -0400, John Porter wrote:
> Jarkko Hietaniemi wrote:
> > So URLs are not
> > literals, they have structure, and only thinking of them as filenames
> > may be too simplistic.
>
> Yeah. But Rebol manages to deal with them.
I doubt it. telephone:? fax:? lpp:?
On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
> > "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
> SC> Why can't Perl automagically do a Schwartzian when it sees a
> SC> comparison with complicated operators or functions on each side of
> SC> it? That is, @s = sort { f(
On Mon, Mar 26, 2001 at 08:25:17AM -0800, Peter Scott wrote:
> I'm kinda puzzled by the focus on Schwartzian when I thought the GRT was
> demonstrated to be better.
Because the transform is a specialized case
of the schwartzian transform where the default sort is sufficient.
Address the issu
On Tue, Mar 20, 2001 at 11:15:51PM -0500, John Porter wrote:
> Adam Turoff wrote:
> > This message is not an RFC, nor is it an intent to add a feature
> > to Perl or specify a syntax for that feature[*].
>
> Yay.
>
[...]
> So you think
>
> @s =
>
A very good non-programmer friend of mine just read yet another
discussion on the Schwartzian Transform, and had this to say:
> So, having just plowed through more than I ever wanted to about
> the Schwartzian Transform:
>
> Is there some way to hard-code this into Perl6? Seems like it
> would
On Tue, Oct 24, 2000 at 12:54:51AM -0400, Uri Guttman wrote:
> another TIL win is no compile phase and not even a bytecode intepreter
> startup phase. TIL code is executed directly and the script is now a
> true binary. reverse compilation is still easy due to the template
> nature of the generate
On Mon, Oct 23, 2000 at 08:33:23PM -0400, Uri Guttman wrote:
> as for ziggy's comments on the overload of builtins issue there could be
> a simple dispatch table used instead of direct calls.
I don't think you understand the issue. That's taking great pains
to unthread threaded bytecode once yo
you've lost the indirection.
There's a discussion that Larry started this weekend on -internals.
Specifically:
Date: Mon, 23 Oct 2000 08:45:39 -0700 (PDT)
From: Larry Wall <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] (Adam Turoff)
Cc: Larry W
On Thu, Oct 05, 2000 at 01:17:27PM -0400, John Porter wrote:
> RFCs are written to help Larry review the issues,
> and present some new ones. [...]
RFCs are part of our community library.
All of the summarization that is done in the RFC process is done
for our fearless leader, as well as for th
On Wed, Oct 04, 2000 at 03:42:57PM -0500, Jarkko Hietaniemi wrote:
> > Any others? There are bugs in the RFC process. Now is the time to
> > fix them.
>
> I don't know whether this is worth a separate improvement # but here goes:
>
> Too many RFCs live in a vacuum by not not explaining in enou
[Moving this discussion to -meta. See Reply-To.]
On Wed, Oct 04, 2000 at 03:14:39PM -0500, Jarkko Hietaniemi wrote:
> > I disagree. The RFC process is for generating ideas, not making decisions,
> > nor is any author obliged to include ideas he/she doesn't agree with;
> > that's why others ca
On Wed, Oct 04, 2000 at 12:18:22PM -0400, Buddha Buck wrote:
>
> Do you expect that your 7 retracted RFCs to be looked at by future
> developers? Even if they had good, but unpopular, points to make? Or do
> you expect that once retracted, they will be ignored?
Mostly.
There are some core d
On Mon, Oct 02, 2000 at 03:36:20PM -0500, Garrett Goebel wrote:
> From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
> > >- Done right, it could be easier to write and maintain
> >
> > Strongly disagree.
>
> Ok, you disagree. There are differing opinions here. Can we agree to
> disagree?
No.
A
On Sun, Oct 01, 2000 at 09:49:31AM -0500, Frank Tobin wrote:
> Adam Turoff, at 03:22 -0400 on Sun, 1 Oct 2000, wrote:
> > POD has three mighty significant advantages over XML:
> > - it is easy to learn
>
> True, but XML is also easy to learn, and is more in-line with
On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Perl should use XML for documentation instead of POD
No, it shouldn't. And I say that as an XML Evangelist.
> =head1 ABSTRACT
>
> Perl documentation should move to using XML as the formatting language,
>
On Sat, Sep 30, 2000 at 07:30:03PM +0200, Bart Lateur wrote:
> >All of the other features offered by Lincoln Stein's CGI.pm should remain,
> >but should not be deeply integrated into Perl6.
>
> Eek, no! I don't want no steenking p() functions etc. to generate HTML
> on the fly! That is one featur
On Thu, Sep 28, 2000 at 08:06:42AM +0200, H . Merijn Brand wrote:
> On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> > =head1 TITLE
> >
> > First-Class CGI Support
>
> Freezing
On Wed, Sep 27, 2000 at 05:11:30PM -0700, Nathan Wiger wrote:
> Yes, but perhaps a little bit of both. Truthfully, I've always seen long
> alternatives as useless bloat, not used widely over the long term. Once
> people learn the shortcuts, they use them.
>
> Expunging "use English" may will impr
On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote:
>
> My personal feeling is that I'd love "use English" to be expunged from
> the language altogether - it's unnecessary bloat that only increases the
> number of mistakes that people can make. But I'm not sure if I have the
> guts to w
On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
> Ziggy, are you interested in this idea enough (at all?) to stick a note
> about the 'header' function into the RFC? Or should I RFC it separately?
Adding headers() to the core language (or a similar pragma that is
automagically invo
On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote:
> Really, I don't see why we can't
> just have a 'use taint' and 'no taint' pargma.
Because taint mode needs to be turned on REEELY early, like before
pragmas are compiled.
Z.
On Wed, Sep 27, 2000 at 03:48:33AM -0400, Uri Guttman wrote:
> > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
>
> PRL> -r freadable()
> PRL> -w fwriteable()
> PRL> -x fexecable()
> PRL> -o fowned()
>
> PRL> -R Freadable()
> PRL> -W Fwrite
On Wed, Sep 27, 2000 at 08:50:28AM +0200, Bart Lateur wrote:
> On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote:
>
> >Another option is to stuff the long names into some namespace, and
> >export them upon request (or maybe not export them, upon request).
>
> Can you say "method"?
Doesn't wo
On Tue, Sep 26, 2000 at 02:13:41PM -0400, Uri Guttman wrote:
>
> and if the file test names are only loaded via a pragma it should be
> ok. it is not clear to me that you want that.
It's not clear that I want that either.
This is probably a plea for a subset of 'use english;', possibly
'use en
On Tue, Sep 26, 2000 at 01:14:05PM -0400, Uri Guttman wrote:
> > "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
>
> >> I'll revise the RFC to add 'readable()', 'writable()', and such
> >> synonyms for -r and -w that are more like 'use english' and less like
> >> 'use English'.
On Tue, Sep 26, 2000 at 04:41:21AM -0400, Alan Gutierrez wrote:
> > > > > Robust input parsing: yes.
> > > >
> > > > > General purpose output formatting: no, [...]
> > > >
> > > > > Rudimentary HTTP header emission: probably.
>
> So this is the definition of first-class?
Have you read the RFC
On Tue, Sep 26, 2000 at 05:02:02PM +1100, iain truskett wrote:
> Is there much point having a lightweight CGI module? If you say 'I want
> it to load quickly', I say 'get mod_perl'.
There's more to it than just loading quickly. It should load quickly
as in "load everything that's absolutely nece
On Mon, Sep 25, 2000 at 09:34:41PM -0700, Nathan Wiger wrote:
> Adam Turoff wrote:
> > I'm thinking that whether the request came from a GET or a POST,
> > the un(HTTP)-escaped values will be in %CGI, just as CGI::params()
> > does.
>
> Like this?
>
On Mon, Sep 25, 2000 at 09:18:40AM -0500, Jonathan Scott Duff wrote:
> On Mon, Sep 25, 2000 at 06:02:51AM -, Perl6 RFC Librarian wrote:
> > =head1 ABSTRACT
> >
> > File tests (-r/-w/-x/...) made sense when Perl's shellness was an
> > attribute. Most new Perl programmers are not coming from a
On Sun, Sep 24, 2000 at 11:16:46PM -0700, Nathan Wiger wrote:
> > Perl is frequently used in CGI environments. It should be as easy to write
> > CGI programs with perl as it is to write commandline text filters.
>
> First off, good idea, I do like this. Critiques:
>
> > Parse the CGI context, r
On Mon, Sep 25, 2000 at 03:17:33AM -0400, Alan Gutierrez wrote:
> On 25 Sep 2000, Perl6 RFC Librarian wrote:
> > First-Class CGI Support
>
> First-class CGI to me means HTML::Embperl.
It means a hundred different things to a hundred different Perl
programmers. Especially those writing mod_perl
On Mon, Sep 25, 2000 at 11:43:53AM +0100, Hildo Biersma wrote:
> For output generation, it becomes worse.
Output generation is a separate problem space altogether. Related,
but separate.
Should embperl be turned on simply because I have a CGI program
returning text, images or HTTP redirects
On Mon, Sep 25, 2000 at 10:09:03AM -0500, [EMAIL PROTECTED] wrote:
> > =head1 TITLE
> >
> > First-Class CGI Support
> > [...]
> > To make CGI programming easier, this option/pragma should:
>
>
> Should the option/pragma also do "something" with regards to
> files opened for writing?
>
> They (n
On Mon, Sep 25, 2000 at 07:50:28AM +0100, Richard Proctor wrote:
> On Mon 25 Sep, Perl6 RFC Librarian wrote:
> > Turn on tainting
>
> What would it do on a platform that does not support Tainting?
Is this a real issue? Is there a platform where tainting isn't
supported?
> > Parse the CGI conte
On Mon, Sep 25, 2000 at 09:40:52AM -0400, Michael Maraist wrote:
> > Many mechanisms exist to make perl code and data persistant. They should
> > be cleaned up, unified, and documented widely within the core
> > documentation.
>
> But doesn't this go against TMTOWTDI. :)
On the one hand, there'
I plan to offer a more formal RFC of this idea.
Z.
=item perl6storm #0101
Just like the "use english" pragma (the modern not-yet-written
version of "use English" module), make something for legible
fileops.
is_readable(file) is really -r(file)
note that these are hard to write now due to
I plan to offer a more formal RFC of this idea.
Z.
=item perl6storm #0043
Write something that spits out module dependencies. Like makedep.
A tool that sources but doesn't run? a program/module then spits
out %INC might suffice. Can we autobundle with CPAN tricks?
I plan to offer a more formal RFC of this idea.
Z.
=item perl6storm #0026
Make CGI programming easier. Make as first class as
@ARGV and %ENV for CLI progging.
I plan to offer a more formal RFC of this idea.
Z.
=item perl6storm #0025
Make -T the default when operating in a CGI env. That is, taintmode.
Will this kill us? Close to it. Tough. Insecurity through idiocy
is a problem. Make them *add* a switch to make it insecure, like
-U, if that's wha
I plan to offer a more formal RFC of this idea.
Z.
=item perl6storm #0004
Need perl to spit out pod/non-pod, like cc -E. Pod is too hard to parse.
This would make catpod trivially implemented as a compiler filter.
I plan to offer a more formal RFC of this idea.
Z.
=item perl6storm #0022
make marshalling easy. core module? would this allow for easy
persistence of data structures other than dbm files?
general persistence is hard, right? can this be an attribute?
I plan to offer a more formal RFC of this idea.
Z.
=item perl6storm #
This:
($a,$b) = ;
should not drain whole ahndle on known LHS count, to rescue
my($x) = ;
On Fri, Sep 15, 2000 at 01:33:01PM -0700, Nathan Wiger wrote:
> Michael G Schwern wrote:
> >
> > perl6-internals is probably the wrong forum for this, it was just
> > convenient. I think Dan's got the right idea, distribute a Taint
> > module with Perl.
>
> I'm not sure what's happened on -inte
On Fri, Aug 11, 2000 at 04:53:01PM -0500, Jarkko Hietaniemi wrote:
> On Fri, Aug 11, 2000 at 04:48:12PM -0500, David L. Nicol wrote:
> > It's a vast and contrived joke, right?
>
> If it is, someone has really gone into some trouble:
>
> http://www.cobolscript.com/samples.htm
Looks real to me, b
71 matches
Mail list logo
