Re: The C Comma

[Adam Turoff]

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.
> 
> Perhaps this is yet another argument for insisting on:
> 
>   while do {$n++; $foo > $bar}
> 
> instead.

That looks like syntactic sugar for 

while (do) {$n++; $foo > $bar}

and could be interpreted as either:

while "do" {...}  ## perl5 bareword
while do() {...}

Luke's "then" feels like the best fit on the one hand, and the worst fit 
on the other.  Everything else feels worse, though.

Z.

Re: Dispatching, Multimethods and the like

[Adam Turoff]

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.

Re: Dispatching, Multimethods and the like

[Adam Turoff]

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.

Dispatching, Multimethods and the like

[Adam Turoff]

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

[Adam Turoff]

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?

[Adam Turoff]

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.

Re: Multimethod dispatch?

[Adam Turoff]

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.

Multimethod dispatch?

[Adam Turoff]

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?

[Adam Turoff]

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

[Adam Turoff]

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 :-)

[Adam Turoff]

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"

[Adam Turoff]

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: "Arc: An Unfinished Dialect of Lisp"

[Adam Turoff]

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: REs as generators

[Adam Turoff]

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: Multmethods by arg-value

[Adam Turoff]

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: Partially Memoized Functions

[Adam Turoff]

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: Partially Memoized Functions

[Adam Turoff]

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

[Adam Turoff]

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

[Adam Turoff]

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

[Adam Turoff]

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 edge cases which require calculation; or the
> function is liable to be called with many invalid input values, which
> can quickly be determined yield C 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?

[Adam Turoff]

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

[Adam Turoff]

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?

[Adam Turoff]

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

[Adam Turoff]

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.

Re: http://www.ora.com/news/vhll_1299.html

[Adam Turoff]

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: http://www.ora.com/news/vhll_1299.html

[Adam Turoff]

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 (, , 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: Perl, the new generation

[Adam Turoff]

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

[Adam Turoff]

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

[Adam Turoff]

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: Schwartzian Transform

[Adam Turoff]

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 issues with the general case, and the specialized case
is handled as well.

Z.

Re: Schwartzian Transform

[Adam Turoff]

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 = 
> map  { $_->[0] }
> sort { $a->[1] <=> $b->[1] }
> map  { [ $_, /num:(\d+)/ ] }
>   @t;
> 
> would be more clearly written as
> 
>   @s = schwartzian(
> {
>   second_map  => sub { $_->[0] },
>   the_sort=> sub { $a->[1] <=> $b->[1] },
>   first_map   => sub { [ $_, /num:(\d+)/ ] },
> },
> @t );
> 
> ???

Which part of "not ... an intent to ... specify a syntax" didn't 
you understand?

And, no, I don't think that verbosity is an improvement, nor do I
remember recommending newbie-confounding syntax with verbosity.  

Z.

Schwartzian Transform

[Adam Turoff]

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 be incredibly useful.

We're all for making easy things easy, but the complexities of
"map {} sort {} map {} @list" has always been befuddling to newbies,
especially when reading the code left-to-right.

Loooking over dev.perl.org/rfc, only two RFCs mention sorting:
RFC 124: Sort order for any hash
RFC 304: sort algorithm to be selectable at compile time

and none mentioning the Schwartz.  :-)


This message is not an RFC, nor is it an intent to add a feature 
to Perl or specify a syntax for that feature[*].  I just posted it to
get the idea into the archives as a (possibly) useful way to improve Perl.

>From a cursory glance, it didn't seem to have been mentioned yet in the
discussions about Perl6. (Please correct me if I'm wrong here.)

Z.

*: There are still 4 months until TPC5.  Damian may have a source
   filter to do this by then.  :-) :-)

Re: Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))

[Adam Turoff]

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: TIL redux (was Re: What will the Perl6 code name be?)

[Adam Turoff]

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: TIL redux (was Re: What will the Perl6 code name be?)

[Adam Turoff]

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: RFC 357 (v2) Perl should use XML for documentation instead of POD

[Adam Turoff]

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 the rest of us mortals.

Z.

Re: RFC 357 (v2) Perl should use XML for documentation instead of POD

[Adam Turoff]

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 (v2) Perl should use XML for documentation instead of POD

