Re: Dispatching, Multimethods and the like
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 behavior will continue to be supported, including things like AUTOLOADER and the like. Whoah! The wired in dispatch rules are going to be runtime dispatch rules, but with potential compile time short circuiting where the compiler knows enough stuff (frankly, I'm not sure I'd expect to see compile time short circuiting in perl 6.0, maybe in 6.001 or whatever) That sounds about right. Perl as we know it is runtime dispatched, so adding compiletime short circuiting sounds like a job for a new pragma or declaration. 6.000+epsilon sounds like the right time to introduce this feature. Z.
Re: Dispatching, Multimethods and the like
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, if it wants, do *anything*. Hm. Ruby has unbound methods and per-object method binding. How does that impact Parrot's built-in dispatching behavior(s)? Core engine support will be in for this, since we don't want everyone to have to bother writing code for it all. Duplicate code. Bleah. We'll also provide method caches so we have some hope of not being horribly slow. Hm. Maybe the solution here isn't to fob off *all* dispatching to the core or the program, but have loadable dispatching behaviors, much like loadable datatypes and opcodes... Don't know how desirable or implementable that idea would be. Or even if it's just half-baked. But it would be interesting to play around with things like a dispatcher that adds before: and after: methods (for AOP), or support for programming by contract sanity checking. Worst case, a Perl programmer might have to drop a pasm block in a class definition to link the dirty bits together without necessarily extending the language. Whatever happens, it's certainly one of those grey areas that lies smack between language definition and runtime implementation... Z.
Dispatching, Multimethods and the like
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 things like
AUTOLOADER and the like.
As of January, the thinking is sub DISPATCH {} will handle runtime
dispatching behaviors, including autoloading, but easily accomodating
value-based dispatching, AOP style pre/post methods, and whatnot.
Unfortunately, Damian said that the design team isn't saying much about
this, because the semantics aren't quite worked out yet, especially with
the interaction between autoloading and other dynamic dispatching
behaviors.
Yes, this is a *big* issue.
Z.
Re: This week's summary
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 programmer to override the dispatcher,
allowing for all sorts of more or less cunning dispatch mechanisms
(which isn't to say we could still have MMD tightly integrated, but it
wouldn't be the *only* alternative to simple single dispatch). Luke
Palmer gets the Pointy End Grandma award for pointing out that Perl 6
is a 'real programming language now' (as Adam pointed out, Perl's been
a 'real' programming language for years), inspiring a particularly pithy
bit of Cozeny. As far as I can tell, Adam wants to be able to dispatch
on the runtime value of a parameter as well as on its runtime type (he's
not alone in this). Right now you either have to do this explicitly in
the body of the subroutine, or work out the correct macromantic
incantations needed to allow the programmer to use 'nice' syntax for
specifying such dispatch.
Assuming I'm not misunderstanding what Adam is after, this has come up
before (I think I asked about value based dispatch a few months back)
and I can't remember if the decision was that MMD didn't extend to
dispatching based on value, or if that decision hasn't been taken yet.
If it's not been taken, I still want to be able to do
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
That's pretty much correct.
I've been musing on dispatching over the last week, and I've come
up with a few scenarios:
- pure type-based (match a method's signature, modulo superclasses)
- pure value-based (scalars with specific values)
- mixed-mode (RightMouseClick class, with 'control' modifier set/unset)
- pre-/post- methods; chains of pre-/post- methods
- AOP-style pre-/post- methods that can come and go at runtime
- Eiffel-style contract checking/enforcement
- roll-your-own inheritance mechanisms (see NEXT.pm)
I've also considered side-effect based dispatching for lack of a better
term: Consider an object with a whole gaggle of methods that need to check
whether the database is up before continuing. All of them fail similarly
with a database is down error. Why *not* factor that out into a
different set of multimethods that execute only when the database is down?
Now consider what happens if the database handles are not parameters to
each method call, but slots in the object or stored globally...
There are a few other, admittedly weird scenarios where this kind of
behavior would be desirable. All of them exhibit an AOP-ish quality.
Anyway, as Piers summarized, my concern is that if there's only two types
of dispatching, it may be artificially limiting. I'm guessing that if I
can think of three dispatching behaviors, then there may be five, and if
there really are five then there just might be as many as ten or more.
Therefore the simple dispatch/type-based MMD dispatch duality limits more
than it empowers.
I don't think this is really a problem to be solved in the domain of
macro expansion or syntactic warpage. Writing classes to handle these
rules feels like the way to go. Whether or not MMD as it's been sketched
is hardwired into the language (e.g. for performance) is less important to
me than the ability to plug in different (levels of) dispatching behaviors.
Z.
Re: Multimethod dispatch?
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 and scripting language is meaningless and
artificial when you're talking about Perl. Perl is quite simply a
'programming language', and it has been for years.
It will still have a lot of power in text processing, and still be a
powerful quicky language, but that's no longer its primary focus --
not to say that highly structured programming is. Some applications
want strong typing, some don't. That's why typing is optional (which
is still driving me nuts as to how that's going to work).
You seem to have Perl5 confused with bash, sed or awk.
The main principles behind Perl are:
0: Get the job done (before the boss fires you)
1: TMTOWTDI
2: Use what works for you (i.e., Perl has no ideological bias)
I don't see what typing has to do with any of that. And I don't see why
optional typing or moving towards 'highly structured programming' is the
solution to fixing all of Perl5's warts.
Well, type signatures are the only relevant information we have, so
that's what we'll use. See below.
They're *not* the only relevant information that *we* have. They're
the only relevant information that a Java/C++ compiler has at compile
time. We can do better, since we're dispatching at runtime.
Perl will easily be (is) powerful enough for someone to write a
dispatcher class. Whether that will be easy to do doesn't matter,
because some Damian will write a module to make it easy.
That's not my concern.
My concern is that there's a huge body of ideas and literature out there
that's worth stealing and putting into Perl6. MMD is one of those ideas.
However, the foundations of MMD are solving problems in the context of
limitations that do not necessarily exist in Perl6. Furthermore, concepts
that are roughly similar to MMD are *harder* to convey the because classic
MMD is baked in and taking up so much mindshare when it comes to
dispatching.
What the A6 MMD's accomplish are the common case. There's one most
common kind of dispatch that it implements. But Perl's not going to
stop you from redefining the multi declarator, registering the
routines, and using your own dispatcher. Perl 5 sure didn't :-)
That's a cop-out.
Of course I can write my own dispatcher or warp the syntax to make my
pet idiom work. If the solution to every hard or unforseen problem is
warp the syntax, then Perl6 is doomed to failure[*]. Don't forget that
Perl has many masters, and if the work-a-day Perl5 programmer is left in
the dust, then Perl6 will not have fufilled its mission.
The whole point behind Perl6 is to remove the warts and make easy things
easier. To me, this is a wart:
my %dispatch = (
param1 = sub {...},
param2 = sub {...},
);
sub foo {
my $param = shift;
if (my $sub = $dispatch{$param}) {
$sub-(@_);
} else {
warn No such parameter: $param\n;
}
}
It's structurally similar to MMD, yet it is unsupported by MMD. And a
very easy technique for cleaning up Perl programs.
Z.
*: JBoss 4.0 is coming out, and if the pre-press reports are even remotely
correct, it was implemented using a high degree of AOP. The JBoss team
didn't need to warp Java syntax to accomplish it; instead, they rewrote
the class loader to support :before and :after subs dynamically appearing
and disappearing. I predict that this kind of extension, along with
macros, are going to be *MUCH* more useful than hacking the grammar.
The 'warping the syntax' escape hatch should only be used for hacking in
things like v-strings or lexical filehandles, *not* every pet extension
hook that someone could possibly want to see in the language.
Re: Multimethod dispatch?
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 be in the core.
Actually, no.
I expected that there'd be a way to extend runtime behavior through modules
like this hypothetical Dispatch::Value, Dispatch::Multimethods, or
Dispatch::Agent::Smith, but I'm seeing precious little evidence of that,
just allusions to MMD with the 'multi' keyword and all that.
As I said earlier, MMD is starting to give me a big case of The Fear
because it's predicated on offering behavior that heretofore hasn't been
widely used in Perl, and it's based around limitations that don't
necessarily exist in Perl. It's nice that Perl6 will extend its dynamic
range, but the whole reason for Perl6 in the first place is to fix
some of the warts in the current problem domain.
With some recent focus on MMD (mostly thanks to Dan's WTHI post, and my
discovery of TAMOP), I started to feel like MMD was good for a certain
style of programming, but necessarily ignores a native Perl5 idiom that's
equally powerful and perhaps preferable for a large set of problems.
I'm not trying to throw out the type system or cast MMD as pure evil.
Rather, I'm just poking around to make sure the dispatch machinery isn't
wired in for single dispatch/MMD without opening it up for extensions
via simple dispatch classes. *That* feature seems much more important
to me than wiring in MMD, since MMD could be implemented through
Dispatch::Multimethods or something. It's been done before with
Class::Multimethods, and I'll buy that there's a benefit to adding a
'multi' keyword to the language, but not if that's the last word for
variant dispatching...
If some dispatch class can use some syntax vaguely approximating the straw
man above, then this is just a tempest in a teapot and I'll move along.
But I haven't heard or seen anything concrete that dispatch behavior in
Perl6 can be user-defined without resorting to serious magic. Instead,
it's starting to sound suspiciously like you can have any dispatching
behavior you want, so long as it's either single dispatch (modulo
sub/method semantics) or MMD. And that would be a net loss for Perl6.
Z.
Multimethod dispatch?
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 to implement method overloading similar to C++/Java or multimethods in CLOS in a Perlish fashion. Dan's WTHI MMD[***] has also been quite helpful. I'm paging through The Art of the Metaobject Protocol for bedtime reading material, and multimethods are starting to give me a big case of The Fear. As I understand it, the idea behind MMD is that languages like C already do it with basic operators, since '5 + 3' generates different instructions than '5 + 3.1' or '5.5 + 3.1' do. But weak languages like C do not allow that mechanism to be triggered by user defined functions. The obvious answer in type heavy languages like C++, Java or Common Lisp is to extend that behavior for user defined functions. Somehow that just feels wrong in Perl. In all of the Perl code I've written, I've *never* felt the need to overload the + operator, or have one of five possible implementations of new() automagically selected by the datatypes of its arguments. Furthermore, most Perl programs I've read or written aren't very type heavy -- there's still a lot of text slinging and plain vanilla reference processing going on, and presumably that will still be the case in five years' time. Type-based MMD as it exists elsewhere are solving a problem that does not exist in Perl, or at least does not exist to the same extent it does in other languages. Similarly, value-based dispatching is dirt simple in Perl and easy to implement that it's an idiom that at least I use constantly. Add all that up, and MMD is a lot of pain for not a huge benefit. Not because MMD is a necessarily bad idea, but because MMD doesn't go *far* enough, since it's limited to type signatures. A better fitting solution wouldn't focus on classic MMD, but simply Dispatch, where type- and value-based dispatching are two of many kinds of dispatching supported. If there's a third kind of dispatching (e.g. a hybrid model), then the dispatching machinery would be open enough for someone to write a new dispatcher class in Perl instead of warping the language. I haven't been following language syntax discussions recently, so I'll refrain from proposing a straw man. Z. *: http://dev.perl.org/rfc/256.pod **: http://search.cpan.org/author/DCONWAY/Class-Multimethods-1.70 ***: http://www.sidhe.org/~dan/blog/archives/000194.html
Re: P6ML?
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.
Approximately none, except that Perl's self-selected problem domain is
text hacking, and XML is redefining the meaning of text hacking.
AFAICT, all of this is rather moot. The ability to create a presumably
fast parser using rule{}'s and such solves 80% of the problem. From
there, it's a SMOP to convert text-with-angle-brackets to sensible
native data structures or native processing techniques.
I believe Robin's interest in the area is in ensuring that there will be
a simple way to take a specific XML grammar and [auto]generate an
angle-bracket-friendly parser that produces appropriate domain-specific
data structures without the grovelling through horribly generic data
structure, events or whatnot.
Z.
Re: Arrays vs. Lists
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. ML -- An array is an object that stores a list. but you can't derive the rules about allowing push/pop/splice/slice from that pair of defintions. 1) A list is an ordered grouping of scalar values. 2) An array is an object that stores a list. 3) Assignment and splices can be performed on both lists and arrays. 4) Operators like push/pop/splice/shift/unshift operate only on arrays. lists are read only Not quite: ($a, $b, $c) = 1..3; Z.
Re: Spare brackets :-)
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 indices and ints/floats as hash indices, and count on autoconversion to Make It Work. On the one hand: Java/ECMA/J-script does it. That's nice, but Perl isn't Java/ECMAScript/JavaScript/JScript/C/C++/Pascal. It's Perl. Perl uses square brackets for arrays, and curly braces for hashes. Period. And Perl 6 will continue in the path of Perl 1..5, *not* in the path of some other broken syntax. If you have any questions about this, please refer to the 1st, 2nd, or 3rd editions of Programming Perl, or to any of the millions of Perl programmers who have that distinction hard-wired into their wetware. Z.
Re: Arc: An Unfinished Dialect of Lisp
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... I can't help feeling slightly deflated. Given the chance to re-design Lisp from scratch, the tasks on the top of my TODO list to address would be: * getting rid of some/all those damn parenthesis * renaming cons/car/cdr to something meaningful Alas, these are about the only parts he's not changing. He promises that Arc will have a syntax one day, but there isn't one yet. These slides are over a year old. There hasn't been much of Arc since Paul Graham's early musings on it. But one of the things he did do was rename lambda to fn. This is proof that the holy grails can be tossed out of the window. 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 simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. Austin mentioned that the syntax has eliminated the need for some of the parens, so that's a start. Perhaps a real syntax can follow. :-) The other comments that caught my eye were that Arc is designed for Good Programmers[tm] and that it was particularly targetted at developing web applications. Alas, my experience seems to suggest that most of the people writing web applications are monkeys who would rather have something designed for Bad Programmers, like PHP. Good Programmers [tm] has been a theme of Graham's work. Figure that less than 10% of programmers make this cut. Lisp hackers like to assert that good programmers eventually migrate to Lisp or something lisp-like (er, functional). Count up all of the Lisp/Scheme/ML/Haskell programmers you know relative to the total number of programmers, and that's the percentage of web programmers he's targeting. The fact that a good many web programmers want ASP/PHP doesn't really have an impact on what he's trying to do. A bigger problem is that employers demand large numbers of these folks to do the job that someone Good [tm] could do in a day. Alone. While reading email. Z.
Re: Arc: An Unfinished Dialect of Lisp
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 simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. hmm...ML uses hd and tl. I believe that is pretty coded :) Good point. I've used Scheme and Lisp, but not ML... Z.
Re: Partially Memoized Functions
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)
{
$month = lc $month;
if $month eq 'feb'
{
my sub feb_days (Int $year) is cached {
my $leap = $year % 4 == 0
($year % 100 != 0 || $year % 400 == 0);
return $leap ? 29 : 28;
}
return feb_days($year);
}
else
{
# Simple look-up, so caching would be counter-productive:
return %days{$month}; # %days was declared above (honest)
}
}
I don't think that works correctly. This will create a new cached
sub each time $month eq 'feb'? That'll generate a lot of cached
subs, values will be calculated each time $month eq 'feb, and none
of the values will ever be returned from any of those caches.
Schwern's approach of factoring out days_in_feb into a cached sub
is the same basic idea, and doesn't have this issue.
Z.
Re: Partially Memoized Functions
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 called with a set of parameter values, the return value will always be a cheap lookup in the memoized sub's cache. You may get some disagreement from those for whom memory is neither virtual nor free. Memoization is simply the exchange of cheap memory lookups for complicated calculations. If memory is more precious than a few CPU cycles, then you shouldn't be memoizing. Z.
Re: Partially Memoized Functions
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
want to implement a more sophisticated cache management strategy
for your sub, not warp the language for a special case.
Ahh. This is better. How does one implement a more sophisticated cache
management strategy?
By memoizing specific cases by hand, of course. :-)
That is, what is the mechanism for manipulating the run-time system
behavior of subs?
Memoization does not have to involve manipulating runtime behavior.
However, manipulating runtime behavior is a simple, generic and
effective way to memoize random subs.
Here's an example of a memoizing only the values for 'feb'.
Schwern's solution is simpler and easier to read though.
{
## start of a lexical scope to hide %feb_cache
my %feb_cache;
sub days_in_month(Str $month, Int $year) {
$month = lc $month;
if $month eq 'feb' {
unless $feb_cache{$year} {
my $leap = $year % 4 == 0
($year % 100 != 0 || $year % 400 == 0);
$feb_cache{$year} = $leap ? 29 : 28;
}
return $feb_cache{$year};
} else {
return %days{$month};
}
}
}
Z.
Re: Partially Memoized Functions
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 (Smylers) asked if there was a benefit to only cacheing certain values, presuming the remainder would be either trivial to compute or internally cached, or both. I think *you've* missed the point. There's not enough benefit to support caching certain values through linguistic warping. That technique is possible, and it's the kind of solution that is better suited to (1) hand-rolling a cache management strategy, or (2) refactoring the code to work with standard memoization. The best solutions involve caching all of the values returned by this function (ignoring the possible waste as insignificant), or refactoring the code so that all of the meaningful values are cached (and computed by a separate cached sub). Z.
Re: Multmethods by arg-value
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_in_month( Str $month, Int $year )
{
...
}
sub days_in_month( Str $month is value{ rx:i/feb[ruary]?/ }, Int $year ) is
cached
{
...
}
That strikes me as a lot of bugs waiting to happen.
What happens when you have multiple values that would match a given
parameter?
What happens when some module you don't even see loads a variant
of a sub you declare that matches some of the arguments you expected
to process?
XSLT has something similar. The rules are subtle and easy to mess
up. The XSLT spec also states that defining multiple subs (templates)
that could match a piece of input is an error, but may be resolved
by a specific algorithm (last definition prevails). I'm not so
sure I like that behavior in Perl; it's all too easy to create new
subs at runtime...
Z.
Re: REs as generators
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 Perl should have a similar capability, using REs.
Dominus has an example of an 'odometer' written using closures. If
you want to specify a simple sequence like this using a regex, then
you need to parse the regex (but in reverse).
Alternatively, you could write a generic odometer generator generator
that takes a series of scalars and lists:
my $generator = make_generator('foo', [0..9], [0..9]);
while ($_ = $generator-()) {
## progressively generate foo00, foo01, ...
}
Z.
Re: Partially Memoized Functions
On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote:
I was wondering whether it'd be better to have this specified per
Creturn rather than per Csub. That'd permit something a long the
lines of:
sub days_in_month(Str $month, Int $year)
{
}
Perhaps there are only some edge cases which require calculation; or the
function is liable to be called with many invalid input values, which
can quickly be determined yield Cundef and so which don't need
caching; or there is a pattern as to which sets of input parameters are
likely to be passed multiple times so the function only bother caching
those.
It doesn't matter whether some of the values are cheap lookups
while other values are complex calculations. Once a cached sub
is called with a set of parameter values, the return value will
always be a cheap lookup in the memoized sub's cache.
It's irrelevant if you have a different but comparable cheap
lookup for some values.
Anybody else like this, or are we better off leaving things as they
were?
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
want to implement a more sophisticated cache management strategy
for your sub, not warp the language for a special case.
Z.
Re: [OT] Power of Lisp macros?
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 * Easier maintenance Perl has no problem with the former. It's multi-platform by nature. But is has as much of a problem with the latter as any other language, except Lisp. That is one of the continuing strong points of Lisp: it can change very, very quickly. Yes. And what would this kind of meta programming allow? Perhaps thoughts like this: Now I need code for these n cases. I will just write a macro. Maybe it makes complex problems suddenly appear more tractable, allows for more code reuse/factorization? Damian's Switch.pm is like a Lisp macro. It extends Perl syntax for a certain kind of problem, and makes it easier to write a common code pattern. The thought process might go something like this: I want to check a variable against a variety of conditions, and I'm tired of writing the same long-winded and error prone if/elsif/elsif/elsif/else cascade. This is a common 'switch' statement, except that I want to match a variety of conditions intelligently (integers, string equality, regexes, etc.). When Paul Graham writes that 25% of his Viaweb code was macros, he's really saying that Common Lisp wasn't well suited to his problem domain (writing an ecommerce app). However, Common Lisp *allowed* itself to be extended in that directon, with macros. The result is that the 75% of his code that comprised the guts of Viaweb could have been written without macros (or in a language other than Common Lisp), but would have taken significantly more effort and code (and led to more bugs). Perl source filters are similar to Lisp macros to a small degree. Lisp macros are Lisp functions that are invoked at compile time to transform a *tokenized* Lisp program (using Lisp data structures) into a different set of tokens (which are then compiled). Source filters tend to act on raw text, not tokenized source code, and need to deal with the problematic aspects of Perl syntax (comments, Pod, HEREDOCs, etc.) every time they are written/invoked. Because Lisp macros are real Lisp code, they are far more powerful than the textual substitutions that pass for C macros. Perl6 is moving to include something like Lisp macros. Perl5 source filters are a rough approximation, and a preview of things to come. Z.
Re: Perl6/Parrot status
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. There's certainly interest in running regular updates on Parrot and Perl6. Logistics, applicability and updates to parrotcode.org are a separate issue that likely just needs a few nanoseconds of thought. Z.
Re: Per-object inheritance in core a red herring?
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 that is offset bytes away from the start of the object that is doing the method which is pretty light, unless you've got dozens of virtual methods. And what's the linguistic hook that allows C++ object-based inheritance? And where's the guarantee that vtbls are per-object and not per-class? Z.
Re: http://www.ora.com/news/vhll_1299.html
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 Software Development insert. Don't laugh. It's here now. It's called XSLT. :-) I've got just one question: if this is such a good idea why don't the proponents just go ahead and start doing it? All it requires is a simple source filter and if XML is all it's cracked up to be that should be pretty easy to write. The only benefit I can find to XSLT using XML as a programming language syntax is that it's a natural fit for intermingling XML output with XSLT constructs (xsl:for-each, xsl:if, etc.). For average programs, it sucks eggs. I don't want to *THINK* about doing the 8-queens problem with XSLT, although it's possible. It's not because of the scheme-like behavior; it's because of the needless verbosity for programming-style tasks (vs. format translation tasks). Some problems still exist: runaway strings are still there, as are unterminated statements. Except now, it's with XML syntax, so you're talking about closing tags that aren't open, or prematurely closing a tag (because you forgot an end tag somewhere). Completely different class of syntax errors, and a lot of cognative dissonance for those who are used to more conventional programming languages. :-| The answer: the lack of comfortable XML editors and the pain of editing XML by hand would make programming in an XML source format less fun than it seems. Straw man argument. You don't need a comfortable XML editor to do XSLT; lack of comfortable XML editors are not hindering the adoption of XSLT. Z.
Re: http://www.ora.com/news/vhll_1299.html
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 to program in existing VHLL languages, including Perl. ...and we have a working example of what a bad idea that is with XSLT. XSLT is a good idea in *it's* domain, but very bad for a general purpose programming language. This would supposedly allow programmers to embed drawings as documentation as well as solve the age-old tab-setting and brace-style dilemas. XSLT allows multiple XML vocabularies to be intermingled (and possibly ignored) in the same stylesheet (er, program). And it renders the other holy wars meaningless, too. Sure, program XSLT in XML. I guess that makes about as much sense as XSLT is ever going to. My question is, if you think programming Perl in XML is such a good idea, why not do it? Who said programming Perl in XML was a good idea? All of the benefits are of programming in XML are available with XSLT, and they appear to be of dubious value (modulo domain specific requirements). If you think my answer is a straw man argument, then what's yours? What's your question? XML Editors are not the limiting factor preventing XML-based programming languages; that argument doesn't stand up in the face of XSLT adoption. The dubious value of those beneifits (and the re-engineering cost) are the true limiting factors. Z.
Re: Perl, the new generation
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 make the transition from Attic Greek to Koine without changing how people fundamentally view their language. Apocalypse two made me a believer. There's language and then there's language. Is English the same language it was 50 years ago? No, but it's substantially similar, and all of the old thoughts are still parsable and comprehendable. The reverse isn't strictly true. This isn't about an instant transition from Attic to Koine Greek. It's more like an opportunity for accelerated translation from Frank Sinatra to Trent Reznor. But if you prefer Frank and despise the noise taking his place, that's fine too -- Frank's not going anywhere. In that respect, Perl6 will be very much the same language, +/- a few kiloconways[*] from where we are today, if you want it. :-) Z. [*] conway: unit of mind expansion. One Conway == ~20 lines of Perl code found in $CPAN/authors/id/D/DC/DCONWAY, which gives the sensation of your brain being wrapped around a brick, with kiwi juice squeezed on top.
Re: Larry's Apocalypse 1
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:? callto:? uuid:? If Rebol can handle all of those URL schemes, why bother with Perl in the first place? I don't know if this is something we want to follow Rebol's lead on, but it's something to look at. Sounds like if there's a 'use url;' clause in use, then the standard three (mailto:, http:, ftp:) might be available, whereas other URL schemes would need different declarations (use url::dns;). Z.
Re: Schwartzian Transform
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 insert name here transform is a specialized case of the schwartzian transform where the default sort is sufficient. Address the issues with the general case, and the specialized case is handled as well. Z.
Re: Schwartzian Transform
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($a) = f($b) } @t would Do The Right
SC Thing.
because that would require the PSI::ESP module which isn't working
yet.
Not at all. Simon's example looks like a simple case of memoization.
The cache only needs to be maintained for the duration of the sort,
and it alleviates the need for complicated map{} operations.
how would perl intuit exactly the relationship between the records
and the keys extraction and comparison?
The key extraction is done with f(), and the comparison is done
with cached values of f().
Z.
Re: TIL redux (was Re: What will the Perl6 code name be?)
On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote:
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC I can't make this make any sense. Could you try again?
well, you should have been on the lists when this was being hammered
around.
OK. I don't remember this being hammered around though.
basically the emitted machine code for TIL is very simplified C
routine calls and their argument setup and return. all the routine calls
are to perl ops with just the minimal stack glue code in between them.
So you're talking about using a Forth style compiler to thread the
opcodes together.
Unfortunately, there's a slight problem with that:
*main::localtime = \replacement;
memoize("factorial");
Once you've threaded the sub calls together, 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 Wall [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Threaded Perl bytecode (was: Re: stackless python)
In-Reply-To: [EMAIL PROTECTED]
(from Adam Turoff on Sun, 22 Oct 2000 20:10:34 -0400)
Sender: [EMAIL PROTECTED]
Status: RO
Content-Length: 364
Lines: 9
Adam Turoff writes:
: If Perl bytecode were to become threaded, it would be rather troublesome.
Wasn't actually suggesting it, though similar issues also arise for
compiling down to efficient C, JVM, or C# IL. Optimizing for Least
Surprise means different things in different contexts, but I'd hate
for Perl 6 to be astonishingly slow at anything... :-)
Larry
Hope this helps.
Z.
Re: TIL redux (was Re: What will the Perl6 code name be?)
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 you've gone through the effort to thread it in the first place. If you're going to have indirect lookups, keep it localized. Adding the "simple dispatch table" is adding more instructions (and memory fetches, and cache flushes) where they're not needed, making the optimization run slower than what it was trying to optimize. Perl is just too dynamic to use threaded bytecode out of the box. I'm with Dan. Make it an optional runtime for everyone who *chooses* to live within the confines of threaded bytecode. It shouldn't be the default runtime model because it is too broken. Remember what Knuth said: premature optimization is the root of all evil. Z.
Re: Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))
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 generated code. Hard numbers, please. Z.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
[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 can (or could) submit RFCs that contradict it, if they want to. The author is no more obliged to include opposing opinions in Not obliged, no. But not recording opposing views is like sticking fingers in your ears and loudly chanting 'la la la la, my proposal is good, pure and uncontested, la la la, la la la...' RFC Improvement #1: All updated RFCs must contain a CHANGES section. RFC Improvement #2: All updated RFCs must contain a synopsis of relevant discussion, including opposing views. RFC Improvement #3: All final RFCs must contain a discussion of why they are finalized. RFC Improvement #4: Each working group may define more stringent acceptance criteria for RFCs. -licensing doesn't care about including test plans, and -qa doesn't care about redistribution considerations. RFC Improvement #5: An working grouup chair can cause an RFC to be withdrawn from condideration if it is off-topic or simply rehashing old issues. This is to keep the brainstorm-to-proposal ratio close to zero when rampant brainstorming is not desired. Any others? There are bugs in the RFC process. Now is the time to fix them. A modified RFC process should be in place for Perl6, where it fits. And it should not be a process that generates 150+submissions/month of wildly varying quality. Z.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
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 enough detail what is the problem they are trying to solve, RFC Improvement #6: Every RFC must contain a brief background describing the problem in enough detail for readers to understand what this RFC proposes to solve. Conciseness is preferred. Links to extended discussions are appreciated. but instead go ahead and pull new/backward-incompatible syntax and/or keywords and/or semantics out of thin air. I hope we're done the first phase of RFC submissions, that aspect of RFC submissions should be behind us. Call me an old curmudgeon Jarkko, you're an old curmudgeon. but some words towards backward compatibility, keeping proposed changes as small and generic as possible (I think that's one of things that epitomises perl: lots of cleverly interlocking small features or feature sets) would have been nice before the launch of the RFC process. RFC Improvement #7: Every RFC must contain a discussion of migration and backwards compatibility, as appropriate. This includes non-internals areas such as licensing. New areas of effort may be excluded[*]. Keeping RFCs current is another bug in the process. Here's a possible fix: RFC Improvement #8: RFCs are patchable. This is to encourage RFCs to be kept up to date with a synopsis of discussion about a proposal, especially when the maintainer is too busy to keep updating an RFC. Process TBD. Z. *: OK, so we're losing formats, but Damian shouldn't need to write a backwards compatibility dissertation for each and every new extension to formats he comes up with (even though he could). Ditto on 'use Notation::Polish::Reverse;'
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
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. Agreeing to disagree about this is like agreeign to implement Perl with three parts C, two parts Eiffel, two parts Python and one part Objective C. TMTOWTDI can't always be invoked simply because this project is named Perl. Or must all people who believe XML is easier to write and maintain leave the room? There are huge cultural, technical and practical limitations for Perl to adopt XML as a documentation syntax, or code all docs in =xml...=cut blocks. If you want to use XML, Latex, Texinfo or raw *roff for your docs, then by all means do so. Understand that Perl can't be made to magically ignore embedded Texinfo, and Perl contributors realistically can't be made to understand/patch/correct multiple markup formats. This is why we invented POD. This is why we use POD. Horror of horrors: why not support both? Long live: TMTOWTDI. If XML documentation fails to thrive, cut it from Perl 6.1. XML docs *have* failed to thrive among those who document Perl. They have failed to thrive among that group for over two years, especially since all that's missing is someone thinking about a definitive POD-XML conversion. (Sorry, I'd chip in, but I'm a little busy this week.) That is an excellent description of why THIS IS COMPLETE MADNESS. Being able to parse for well-definedness, DTD validation, and schema constraints are postive things. And none of them *require* XML. There's no reason why POD can't be well-defined, validated and schema correct. Z.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
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, instead of using POD. XML has many advantages over POD, and would address several problems POD is reaching as it expands beyond its original designs. POD has three mighty significant advantages over XML: - it is easy to learn - it is to write - it is easy to ignore, if you're spelunking for Perl code Try and do that, when body interferes with STDIN syntactically. DocBook, my doctype of choice, comes with a handy-dandy 600 page reference. Terms like %qandaset.mix; and "entity reference" are far from easy to understand to the beginner. Especially when compared to '=head1' and '=head2'. =head1 DESCRIPTION However, POD can be confusing to learn, and has many limitations. These are deficiencies in the POD language definition and the POD toolchain. It can be fixed by tweaking the definition of POD and writing better tools. It's not a reason to throw out POD entirely because something more hyped is available to replace it. XML, on the other hand, is a document language that is designed for high extensibility, and little ambiguity. XML is flexible, relying on Document Type Definitions, DTD's, (recently, also XML Schemas), which define the document structure being used by the author. For example, a copy of the DTD for XHTML may be found at Chttp://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd. You must be kidding if you're seriously recommending XHTML as a replacement for POD. POD has many flaws (and I'd list them if I had the time right now), but at the very least it provides a modicum of structural markup. Moving to XHTML is one huge step backwards, because it is presentational markup instead of structural markup. XHTML+CSS as a structural model is a sick joke. Moving to any XML based markup today should make it stupidly easy to target DocBook and DockBook's structural model directly. And it should do so with a minimum of pain to the author. Knowledge of how to write or work with DTD's is not necessary for an XML-author; the author need only know the effect of the DTD or XML Schema. [...] POD has the advantage in that it has syntax that is quick and easy to type, such as CElt$var++Egt instead of an XML/XHTML EltcodeEgtvar++EltcodeEgt. However, author effort pays off immensely on the reader's end. Moving towards a system that adds any friction to the documentation process is a *HUGE* mistake. XML adds more friction to the authoring process by refusing malformed documents, while POD complains and muddles forward, typically formatting them poorly but still rendering. Increasing author effort may make for more beautiful documentation for the reader, but it also inhibits authoring content in the first place. It's quite possible that switching to an XML docset produces a beautiful, unmaintained set of documentation that is of no use to anyone. The answer is to fix POD, fix the tools, not to use XML. Z.
Re: RFC 288 (v1) First-Class CGI Support
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 feature I never ever use. I repeat: All of the other features offered by Lincoln Stein's CGI.pm should remain, but should not be deeply integrated into Perl6. ^^^ :-) The proposed 'use cgi;' pragma is concerned with gluing Perl into a cgi context. No more, no less. That's why %CGI and taint are important (and the http headers from Nate's RFC), and everything else is more heavyweight and placed elsewhere (e.g. CGI.pm, CGI::*.pm). I'm open to suggestions if the nominclature/distinction is too confusing. Z.
Re: RFC 288 (v2) First-Class CGI Support
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 within two days doesn't leave much space for comments and or objections does it? Retractions are still possible with frozen RFCs. Minor revisions and clarifications are still acceptable for frozen RFCs. The intent of this RFC seems clearly stated. That, and the discussion I saw seemed to have fleshed out the major issues, and was getting bogged down in trivia (e.g. embperl). I'm not against making things easier in general, but I don't want perl to be Just Another Web Service. I've started an RFC on that when perl6 just started, but I saw discussions take a good direction, so I didn't post it. Please post it. Or something along the lines of what you were thinking. I think this one belongs in perl6-stdlib, certainly not in the perl6-core! Probably. But it has interaction with taint mode, which is also something of an internals issue. And there are some minor language design issues, like making %CGI become the equivalent of %ENV and making taint mode manditory (unless it's REEELY not wanted). One strike against -stdlib, is that the standard library has CGI.pm already, and this is a plea for a more standard, less feature-bloated module that could easily be reused for all of the CGI output interfaces. Z.
Re: RFC 290 (v1) Remove -X
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 work on scalars. Unless every scalar should have a 'readable()' method *just in case* it could contain a filename. Not sure I like that. I just drafted a set of methods. The basic problem is -e = exists(), and -S = socket(), which are already taken. I didn't like the idea of -e = present(), and I couldn't think of a synonym for exists that begins with 'e', nor a synonym for socket that begins with 's'. :-) If that isn't enough, I think we all forgot about thie difference between -r and -R, which *really confuses things. Is one of them more readable than the other? It's late, and I'm just going through another revision of 4 of my last 5, and I went with f*() and F*() for the -RWX. Not as bad as filetest::readable() filetest::really_readable() filetest::exists() filetest::socket() ... Update to be posted as soon as the left hand finds out what the right hand was doing... Z.
Re: RFC 290 (v2) Better english names for -X
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 Fwriteable() PRL -X Fexecable() PRL -O Fowned() this looks decent to me. Well, it leaves readable for AIO callbacks, so of course you're going to say that. :-) I reserve the right to switch to readable/writeable iff the socket/exists issue has a resolution. Thoughts anyone? maybe make the prefix f_ to make it a little more readable (overriding that word again! :)? I can't think of any builtins that use _, but it's going to be exposed by use english, so perhaps that qualifies it. I'm on the fence though. If it's going to be *_writeable, is_writable() looks better. It is tom's original proposal, after all. also f/Fexecable() looks very odd. Patches welcome for f/F. is that your choice or were your right and left hands fighting again? executable is probably the better term and who cares about 2 chars more if you are using this. No, I chose execable intentionally. Probably change it to executable in v3 anyway. Z.
Re: RFC 288 (v2) First-Class CGI Support
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.
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
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 write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. Z.
Re: Expunge use English from Perl?
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 improve Perl syntax, since it's one less way to do things with already dubious value. A lot of use English has to do with aliasing global variable linenoise, which is already going away. For instance, $/ is becoming per-handle, and $: (?) is probably going away because it has nasty action-at-a-distance properties, and FORTRAN programmers never use it to offset the zero-index to one. (Abigail uses it to make japhs that bizarrely store the number 17.) It has nothing to do with improving the syntax though, because everything in use English is a variable that serves as a reference to some other variable. I'm not vehemently opposed to "use English", or even the long alternatives to -r and -w that RFC 290 proposes. But I do think, truthfully: 1. They don't solve the real syntactic problems No, because the syntactic problems are -s(FH)/2, and that is solved by fsize(FH)/2 iff -s is replaced with fsize (or a better spelling thereof). 2. Very few people will ever use them long-term I dunno. I remember looking at some code that used '-x _' that had half a department befuddled. -rwx FH is better, and gets rid of the special case bare _ syntax. Z.
Re: RFC 288 (v1) First-Class CGI Support
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 necessary but nothing more." Taint mode is necessary, and half the reason for this proposal. That should make it faster than it is today (ms) and faster than it is today in mod_perl (us). I do like the idea of stacking HTTP headers and queueing them up before the first print statement, where that print is a little more magical than every subsequent print. I'd imagine that if the HTTP headers were blank, it would Do The Right Thing (tm) and emit a "Content-type: text/html\n\n", before replacing itself with the standard print builtin. This would be useful. I'd be more inclined to have it with the CGI module though. But then, it would need to be an option since sometimes programs use CGI bits and pieces but don't run in a CGI context (such as mod_perl scripts, and the odd script I have for generating semi-static documents). This has nothing to do with CGI context. Robust input parsing: yes. General purpose output formatting: no, [...] Rudimentary HTTP header emission: probably. I think it all belongs in the CGI module really. Then you're probably against this proposal. No biggie. The assorted Apache modules (and HTML::Embperl and similar) and the CGI module really do provide proper facilities for CGI operations. Having "rudimentary" features in the core would be duplication and hence a waste. Even if the core implementations were so lightweight that they could be reused as-is across all the other modules? Z.
Re: RFC 288 (v1) First-Class CGI Support
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? Have you read the message you're quoting here? In full? In context? Here's the abstract again: 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. For the purposes of this discussion *this* is what first class means. As I've said before, first-class CGI to me means a language where I can focus on the HTML or XML I am creating. An example of a first-class CGI language is ASP or my beloved HTML::Embperl. I don't bother with CGI anymore, and when I did I was content with CGI.pm. Have you been reading this thread? I've already said in at least one occasion that playing favorites between embperl, mason, template toolkit, text::template, Format, autoformat, xml::writer and such is *NOT* the intent of this RFC. Please stop inferring that this should be a way of getting *your* own *personal* favorite CGI module included into the core, especially when you say later it wouldn't make sense. I'm not saying any of that. It seems like we are talking about pulling some functions from a module to the core. And for no real good reason. Is query string parsing or header processing so time consuming that it must be implemented in C? It seems you are mistaken. We are not talking about implementing string or header processing in C. Please re-read this thread. For any sizeable application input and headers will not be enough. You'll need cookies and redirection certainly. At which point you will load CGI.pm anyway (if you are bothering to create this in classic CGI). Please re-read the CGI specification as well. Cookies and redirection are both HTTP headers, and do not require loading CGI.pm. Z.
Re: RFC 290 (v1) Remove -X
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 english "filetests";'
But I wouldn't want that pragma to override any other aspect of the
core library, such as async I/O.
also i think a common
prefix idea is still valid as it will make it more apparent that these
are from the file test family.
That's a stone's throw awaty from:
import english
from english import filetest
result = filetest.readable("/dev/null")
I think the common prefix idea is a nonstarter. There must be a way
to coming up with sensible names for all of -X that don't conflict
with the core library. Besides, AIO has a requirement on
'sub Foo::readable()', which means that main::readable is still
accessible and doesn't conflict. No, that's not desirable, but AIO
behavior looks more malleable to me.
i have not seen an attempt to name all of
the -X ops yet.
v2 fast approaching. ;-)
Z.
Re: RFC 287 (v1) Improve Perl Persistance
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's TMTOWTDI. On the other hand, there's overly complicating things with a maze of twisty, turny modules, mostly alike. I'm not arguing against TMTOWTDI. I'm arguing that what we have isn't making easy things easy, but actually inadvertantly making easy things harder than they should be. Different people might have different requirements. Portability would want all ASCII, large apps might want compacted (if not compressed) storage, while others might want highly-efficient storage. No complaints. Why do they need to be provided by mutually exclusive sets of modules? You might want to extend this RFC to include information about existing serialization techniques (which tend to be more sophisticated than raw dumping of a data-structure). Actually, I don't. The *DBM_File modules work, as do Data::Dumper and its kin. This RFC is a request to improve the interoperability of those modules, not implement any of them from scratch. Z.
Re: RFC 288 (v1) First-Class CGI Support
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 context, returning CGI variables into %CGI
This is a little vague, will it parse $ENV{'QUERY_STRING'}, look for
content on STDIN controlled by $ENV{'CONTENT_LENGTH'}, Cookies, the command
line? Or all of them.
All of them. Update forthcoming.
Will it handle multipart input? How will it
handle multiple inputs of the same name? etc etc.
CGI.pm has solved these problems already. I don't see these as major
issues in the feature request, just the poor wording of the RFC. ;-)
Offer simple functions to set HTTP headers (e.g. content type, result
codes)
Will there be access to do more - eg to control caching, cookies etc, will
it be optional?
All of these are handled through HTTP headers. I'll leave the
syntactical sugar to the designers and implementers of this interface.
Z.
Re: RFC 288 (v1) First-Class CGI Support
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 (nearly?) always require locking in a CGI environment... That is, should this feature do anything with regards to file locking? My first instinct is to say no. There is nothing inherent about file locking and CGI. CGI is a dain-bread interface for running insecure^Wremote programs. If, however, there was some sort of 'use autolock' or 'use writelock' pragma, then I suppose it would be sensible turn that on with 'use cgi' or 'perl -cgi'. Make sense? Z.
Re: RFC 288 (v1) First-Class CGI Support
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? Should I get an autoformatter configured for my (unicode) locale? What about CGI.pm style table() and br() functions? Text::Template? Template Toolkit? HTML::Mason? That's a bigger problem to solve and unrelated to making Perl bind tighter to CGI invocation. Z.
Re: RFC 288 (v1) First-Class CGI Support
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, HTML::Mason, etc. First class CGI support means binding Perl as tighly to CGI invocation as it is to commandline invocation. Z.
Perl6Storm: Intent to RFC #0000
I plan to offer a more formal RFC of this idea. Z. =item perl6storm # This: ($a,$b) = FH; should not drain whole ahndle on known LHS count, to rescue my($x) = FH;
Perl6Storm: Intent to RFC #0022
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?
Perl6Storm: Intent to RFC #0025
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 what they mean, to disable tainting instead.
Perl6Storm: Intent to RFC #0026
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.
Perl6Storm: Intent to RFC #0043
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?
Perl6Storm: Intent to RFC #0101
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 -s(FH)/2 style parsing bugs and prototype issues on handles vs paths.
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easy programming
On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote: On Tue, 19 Sep 2000, Nathan Wiger wrote: And then there's the lexical variable issue too: The default variable scope rules for Ruby (default: local) are much better suited for medium-to-large scale programming tasks; no "my, my, my" proliferation is needed for safe Ruby programming Actually, this is the bit that interests me. Most times, when you create a variable, you *do* want local scope. Really? You want a brand new $foo inside a while loop, distinct from the one inside the surrounding sub? That is lost when the while loop terminates? I think I would be guardedly in favor of changing the default scope from global to local (although I have the feeling there is something I'm not considering). What does everyone else think? Sounds like a really bad idea. That's one of the reasons why people tend to hate tcl: everything is 'upvar' this and 'upvar' that to go up one level of scope. Z.
Re: we might as well give up now: CobolScript(R)
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, but I've never used COBOL. :-) A CGI based DNS resolver in only 117 lines. We *must* be doing something wrong: [...] 96 * Display all hostent-address elements from inside inline PERFORM loop 97 PERFORM VARYING counter FROM 1 BY 1 UNTIL counter 8 98 DISPLAY `TR BGCOLOR="lightblue"` 99 DISPLAY `TDTCPIP-HOSTENT-ADDRESS(`counter`): /TD` 000100 DISPLAY `TD`TCPIP-HOSTENT-ADDRESS(counter)` /TD` 000101 DISPLAY `/TR` 000102 END-PERFORM. [...] Looks like Perl goofed up bigtime with 1 statement per line, and simple scalar interpolation. Z.