[Adam Turoff]

[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

[Adam Turoff]

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 developers we have yet to meet, and some core
developers who have yet to look at the Perl sources.  For future
contributors, retracted RFCs demonstrate why some ideas are incredibly
unperlish.  And that helps keep Perl perlish, instead of adopting 
every feature from every other language out there simply because
they exist.

Z.

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Adam Turoff]

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

[Adam Turoff]

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 what the
> user will probably already know, as covered in the RFC.

Who needs to learn it, the user or the module author?

The benefit of POD is more focused on the module author, leaving the
use a minorly strange markup language to be read.  POD is intended
to be read as-is as a last case measure.  Presumably, users will
be reading -man or HTML rendered versions of the docs and can also
read the raw docs pretty easily if need be.

> >   - it is easy to write
> 
> True, but XML is not hard to write; if you want, you could make a real
> simple DTD with very small tags.

Then you're advocating a small XML DTD, not XML.  Advocating raw
XML using a hypothetically small DTD is misleading.  Advocating a 
hypothetically small DTD and calling it XML is equally misleading.

Two of POD's deficiencies are list handling and table handling.  POD
doesn't handle tables right now, but calling this easy to write
or easy to read is ludicrous:


 
  Column 1
  Column 2
  Column 3
 
 
  Item1a
  Item1b
  Item1c
 
 
  Item2a
  Item2b
  Item2c
 


That was [X]HTML.  Here's an unordered list in DocBook:


 
  
   Element 1
  
 
 
  
   Element 2
  
 
 
  
   Element 3
  
 


I think POD's list handling is full of warts, but what follows
is much better than HTML/DocBook itemized lists:

=over 4

=item *

Element 1

=item *

Element 2

=item *

Element 3

=back

> >   - it is easy to ignore, if you're spelunking for Perl code
> > Try and do that, when  interferes with  syntactically.
> 
> No reason there couldn't be a perl-style delimiter, with __*__.

Perl already understands =foo...=cut.

> > 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'.
> 
> I'm not supporting DocBook.  The concept of foo, I would guess,
> is not that hard to grasp.  

And Google has an index of over 1 Billion pages where the semantic
meaning of H1 is most likely ignored.

> Furthermore, the same syntax is used
> consistently throughout the document; there is no separate syntax between
> 'headers' and 'body'.

One of the problems with POD is that it separates block markup from
inline markup.

One of the benefits of POD is that it separates block markup from 
inline markup.  This is the clearest way of distinguising semantic
structure from presentation.  =head1 is not equivalent to 
but rather DocBook's ... start block.
section tags aren't as easily abused as H1 tags for REEELY BIG LETTERS.

True, C<> and E<> are pretty warty, but they clearly identify 
something more presentational in nature.

> As covered, I'm worried POD will continually outgrow it's original design,
> and become messier and messier.

Then help work on a POD-NextGeneration that still adheres to the P
in POD.

> > You must be kidding if you're seriously recommending XHTML as a 
> > replacement for POD.
> 
> I never stated I specifically supported using XHTML over pod; it was just
> an example of a DTD.

It's also an example of soemthing that's far from small as DTDs go.

> > Moving towards a system that adds any friction to the documentation
> > process is a *>HUGE<* mistake.
> 
> If this is a valid argument, then why not just use comments insetad of
> POD?  XML does require some more work, granted.  But it pays off.

Comments don't provide enough context for embedded documentation.  POD
does.

XML creates too much friction compared to the status quo when it
comes to getting authors to write docs.  POD *is* the status quo
and therefore isn't adding *more* friction to the process.  

Perhaps I should have stated that more clearly.

Z.

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Adam Turoff]

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  interferes with  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
> C.  

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 CE$var++E instead of an XML/XHTML
> EcodeEvar++EcodeE.
> 
> 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

[Adam Turoff]

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

[Adam Turoff]

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: Expunge "use English" from Perl?

[Adam Turoff]

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: Expunge "use English" from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

[Adam Turoff]

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: RFC 288 (v2) First-Class CGI Support

[Adam Turoff]

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 invoked by cgi) would make more sense to me.  I'd be in
favor of a new RFC.  Adding it into cgi sounds like we're on the
road to spontaneously reinventing CGI.pm...

It has uses in HTTP, CGI and SMTP contexts, probably others.  Would
be nice if there were some sort of interaction with 'open http $url' as
well.   Perhaps that would be what supplies %HTTP (or %HEADERS) for
incoming headers and does trickery with print and @HEADERS...

Z.

Re: RFC 288 (v2) First-Class CGI Support

[Adam Turoff]

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: RFC 290 (v2) Better english names for -X

[Adam Turoff]

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 290 (v1) Remove -X

[Adam Turoff]

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 (v1) Remove -X

[Adam Turoff]

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 290 (v1) Remove -X

[Adam Turoff]

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'.
> 
> 
> i have a minor problem with the names readable and writeable. i am
> currently using them as method names in a major project i have
> created. they are callbacks (see my recent callback rfc) which mean the
> socket is readable/writeable. maybe put some sort of prefix on them to
> designate them as file test operators so we don't clutter up the
> namespace so much. 

I don't think so.  The file test operators should be generalizeable
across all input channels, including sockets.  Their synonyms should
be as well.  See RFC 239 for details.

I'm actually less concerned that readable() and writeable() enter the
core grammar as much as I'm concerned that they're easy to find
intelligently named across the board.  On the one hand, they could
be integrated into RFC239 for filehandles.  On the other hand,
RFC239 doesn't address object interfaces on filenames.

Maybe it'll be easier to rename the callbacks?  They're common
names with easily overloaded meanings, and should be reserved
for the most common usage.

Z.

Re: RFC 288 (v1) First-Class CGI Support

[Adam Turoff]

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 288 (v1) First-Class CGI Support

[Adam Turoff]

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

[Adam Turoff]

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?
> 
>$CGI{fullname} = 'Nathan Wiger';
>$CGI{creditcard} = '1234-1234-1234-1234';
> 
> I'm 99% sure that's what you're saying. And I like it. :-) 

Yes.  More like $CGI{...} eq "...", since they're set from the CGI
environment.  :-)

> One thing that %HTTP could be used for is _incoming_ headers - for
> example, 'If-Modified-Since', 'Set-Cookie', and others that a browser
> throws at you. These don't go in %ENV and wouldn't belong in %CGI.

Good point.

> > I think I'd prefer an exported function like:
> > 
> > http_header("Content-type" => "text/html");
> > http_header("Expires" => "+3 Days");
> > 
> > or whatever.  Then it's an implementation issue to figure out
> > which headers are overridable, and which headers should appear
> > multiple times.
> 
> For output, that's probably better. However, this is treading a line
> between a pragma and a lightweight module. :-{
>
> If it imports a function, then it's a module. Perhaps what we should
> look at doing is providing a lightweight CGI module instead? 

That loses half of the intent, which is automagically turning on
tainting (before it's too late to turn it on) along with setting up
a Perl program to process CGI variables.  Then taint mode needs
to be explictly turned off rather than turned on for the default
CGI program.

The http_header() is a straw man intended to demonstrate that there
are issues with shoving all of the outgoing HTTP headers into a simple
variable.  Not insoluable problems, but problems.

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.  

And if HTTP headers are segregated from document content, it's
easier to determine when the headers are finished and when the
content starts.  That aids in determining when '\n\n' is appropriate.

> > The idea of flushing on the first print call isn't too difficult
> > and kinda cool.  That way, http_header() could flag a warning if
> > the user is trying to set a header after the header is done.
> 
> Yeah, I think that would be cool, *if* we take care of this. But I think
> it's a slippery slope.  [...]

OK, then draw a line in the sand where it's not so slippery. :-)

> I think we should provide robust input parsing,
> but just general purpose output formatting tools.

Robust input parsing: yes.

General purpose output formatting: no, nyet, nein, non, "over my dead body".

Rudimentary HTTP header emission: probably.

Z.

Re: RFC 290 (v1) Remove -X

[Adam Turoff]

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 shell
> > programming background, and the -X syntax is opaque and bizarre.
> > It should be removed.
> 
> No!  Gratuituous removal of syntax is anti-Perl.  Perl is about
> providing options, not taking them away.

Well, at least I succeeded in generating fruitful discussion.  :-)

Making '@permissions = -rwx $filename;' work is an interesting new
suggestion.

Of course, I should say that I've been hanging out with some
snake-hearders recently.  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'.

Z.

Re: RFC 288 (v1) First-Class CGI Support

[Adam Turoff]

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, returning CGI variables into %CGI
> 
> Which variables are you talking about? Everything you need is already in
> %ENV, as I'm sure you're aware.
> 
> If you're talking about splitting up the query string, then this should
> be stated explicitly. And I think %CGI is a fine place for this. Will it
> be quotemeta'ed?

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.

That removes the ambiguity of query strings coming into %CGI, while 
environment variables are shoved into %ENV (something rather obscure
by comparison).

> > Offer simple functions to set HTTP headers (e.g. content type, result codes)
> 
> How about %HTTP, which is just flushed on the first line of output?
> 
>use cgi;
>$HTTP{'Content-type'} = 'text/html';
>print "Hello!"; # flushes %HTTP first
> 
> Just one idea. 

HTTP headers is tricky.  It's reasonably easy to figure out when
there are multiple form values in a request.  It's less easy to 
figure out when a program has finished emitting values for a
specific header type.

I think I'd prefer an exported function like:

http_header("Content-type" => "text/html");
http_header("Expires" => "+3 Days");

or whatever.  Then it's an implementation issue to figure out
which headers are overridable, and which headers should appear
multiple times.  

The idea of flushing on the first print call isn't too difficult
and kinda cool.  That way, http_header() could flag a warning if
the user is trying to set a header after the header is done.
 
> The RFC should just be a little more specific on what's being included
> and not included. Are any of the functions like header(), h2(),
> footer()? 

None of those.  I'm preparing an update to make this stated more
explicitly.

Z.

Re: RFC 288 (v1) First-Class CGI Support

[Adam Turoff]

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.

Re: RFC 288 (v1) First-Class CGI Support

[Adam Turoff]

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

[Adam Turoff]

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

[Adam Turoff]

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 287 (v1) Improve Perl Persistance

[Adam Turoff]

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.

Perl6Storm: Intent to RFC #0101

[Adam Turoff]

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.

Perl6Storm: Intent to RFC #0043

[Adam Turoff]

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 #0026

[Adam Turoff]

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 #0025

[Adam Turoff]

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 #0004

[Adam Turoff]

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.

Perl6Storm: Intent to RFC #0022

[Adam Turoff]

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 #0000

[Adam Turoff]

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) = ;

Re: RFC 227 (v1) Extend the window to turn on taint mode

[Adam Turoff]

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 -internals, but early on in
> perl6-language I suggested something similar, and Larry dropped some
> major knowledge on me about tainting:
> 
> http://www.mail-archive.com/perl6-language@perl.org/msg00394.html
> 
> I'd advise everyone read the above. Adding a $TAINT
> variable/pragma/whatever is, basically, a Bad Idea. 

The hypothetical taint.pm/taint.xs that was being discussed was in
a different context.

The taint pragma that we were talking about is not about lexical
scoping of taint mode, but rather a sensible place to add taint(),
tainted() and similar functions that need specific knowledge of
core internals.

Of couse, if the core language contains taint() and untainted(), then
this is a trivial discussion.  We were looking at it from an internals
perspective, with the POV that it may not be a core language feature.

taint() and tainted() would work on scalars that may or may not
be coming from a trustworthy source.  untaint() should *not* be
one of these functions, because untainting should remain hard 
(i.e., you should have to think about what you're doing).

This is a discussion that may result in a different RFC altogether.
It came up because RFC 227 discusses tainting.

-language is probably not the right forum for either.  I vote for
starting a new thread in -stdlib.

Z.

Re: we might as well give up now: CobolScript(R)

[Adam Turoff]

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 ``
99   DISPLAY `TCPIP-HOSTENT-ADDRESS(`  &  counter  &  `): `
000100   DISPLAY ``  &  TCPIP-HOSTENT-ADDRESS(counter)  &  ` `
000101   DISPLAY ``
000102   END-PERFORM.
[...]

Looks like Perl goofed up bigtime with <1 statement per line, and 
simple scalar interpolation.

Z.