Re: my and local

[Adam]

On Thu, 28 Sep 2000, Steve Fink wrote:
> Tom Christiansen wrote:
> > 
> > As we sneak under the wire here, I'm hoping someone
> > has posted an RFC that alters the meaning of my/local.
> > It's very hard to explain as is.  my is fine, but local
> > should be changed to something like "temporary" (yes, that
> > is supposed to be annoying to type) or "dynamic".
> 
> my's runtime/compile-time schizophrenia is rather bizarre too. I'd like
> 
> my $x if 0;
> 
> to be equivalent to
> 
> my $x;
> 
Why? Do you mean that you want $x to be created/instantiated even if the
boolean clause is false (but could have been true)? In an if/then blcok
the scalar would be scoped locally and so would be irrelevant if the
boolean clause evaluated evaluated to false. As it is, it is kind of
strange that the scope of $x in your statement isn't bound in the if/then
structure.

-Adam

btw: I am guessing that you usually write that 
my $x = $y if 0/1;

Which could be done slighlty safer
my $x = 0/1 ? $y : 0; # or undef

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.

Re: RFC 76 (v1) Builtin: reduce

[Adam Krolnik]

Following the lead of the sort operator, it would be a little
simpler to see reduce expressions use $a and $b instead of
$_[0], $_[1].

E.g.

Summation:

 $sum = reduce{$a + $b} 0, @numbers;
 $sum = reduce sub{$a + $b},0, @numbers;



 Production:

 $prod = reduce{$a * $b}1, @numbers;
 $prod = reduce sub{$a * $b},   1, @numbers;



Following grep, map, sort, reduce should be able to 
accept all these forms - currently the form seems to be like
sort than grep and map.

  reduce $a + $b, @list  # grep, map
  reduce{$a + $b} @list  # grep, map, sort
  reducesum2  @list  # sort
  reduce sub{$a + $b}, @list # sort


Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074

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.

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

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

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.

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

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

[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 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 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: 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: 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: 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: PERL6STORM - tchrist's brainstorm list for perl6

[Adam Krolnik]

I think the octal number representation should not be accepted...


Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074

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

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

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

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 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: 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: 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: DBI v2 - The Plan and How You Can Help

[Adam Kennedy]

4. All host parameters should be named (like ":foo") rather than 
positional (like "?"), meeting with the SQL:2003 standard.  The named 
format is a lot easier to use and flexible, making programmers a lot 
less error prone, more powerful, and particularly more resource 
efficient when the same parameter is conceptually used multiple times in 
a SQL statement (it only has to be bound once).  If anyone wants to use 
positional format, it could easily be emulated on top of this. Or, if 
native positional support is still important, then it should be a 
parallel option that can be used at the same time as named in any 
particular SQL statement.  See the native API of SQLite 3 for one 
example that (I believe) supports both in parallel.  This also means 
that execute() et al should take arguments in a hash rather than an array.


Yes, native positional support is still important.

positions make it very easy to do SQL math.

To express it in overly simplistic code

$foo = [ "a = ?", "foo" ];
$bar = [ "b = ?", "bar" ];

$baz = "$foo and $bar";
# $baz now is [ "a = ? and b = ?", "foo", "bar" ];

Bearing mind a situation with an arbitrary number and complexity of 
these sql fragments to be added together, doing this sort of thing using 
named placeholders would be a nightmare.


and we'd just end up with every second person implementing a ? to :p1, 
:p2 scheme in their database layers. If you want positional 
placeholders, it needs to be an additional feature, not a replacement 
for positional placeholders.

Re: DBI v2 - The Plan and How You Can Help

[Adam Kennedy]

  - optional treatment of the statements as an AST, similar in concept to
SQL::Routine, or Tangram::Expr.  Death to SQL templating systems!


I suspect during this process people are going to want a lot of things 
that layer on top of what we currently see as DBI.


Personally I think Tim got it right to initially only handle 
connectivity and preparation stuff in DBI, and not try to deal with 
schemas or relational-mapping or any of that other gumpf.


I see the issues with the table methods in DBI as an example of this. 
What you want in many situations is something much more details that 
just a list of table names.


So with that in mind.

I'd like to see DBI done as a set of multiple interfaces that each 
driver can choose to support or not support.


For example, the connectivity layer. This currently works very very well 
and has allowed huge numbers of different interfaces to almost every 
database in existance.


Every driver, as they do now, should implement support for this layer.

On top of that, if you really must interact with the database to query 
table names and so on, lets see that done as a separate layer.


DBI2::Schema or something. drivers could then specifically advertise 
support or non-support for that API.


And we could get an interface somewhat richer than the current "raw 
hashes" one.


Adam K

Re: DBI v2 - The Plan and How You Can Help

[Adam Kennedy]

I don't mind if you implement this ".dbi" feature though, I just want it 
to be invisible :) i.e. don't check this file, if I explicitly supply 
username and password (this is obvious, right?) and show some warnings 
if don't. Say, make a connect parameter "use_dot_dbi", which is zero by 
default.


I concur. I've been presuming what they are talking about is a standard 
implementation for those that want to use that sort of feature. Not a 
default implementation that everyone should use.


So "if you want to use database config files, we've got a standard way"

Adam K

Re: Perl6 burns 18% fewer calories

[Adam Kennedy]

Michael Hendricks wrote:

In other words, Huffman coding works and Perl6 hackers had better start
watching their waistlines.  Or maybe we should spin it that Perl6 helps
reduce global warming ;)

Anyway, I collected a small sample (~300 lines each) of Perl5 code along
with "equivalent" Perl6 code.  Some came from the Exegeses and others from 
Pugs' SVN.  I had Text::TypingEffort give me some pseudo-scientific results

and typing the Perl5 code takes about 18% more physical effort than typing
the Perl6 code.



My god! What is this wonderful module of which you speak?

Finally a chance to help in the argument that ideas that try to force 
less characters in a huffman-inspired nightmare might make life worse 
from a "actually typing it in real life" sense.


I wonder if handles different keyboard, I'd like to the differences in 
using Perl between the different country keyboards. Especially those 
poor nordics with the / and $ in funny places :)


Adam K

Re: DBI v2 - The Plan and How You Can Help

[Adam Kennedy]

In particular, the DBI must not mandate impossible levels of support from 
the drivers. It will benefit you nothing if the DBI is immaculate and 
wonderful and incredibly all-singing and all-dancing, but no-one can write a 
driver for it because the requirements cannot be met by the actual DBMS that 
Perl + DBI needs to work with.


I concur. Like CPAN as a whole, DBI's strength is in it's complete and 
near universal coverage of all databases, and insanely great (and 
occasisionally greatly insane) drivers that do strange and wonderful things.


If we start sacrificing drivers by raising the bar too high, DBI as a 
whole suffers. Anyone proposing new features for DBI needs to be 
extremely careful of CYJ syndrome.


Can't You Just (or sometimes Could You Just) syndrome is described here.

http://c2.com/cgi/wiki?CouldYouJust
http://www.oreillynet.com/pub/wlg/3593
http://c2.com/cgi/wiki?JustIsaDangerousWord

Go read them now. I'll wait...

This sort of behaviour can play a big part in ending up with second 
system problems.


I have an increasing suspicion that having open design processes like 
the Tim's call for comments plays a big part in it as well.


People are free to comment on things that 1) They won't have to 
implement themselves and (in some cases, but not you Duncan) 2) They 
think they know what they are talking about, but really have no idea 
what it means underneath the surface.


In any case, I still propose that DBI2 split the driver interface into 
Roles. The main "DBI2::Role::Transport" role does ONLY what DBI does 
best now. That is, connecting to the database, preparing and sending 
queries, and fetching the results.


Forget the current ->tables interface. Drivers can OPTIONALLY implement 
the DBI2::Role::Schema interface to handle interrogation of the database 
schema. The current way we handle it is really messy by my standards, 
and could use a dedicated interface.


As you invent major new features for DBI2, implement them roles. 
DBI2::Role::Transational, DBI2::Role::RFC90210 (the super flashy Beverly 
Hills feature), etc etc.


Exactly what these roles should be I don't want to state with any 
certainty. That's the sort of thing that Tim, with his complete 
understanding of the issues, should be doing on his own.


But I _would_ certainly like to see schema/table stuff separated from 
the base connection/query functionality.


While I'm on the topic of DBI, one other feature I'd like to see would 
be something like better support for large objects or various types.


In my personal DBI wrapper I've been using plain SCALAR refs as 
parameters to signify a BLOB, so I can pass by reference without a copy 
of a potentially large memory chunk, and then having to do 
driver-specific translation to bind variables (Oracle) or what have you.


Some base way of default method defining a BLOB object (whether provided 
in memory, or pointing at a file handle to pull the data from at commit 
time) in would be really nice. Even if the way I have to pass the blobs 
to each driver differs, I'd like to be at least be able to say,


This is a DBI2::Data::BLOB object (or something functionally equivalent).

Adam K

Re: DBI v2 - The Plan and How You Can Help

[Adam Kennedy]

No - you don't seem to understand. The challenge-response protocol can ask 
someone for the RSA key fob number this time, their mother's maiden name the 
next time, their employee number the time after that, and nothing on the 
fourth occasion. You cannot predict what the extra information requested is 
going to be - so you can't provide the extra information in the initial 
connection attempt because you don't know which extra information is going 
to be needed. That's what provides the security - the unpredictability of 
the question, so that it is hard to pre-programme the answer.


Ah but you can know in advance! :) You may not know the actual result 
per instance, but you CAN know the decision process you'll need to go 
through. Which you can provide as a parameter in the form of a CODE 
reference. :) i.e. a callback


But that's a minor point and overall I completely agree with your 
general ideas.


Adam K

Re: my $pi is constant = 3;

[Adam Kennedy]

: If not a special form, should this work? 
: 
: my $pi is constant;

: $pi = 3;

That could be made to work by defining constant to mean you can assign
to it if it's undefined.  But then it gets a little harder to reason
about it if $pi can later become undefined.  I suppose we could
disallow undefine($pi) though.


Which would basically throw away compile-time optimizations relating to 
constants wouldn't it?


Adam K

Re: my $pi is constant = 3;

[Adam Kennedy]

Larry Wall wrote:
> On Wed, Aug 17, 2005 at 01:56:35PM +1000, Adam Kennedy wrote:
> : 
> : >: If not a special form, should this work? 
> : >: 
> : >: my $pi is constant;
> : >: $pi = 3;
> : >
> : >That could be made to work by defining constant to mean you can assign
> : >to it if it's undefined.  But then it gets a little harder to reason
> : >about it if $pi can later become undefined.  I suppose we could
> : >disallow undefine($pi) though.
> : 
> : Which would basically throw away compile-time optimizations relating to 
> : constants wouldn't it?
> 
> You could still reason about it if you can determine what the initial
> value is going to be.  But certainly that's not a guarantee, which
> is one of the reasons we're now calling this write/bind-once behavior
> "readonly" and moving true constants to a separate declarator:
> 
> my $pi is readonly;
> $pi = 3;
> 
> vs
> 
> constant $pi = 3;
> 
> or
> 
> constant Num pi = 3;
> 
> or if you like, even
> 
> constant π = 3;
> 
> Larry

OK, so then there is not "is constant" at all... just "is readonly"?
Makes a lot more sense to me.

Adam

Re: Perl 6 code - a possible compile, link, run cycle

[Adam Kennedy]

Ingo Blechschmidt wrote:

Hi,

Yuval Kogman wrote:


On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote:


This section will contain all information needed:
* User-defined operators
* Other symbols exported by "is export"
* Exported macros


Okay, this raises a distinction:

Compile time exports
Runtime exports



Well, all exports happen at compile-time, but you're right, some exports
(regular subs) will probably not be used before runtime.


Excuse my stupid question, but what about the equivalent Perl 6 case to 
the following.


use Module qw{symbol};

BEGIN {
die "Not ready to compile" if symbol();
}

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.

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

Will _anything_ be able to truly parse and understand perl?

[Adam Kennedy]

lly round-trip safe (100% in testing of a CPAN subset of 
5,500 perl files)

So $source -> $DocumentObject -> $source is safe.
Now of course, it is completely unable to deal with source filters. 
There is some talk of adding extendability in some how, but that's an 
idea for another year (or decade).

Keeping the normal slight changes in grammar under control has been 
bloody hard, but dealing with arbitrary grammar manipulation would be 
just plain impossible.

But then I'm fairly comfortable in that source filters are consider 
scary and dangerous and everyone knows not to play with them unless you 
really need to, so it's fine to say "PPI does not support source filters".

Getting (finally) to perl6, I could have sworn I saw an RFC early on 
which said "Make perl6 easier to parse".

But it would appear the opposite is occurring. Source filters have 
become grammars and will now be officially approved and acceptable 
(yes?) while so far as I can tell the problem of prototype vs 
operator/operand interaction is not being addressed. (I'm a little in 
the dark here, perhaps it is and nobody has noticed enough)

What information I have managed to get from MAGNet #perl suggests that 
the "approved" way of manipulating code will be to parse it via a 
grammar into primitives, manipulate the primitives and then write it 
back out as those primitives.

Excuse my terminology here if I'm not using the exact terms you guys 
have been using.

But in any case, I take it the grammars are like Scheme "MACROS" 
(correct term?) or source filters and only work in one direction. That 
is, you can't take the result of whatever the grammar transformation is 
and reverse it back into the original code.

Suggesting to #perl that manipulating code this way and writing it back 
would completely destroy the code (certainly from a maintainability 
standpoint) seemed to just seemed to get shrugs from the audience.

I know it's probably a bit late at this point to making huge changes (at 
the time the RFCs were being done I wasn't really confident enough in my 
knowledge to suggest anything), but I really would like to make the 
point that by going down this route of becoming less parsable we may 
well be sacrificing a huge range of potential analysis and manipulation 
technologies by making perl source even more impossible to 
document-parse than it already is.

Any comments or feedback you have on the issue of parsability would be 
welcome. I'm not sure if Damian is involved in Perl 6 language stuff any 
more, but if he or anyone else language-related is going to be at 
YAPC.AU next week I would dearly love to meet up and have a chat.

My currently-being-API-frozen perl parser is visible at
http://search.cpan.org/~adamk/PPI-0.831/
Thanks for your time
Adam Kennedy

Re: Will _anything_ be able to truly parse and understand perl?

[Adam Kennedy]

Let's say you want to write a yacc grammar to parse Perl 6, or
Parse::RecDescent, or whatever you're going to use.  Yes, that will be
hard in Perl 6.  Certainly harder than it was in Perl 5.
In the end, I concluded there was _no_ way to write even a Perl 5 parser 
using any sort of pre-rolled grammar system, as the language does not 
have that sort of structure.

PPI was done "the hard way". Manually stepping through line by line and 
using a variety of cruft (some stolen from the perl source, some my own) 
to make it "just work".

I would envisage that the same would be true of writing a PPI6, except 
with a hell of a lot more operators :)

However, Perl 6 comes packaged with its own grammar, in Perl's own rule
format.  So now the quote "only perl can parse Perl" may become "only
Perl can parse Perl"  (And even "only Perl can parse perl", since it's
written in itself :-).
Perl's contextual sensitivity is part of the language.  So the best you
can do is to track everything like you mentioned.  It's going to be
impossible to parse Perl without having perl around to do it for you.
>
But using the built-in grammar, you can read in a program, macros and
all, and get an annotated source tree back, that you could rebuild the
source out of.
Again, this is of very little use, effectively destroying the source 
code and replacing it with different source that is a serialised version 
of the tree.

For a current notional example, it would be like loading a simple...
try {
  $object->$do_something;
} catch (Exception $problem) {
  handle($problem);
}
... changing ->$do_something to ->$do_something() to make it 
back-portable, and then ending up with...

Module::Exceptions::initialize('line 98');
my $exceptionhandler = Module::Exceptions::prepare();
eval {
  $exceptionhandler->update_status('in try');
  $object->do_something();
};
if ( $@ ) {
  if ( ref $exceptionhandler ) {
require Scalar::Util ();
if ( Scalar::Util::blessed $exceptionhandler eq 'Exception' ) {
  do {
my $problem = $exceptionhandler->fetch_exception_as('$problem');
# handler starts here
handler($problem);
$problem->clean_up;
  };
}
  } else {
# Just die as normal
die $@;
  }
}
While technically they may be identical once they get through the parser 
and into tree form, trying to changing ->$do_something to 
->$do_something() and getting back some huge monster chunk of code you 
didn't expect is definitely not what the intent of parsing it in the 
first place was.

This is what I am talking about when I refer to the "Frontpage" effect, 
the habit Micrsoft's HTML editor (especially the early versions) had of 
reuilding you HTML document from scratch, deleting all your template 
variables and PHP code and generally making it impossible to write HTML 
by hand. For HTML where you arn't MEANT to be writing stuff by hand 
under normal circumstances that wasn't always a problem, but perl _isi_ 
meant to be written by hand.

> You could even grab the comments and do something sick
with them (see Damian :-).  Or better yet, do something that PPI
doesn't, and add some sub call around all statements, or determine the
meaning of brackets in a particular context.
The question of whether to execute BEGIN blocks is a tricky one.
Sometimes they change the parse of the program. Sometimes they do other
stuff.  All you can hope for is that people understand the difference
between BEGIN (change parsing) and INIT (do before the program starts).
Frankly that is a gaping security hole... not only do I have to still 
deal with the problem of loading every single dependency or having no 
parsing ability otherwise, but I am required to "trust" every perl 
programmer on the planet :(

I love PPI, by the way :-)
Thank you, I do to :)
But I'd like to still have something like it in perl6 :(
Adam

Re: Will _anything_ be able to truly parse and understand perl?

[Adam Kennedy]

Michele Dondi wrote:
On Thu, 25 Nov 2004, Adam Kennedy wrote:
I thought it was about time I brought some concerns I've been having 
lately to the list. Not so much on any particular problem with perl6, 
but on problems with perl5 we would seem to have the opportunity to 
fix but aren't. (So far as I can tell).

So why not discussing this somewhere else? (e.g. clpmisc)
One of the biggest problems I have had with perl5 is that nothing, not 
even perl itself, can truly actually "parse" Perl source. By this, I 
mean "parse"

False:
"[Nothing but] perl can parse Perl." (Tom Christiansen)
Please see Acme::BadExample. perl itself cannot "parse" this at all, and 
yet it follows the absolutely most basic syntax for the language.

And just after the snip you will see I qualify "parse" in this context 
as loading the perl in some form of DOM-type tree.

Adam

Re: Will _anything_ be able to truly parse and understand perl?

[Adam Kennedy]

Smylers wrote:
Adam Kennedy writes:

perl itself would also appear unable to understand perl source,
instead doing what I would call RIBRIB parsing, "Read a bit, run a
bit".

RIBRIB?  RABRAB, surely!
Smylers
Yes, you are right, typo.

Re: Will _anything_ be able to truly parse and understand perl?

[Adam Kennedy]

Herbert Snorrason wrote:
On Thu, 25 Nov 2004 22:00:03 +1100, Adam Kennedy <[EMAIL PROTECTED]> wrote:
And just after the snip you will see I qualify "parse" in this context
as loading the perl in some form of DOM-type tree.
And yet you disqualify the Perl6 rule system, with its tree of match
objects? What, exactly, is it that you want?
What I'm after are 3 critical features.
1. You always get back out what you put in.
$source eq serialize(parse($source)).
2. No side effects. Autrijus Tang suggests this may be workable
3. You can parse a document with broken dependencies.
There are a myriad of these situations, such as
- Dependencies you don't have
- Editing on different platform to execution platform (think Win32:: or 
S390/mainframe/GridComputing)

- Unfinished code
- Things you can't get installed (ImageMagick etc)
- Example code that will never be executed
(Imagine if you will a mod_perl syntax highlighting module for 
search.cpan.org. Should the search.cpan.org host have to _install_ every 
single one of the modules in CPAN?)

PPI can do all of these 3 things. Not 100% reliably, but for "normal" 
code (where "normal" is actually defined fairly broadly).

In any case, I would like to suspend this debate for a week, as I'll be 
talking with Damian (hopefully) at YAPC.AU. I'll report back afterwards, 
having hopefully imparted the full extent of my problem.

Perl 6 rules or some variation therein may indeed be what I'm after, 
although I need to find out more about the internals.

Do we have a working version yet I can create some demonstrations with?
Adam

Re: Lexing requires execution (was Re: Will _anything_ be able to

[Adam Kennedy]

It's quite a disappointment in some ways, but we've lived with it in 
Perl 5, and I'm sure we can live with it in Perl 6.

And I still think Perl 6 will have fewer cases in which it's completely 
impossible for not-Perl to parse it. Unfortunately, fewer still implies 
some, and some is still a problem.
Frankly, as the only person who has managed to get together a "guessing 
lexer" that is sufficiently accurate to be something other than useless, 
I see nothing in Perl 6 that makes it any easier than Perl 5. In fact, 
my reason for starting this thread in the first place is because I was 
increasingly getting the feeling there would be MORE problems.

The "prototype and operator/operand content" problem is still there. PPI 
works around it with quite a bit of hackery (look ahead, look behind, 
look ahead again, and shake it all about. Do the hokey pokie etc etc)

For the relevant code, look for '47' in
http://search.cpan.org/src/ADAMK/PPI-0.831/lib/PPI/Token/Whitespace.pm
This can still be easily tricked if you are trying to (see Randal's 
examples again), but usually gets most "real world" code right.

Then again, I avoid the whole problem of attaching params to sub calls 
by not doing it at all. The closest I can get is to list a set of tokens 
within a statement.

Perl 6 has the same problems, and then also adds a higher likelyhood of 
encountering custom grammars than in Perl 5, where source filters are 
considered largely bad form.

The fundamentals would appear to be the same.
As a side note, I may have used "parse" erroneously. What PPI attempts 
to do is to be a tokenizer and a lexer, without understanding its 
function as code.

So perhaps a "syntax lexer" is a closer term. The ability to read in and 
work with code based purely on syntax, without needing to know what it 
means.

Adam

Re: Perl 6 Summary for 2004-12-20 through 2005-01-03

[Adam Kennedy]

Matt Fowles wrote:
Perl 6 Summary for 2004-12-20 through 2005-01-03
All~
Welcome to a New Year of Perl 6 Summaries. I have been doing bi-weekly
summaries over the holiday season, but I plan on returning to weekly
ones now. Hopefully "World of Warcraft" won't prevent me, we shall see,
but if anyone starts a perl guild drop me a line ;-)
  Perl 6 Language
   Perl IDE
matisse wondered if an IDE for Perl would be possible given its dynamic
nature. The conses arrived at last time was that an IDE that worked for
"nice" code would be possible, but a fully general one would be
extremely difficult and quite possibly impossible.
<http://xrl.us/ekks>
Strange, I can't see this message at all using nntp.perl.org... or any 
replies to it at the google groups address that tinyurl points to.

I thought I'de throw in that the very very distant "sparkle in my eye" 
for PPI is to build something for perl similar to IntelliJ IDEA.

If the PPI-like mode of the perl 6 parser happens (don't touch anything 
outside the file) then I don't see why it can't be done, at lease in 
some form.

Adam Kennedy

Re: .method == $self.method or $_.method?

[Adam Kennedy]

I should add that Darren and I, who both have similar tendencies towards 
larger scale coding where consistency is far preferred to compactness, 
both ended up concluding that our style policies will be to _always_ use 
explicit invocants (except of course for one liners).

In the case of the Algorithm::Dependency module that is being ported 
over as a test, and given that larger chunks of code have a tendency 
towards named iterators in loops anyways, and we've ended up with the 
only sane way to be the wordiest of the various ways-to-do-it.

Just for the record, I for one would have much preferred to have .foo be 
the same as $.foo and @.foo and %.foo and refer to the invocant method, 
at the cost of using C< map { $_.foo } >.

To describe it in emotional terms, the current situation feels 
"backwards and inside out".

Adam K
Michael G Schwern wrote:
There's a discussion going on #perl6/irc.freenode.org right now wondering
about what .method means.  We'd all assumed it meant $self.method (where
$self is always the method invocant) but then had a look at Synopsis 12 
which states 

  Dot notation can omit the invocant if it's in $_:
.doit(1,2,3)
This seems to cripple .method's usefulness by coupling it to $_ which
can change often.  Now in order to be safe for anything but trivial methods 
you're back to writing out $self all over the place, something that Perl 6 
was supposed to fix about Perl 5.

It has also been pointed out that .foo, $.foo, @.foo and %.foo are all
(intentionally) similar and all but one operates on the invocant.  Only
.foo operates on $_.  This seems like a newbie trap waiting to happen.
MOST of the time .foo will work like $self.foo but every once in a while
they'll get caught in a gotcha.
Thoughts?

Re: .method == $self.method or $_.method?

[Adam Kennedy]

That is correct. It probably should have read "...our style policies 
will be to _always_ use explicit invocants, if .foo ends up meaning 
$_.foo in the final release (as it does now)".

(of course, I suspect Darren will keep using them anyways, but then he 
likes to be even more explicit than I am)   :)

Personally, .foo meaning $self.foo seems more consistent to my mind, and 
I'd happily standardise on implicit invocants. The only minor thing I 
can see would be that you will end up with a slight asymmetry question 
of "if we use $:attribute for a private attribute, do we call :method 
for a private method?"

Adam K
Michael G Schwern wrote:
On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote:
I should add that Darren and I, who both have similar tendencies towards 
larger scale coding where consistency is far preferred to compactness, 
both ended up concluding that our style policies will be to _always_ use 
explicit invocants (except of course for one liners).

I thought your conclusion was you'd only use an explicit invocant if .foo
meant $_.foo.  And to drop it if .foo means $self.foo as there's no 
ambiguity.

Re: .method == $self.method or $_.method?

[Adam Kennedy]

Err, wait, I don't think we are discussing whether $_ is to be outlawed
in map {}. I think the proposal is for .method always mean $invocant.method
and make it illegal when there is no invocants in sight, mush as $.attr
would be illegal without an invocant.  To use $_.foo, write $_.foo.
Luke is discussing flow-on effects, just as larry was with his 'o' and 'c'.
if ( .process is $_.process ) {
either {
Specify an explicit invocant <--- Larry
} or {
Specify an explicit topical variable <--- Luke's musing
}
} else {
Call methods on $_ using $_.method <--- My preference still :)
}
The only thing that worries me about "The OC" idea (how curious that a 
feature is so easily named after a TV show) is that he is talking about 
them being functions. I don't know enough about interals, but would that 
get optimised to something faster, or do we suffer a second function 
call every time we want to call a method?

I also have some worries about there being three different ways to call 
a simple invocant method.

.method
$_.method   (except in map/grep)
o.method
It has a faintly similar smell to the workaround-hell mod_perl 2 got 
into... I'm all for TMTOWDTI, but surely the language should be elegant 
enough that something as simple as calling a not-special-in-any-way 
method doesn't need to have three different ways to do it?

An interesting exercise for anyone with a minicpan checkout would be to 
scan CPAN and see how often the various uses are needed currently. 
($self-> compared to $_->).

Granted there are a hell of a lot of caveats in that, but it there's a 
10 to 1 ratio of one to the other, surely that would help to make the 
prefered preference a little clearer?

Adam K

Re: .method == $self.method or $_.method?

[Adam Kennedy]

At the moment I'm trying to see if I could get used to ..method meaning
$_.method, and whether it buys me anything psychologically. 
At some point, adding another thing people have to remember in order to 
save one character gets a bit self-defeating, surely.

The good thing about $_.method is that it is familiar, quite compact 
anyways by virtue of using $_, and nobody is going to be surprised by it.

Personally (and I'm admittedly leaning towards simplicity lately) I'd 
even throw a warning for using .method when there is an explicitly named 
invocant as well.

# Good
sub foo {
.bar;
}
# Possibly confusing, throw a warning or forbid under strict?
sub foo ($self:) {
.bar;
}
# More obvious
sub foo ($self:) {
$self.bar;
}
of course, since it is still preferable to be symmetrical, if $.attr is 
legal (and no warning) with a named invocant, then so should .method be.

Adam K

PPI and the Perl 5 to Perl 6 converter?

[Adam Kennedy]

I thought I'd just drop in a quick note to people to let you know that 
PPI 0.903 was just release, which fixs the last significant performance 
bug. PPI is now completely leak-free and implicitly-DESTROY's correctly.

Anyone who wanted to have a short at doing any kind of mass-processing 
of Perl 5 code to produce docs or pugs AST trees or what have you should 
be able to safely build on top of PPI now.

To summarize, "Parsing and Analyzing are getting quite usable. I'll get 
back to you later on Manipulating".

Also, I saw another mention recently (possibly on TPF request for 
donations) about the Perl 5 to Perl 6 converter, and it being 40% 
completed? ... Larry?

Is anybody working on it? If it's built on something other than PPI, is 
there anything I can see, so I can steal any parsing tricks I don't know 
of yet. :)

Adam K

Re: PPI and the Perl 5 to Perl 6 converter?

[Adam Kennedy]

Er, I'm not sure you will want to--I'm using PPI's evil twin brother,
"PPD" (the actual Perl parser).  I've just modified it so it doesn't
forget anything I want it to remember.  (As you know, the standard
parser throws away gobs of useful information, everything from
whitespace and comments to pruned opcode subtrees.  I have a version
that doesn't do that, by and large, though I'm still finding fiddly
spots.) 
So I'm presuming that you don't intend this as a tool that can do mass 
porting of code (due to the dependency issues), but rather as something 
for helping individual module authors port individual files/modules.

Also curious how you handle BEGIN and friends... I take they are 
executed and then pruned, and end up unpruned in your XML?

Also curious if you have managed to keep comments, POD etc...
Adam K

Re: Plethora of operators

[Adam Kennedy]

[»+^=«] reminds me of a P5 regex that has a comment saying "This is
black magic. Don't touch!". --That's-- my complaint.
Indeed. There's a time and a place for that sort of black magic, and 
it's usually about once per 5,000 lines of code, and so deep and well 
wrapped in comments and unit tests that nobody should have to touch it. 
Ever.

If using something like [>>+^=<<] (and I'll bet a LOT of people are 
going to have to type it the long way) is going to involve 5-6 lines of 
comments just to explain what is going on, what's the point?

I look at...
>>but the basic operator there is just ^, with a + modifier to indicate
>>numeric XOR, = to indicate an assignment operator, »« to indicate
>>explicit parallelism, and now [] to indicate reduction
...and I just mind-wipe... so it's doing WHAT exactly? I've read it 5 
times and I still have no idea. And reduction? I write 25,000+ lines of 
Perl a year, and if you are talking about something like 
List::Util::reduce, I think I've used it maybe twice?

That sort of "pill" is the sort of think I'd assumed I'd start seeing 
once I wrote.

use physics;
Which, by the way I'm completely positive about. Loading in special 
grammars for particular classes of programmers is just an amazing idea.

But really, in what circumstances could someone possibly need reduction 
so badly it needs to be in the core?

Adam K

Re: ^method ?

[Adam Kennedy]

Autrijus Tang wrote:
Juerd informed me today that .method should still means $_.method.
However, for the OO modules we're writing, there still needs to be a way
to invoke methods on the current invocant, when the invocant name has
been omitted from the method() declaration.
Currently Pugs has:
$?SELF.method
^method
Is any of the two forms considered canonical?  Or is there some other
alternatives?
I must say after the previous conversation leaning towards .method == 
$?SELF.method I was stunned to see it had flipped back further than 
where we started last time...

I don't mean to be disrespectful, but what was whoever suggested ^ 
thinking? For starters, about the only combination harder to hit with on 
spanned hand might be ctrl-F5. You really have to stretch quite hard to 
hit it. The current requirement of $, -, and > at least contains 
_relatively_ easy to reach characters.

Having read back through some recent archives, it seems that we are 
selling out the option to provide a basic, clean, symmetric, OO for the 
sake what seems basically like a sexy way to do...

if ( $foo == 1 ) {
} elsif ( $foo == 2 ) {
}
If we aren't going to make the invocant method . like everyone else 
expects, can I at least have -> back?

At some point we just end up with it being not maintainable enough by 
"normal" programmers, and so we end up falling back on ...

method ($self: $string) {
$self.method;
$self.method;
}
...because doing it implicitly just isn't readable, and is going to give 
me RSI. Huffman would be turning in his grave.

I don't know if I get a vote, but I write about 25,000 sloc of Perl code 
a year, and I'd MUCH rather have clean, simple and terse OO than sexy 
control structures.

And please, from another thread, can someone please explain exactly what 
the [>>+^=<<] operator does? Not what it's components are, but as a 
whole. Trying to work it out from a description is giving me flashbacks 
of trying to understand haskell in an afternoon.

Maybe I'm just a bit testy from not sleeping in the last 36 hours, but 
I'm willing to accept a lot of things as long as we don't treat OO like 
a second class citizen WRT notation.

Every time I look at it .method just seems both obvious and symmetrical, 
and yet we people keep wanting to give it up because some trickier thing 
gets a bit uglier...

Is there any way we could prioritize based on frequency? We're 
accumulating quite a little library of P6 code now. What are people 
actually _using_ the most?

What gets used in CPAN? How many $self->method calls are there compared 
to grep {} and map {}?

/me goes back to work
Regards
Adam K

Re: ^method ?

[Adam Kennedy]

The obvious way to do it is to declare the invocant.
Wasn't one of the original headline features for Perl 6 not having to do 
that any more for basic normal code? Or at least from a couple of damian 
talks it was one of the things that practically _everybody_ wanted.

On the plus side, with explicit invocants, we don't need all those pesky 
shortcuts for implicit attributes any more, since there's be a invocant 
around 90% of the time.

Adam K

Re: ^method ?

[Adam Kennedy]

For starters, about the only combination harder to hit with on
spanned hand might be ctrl-F5.

I've remapped my keyboard so that I push shift for numbers and leave
it off for the various symbols on the top row. ^ isn't hard to type
for me.  (Plus, is it that hard to use two hands with shifted keys
like you were taught in typing class?)
Can I assume that there is agreement already that in order to sit a 
beginner down and have them learn and write basic Perl, they shouldn't 
have to:

1) Remap their keyboard
2) Use characters that aren't on most keyboards
I have horrible visions of newbie Win32 coders getting frustrated when 
the only way they can see to do something is to open up the Windows 
Character Map program and copy/paste from there.

The current situation of the << and >> characters seems fine in this 
regard, because it's not something you are going to need to use until 
you get more advanced.

Having the...
Start->Programs->Accessories->SystemTools->CharacterMap,Click,"Select","Copy",Close,Ctrl-V
... º character as the default invocant method (to use that option as an 
example) is something I'd much like to avoid.

Adam K

Re: ./method

[Adam Kennedy]

Juerd wrote:
A few days ago, when typing ./pugs,... You can guess the rest :)
I suggest
./method
to mean $?SELF.method, and
../method
to mean $?SELF.SUPER::method, or however that's normally written.
I'm opinionless on the latter, since in my opinion cross-calling 
supermethods (calling a supermethod other than the one you are currently 
in) has been nothing but bad in my experience.

But it's definitely the best suggestion so far for implicit invocant method.
If this was apache.org, I'd +1 it happily.
Looking at various keyboard layouts however, the nordics among us (who 
have / at shift-7) are probably not going to like it though :)

But US/UK/CJK are all to the right of the period, so it's a very 
friendly combination in that regard.

Adam K
Adam

Re: Syntax of using Perl5 modules?

[Adam Kennedy]

On the migration front, when someone ports Digest.pm to Perl6, I get a 
"free" upgrade, assuming the module author was kind enough to up the 
version number.


You are making a pretty huge assumption here that whoever has a 
namespace in p5 CPAN has first dibs at the P6 namespace of the same 
name, and that they will do a straight port over.


Someone else could reimplement the module for Perl 6, or perhaps the 
author wants to (desperately needed in some cases)completely overhaul 
the module and API based on lessons learnt the first time.


The problem with automatic fallback is simple that you are no longer 
getting two different versions of the same module, you are getting two 
completely different libraries, with no guarentee that the API is 
consistent.


Automatic fallback lets changes in environment leak into the process and 
cause unexpected changes in program functionality, and this is BAD.


The only time at which having to do nothing to load a current CPAN 
module will be during the transition period, before a suffucient body of 
Perl 6 modules have built up.


In the longer run, much better to have to do something special to get 
the old and redundant versions of modules.


Adam K

Re: Syntax of using Perl5 modules?

[Adam Kennedy]

You get all those possibilities whenever you install any new version of 
a module you get from someone else, regardless of a p5->p6 hop. In p6, 
when you say "use Digest;", you are specifically asking for what p6 
considers the "latest" version. In p5, it was "first match on libpath".


Except that within Perl 5, there is an general expectation that the same 
API will exist across multiple module versions. It is assumed that newer 
versions of a module will continue to work the same as older ones, with 
API breakages being a bad and rare thing.


The 6 month long mod_perl Apache::->Apache2:: argument was over this 
very thing. There is a huge difference between an API version and a 
module (implementation) version.


As far as I'm aware, there is no expectation that *every* module in Perl 
6 that shares a name with a module in Perl 5 will merely be a 
re-implementation of the same API in Perl6.


If I am expected to reimplement all my Perl 5 modules in Perl 6 without 
the opportunity to do a better job and take advantage of new Perl 6 
API-related features, could someone please point my boot in the general 
direction of the ass of whoever came up with that idea.


Adma K

Re: Declarations of constants

[Adam Kennedy]

Ingo Blechschmidt wrote:

Hi,

  # Way 1
  my $MEANING_OF_LIFE is constant = 42;


Forgive my ignorance here, but for all of these different ways of doing 
constants, will they all optimize (including partial 
evaluation/currying) at compile/build/init/run-time?


my $gravity is constant = 10; # One significant figure

sub time_to_ground ($height, $accel) {
...acceleration math...
}

my $time = time_to_ground( 500, $gravity );

... thus simplifying internally to

my $time = 1234;

Adam K

Musing on registerable event handlers for some specific events

[Adam Kennedy]

With my occasionally-stated preference for keeping the Perl 6 core 
slimmer than it already is, I feel a little silly about suggesting new 
features for P6, but I'd like to stimulate debate on one that I'd like 
to see.


Last year I was having some issues with a large web application that 
needed to run as both a CGI and mod_perl application.


In particular, I wanted an effect where modules that I didn't need for 
every call weren't loaded unless "appropriate".


Now for CGI that means run-time loading. We have a number of these, from 
AutoLoader to (my) Class::Autouse module.


In mod_perl or other forking scenarios these same modules should be 
preloaded BEFORE the fork, so that they only use memory once, not many 
times.


Although Class::Autouse already magically supported mod_perl and 
preloaded, it was obvious that this was the wrong approach. There needed 
to be a way to preload for ALL forking scenarios without duplicating 
logic all over the place.


As a result, I ended up creating prefork.pm to allow different modules 
to register callbacks that would be triggered just before forking, so 
that various run-time loading hooks could all be triggered and loaded 
automatically before the fork.


This has worked for me quite well, but is a voluntary situation in which 
any forking module has to trigger the prefork logic manually.


What I'd like to see for Perl 6 (and I'm not sure if this exists 
already), is some sort of minimal event manager.


The number of events I'm talking about would be extremely low, pre and 
post fork being one. I'm not sure about others, but again I'm imagining 
only events that matter process-wide.


I'd like to see the Perl 6 fork() command issue event triggers to some 
officially blessed event manager module. Any number of other modules 
could register callbacks for whichever events they liked.


The other alternative is to have the event manager overwrite the core 
fork() function... and I dislike this sort of hackery as these tricks 
generally only work if one person does it.


If it can be done in less than 10 lines lines of code, to get the most 
minimal hooks into the core, I'd like to see it done.


Thoughts?

Adam K

Re: Musing on registerable event handlers for some specific events

[Adam Kennedy]

: If it can be done in less than 10 lines lines of code, to get the most 
: minimal hooks into the core, I'd like to see it done.


10 lines?  I laugh in your general direction.


No really. In perl itself, I just to see...

throw Event("CORE::prefork") if $Event::Manager::VERSION;

...or something equally simple.

Fair enough Event::Manager itself might be a little larger... but even 
then it shouldn't need to be more than a couple of dozen lines.


prefork.pm is currently about 30-40, and you should only need the 
hashified version of it.

Re: Musing on registerable event handlers for some specific events

[Adam Kennedy]

Gaal Yahas wrote:

On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:


There will certainly be an event manager for all sorts of events floating
around in Perl 6.  The main trick will be to hide this from the people
who aren't interested.  The other trick will be to actually spec it,
since up till now I've assumed that it should be specced by the people
who are actually into that sort of thing.  Looks like you're one of
them.  :-)



There's the touchy issue of what minimum compatibility level we're
promising to deliver on all platforms. This is an issue in pugs already,
where Windows GHC isn't compiled with POSIX libraries so we're stumped on
the interface for even relatively basic things, such as how (or whether)
File.open might offer O_EXCL.

Is part of the vision something like the explicit cross-platform nature
of Java? Will I be able to write Perl6 code with a certain flag that
possibly limits my choice of modules/builtins, but which promises me
identical behavior on all supported platforms?

To take a notorious example, you mentioned fork() -- if this event manager
becomes part of Perl6, does that mean we're required to emulate fork()
on win32?


Your point is well taken. Hell, even I was debating generalising even 
further from "fork" to "preload". As in, having Perl emit an event which 
says "Hey everybody, now would be a _really_ good time to load 
everything in, because after we $whatever, it's going to be a lot more 
expensive to load them in at run-time that to just load them now and 
benefit from copy-on-write/threads/whatever."


Sort of a "disable run-time loading and load stuff now" event.

The reason I wanted a ten lines of code solution is so that the 
fork()-on-win32 issue is less of a problem.


If perl itself ONLY does (in p5 term)...

Some::EventManager->fire('prefork') if $INC{"Some/EventManager.pm"};

..then it would matter less whether or not fork ever happens on Win32.

The preload.pm module would simply register with Some::EventManager for 
a different set of events depending on which platform it is on. 
prefork.pm as it exists for P5 today doesn't _really_ care about fork(). 
What it _really_ wants to know is "Should I run-time load or not? Tell 
me when we need to stop run-time loading".


Some::EventManager might be part of the core, but it certainly wouldn't 
be loaded by default. It's just a normal module that gets loaded when 
someone needs to use it.


I'm a minimalist. I want something to does the absolute least amount of 
work needed to let me know about events I simply can't find out about 
any other way, and that perhaps we can add additional events to later.


I certainly DON'T want something big enough and heavy enough to be able 
to write Aspect.pm on top of.

Re: ./method

[Adam Kennedy]

The reason we ended up at ./method was simply because it was the best 
suggestion anyone had.


Compared to the previous suggestions it was way ahead.

It's other advantage is that (except for on nordic keyboards) dot and 
slash are generally right next to each other, so the expense of using it 
is two chars and one fingering position, as they would likely be hit by 
fourth and fifth fingers (for touch typist style) and some other two 
fingers for the rest of us, and only 1 cm travel for hunt and peck.


It has a very low RSI index :)   (something I don't think we take into 
account enough as it is when we use the Huffman name to justify 
shortening something)


So call it (2ch|2key|1pos|1cm) cost

.::method on the other hand is 2 chars, 4 keystrokes, one of which must 
be held down between the two colons, is a strech for touch typists, 
requires you to get you hand completely away from the letters for the 
rest, and god help the hunt and peckers.


Something like (3ch|4.5key|2pos|5cm) cost.

And I dislike having a THIRD sigil even more than I dislike the second.

Adam K


I think $ is way more objectionable to the lily-white non-Perl heathens, but
I don't really care about them either way.  I'm just saying ./ screams "file
path" to me, or maybe even "typo-ed Java/C++ comment" or something.
Certainly not "method invocation" or "implicit invocant."  The .: thing,
OTOH, totally works for me and I've always liked it.  I'm just trying to
stretch it to cover both public and private.  Maybe there's something better
than both.

Re: ./method

[Adam Kennedy]

John Siracusa wrote:

On 6/18/05 8:28 PM, Juerd wrote:


The unix shell and things resembling it will still be in use much fifteen
years after today, Perl 5 will not.



Ooo, a bold prediction :)


Heh, it is indeed. And it means given the 16,000,000 lines of Perl in 
CPAN, we only have to keep the porting rate up at around a million lines 
of code a year.


Adam K

Re: AUTLOAD and $_

[Adam Kennedy]

 > I think there exists an even simpler way to avoid any mess involved.

Instead of letting AUTOLOAD receive and pass on arguments, and instead
of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
thing, and then have *perl* call the sub?

sub AUTOLOAD ($whatever) {  # but no [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our &::($whatever) := $s;
return $s;  # non-subref indicates failure
}


You are of course assuming that every use of AUTOLOAD, for all time, 
will result in


a) Calling another function
b) An error

Wouldn't this lead to hacks where people do things like this just to 
prevent perl thinking it's a failure?


sub AUTOLOAD ($whatever) {  # but no [EMAIL PROTECTED]
 my $s = get_subref_for $whatever;
 our &::($whatever) := $s;
 return sub () { 1 };
}

The ability to get complete control over the params and context of the 
function, and maybe run something else AFTER the function call is important.


So I suspect there might be some false economy in this optimisation.

Adam K

Re: Quasiquoting

[Adam Kennedy]

Autrijus Tang wrote:

On Tue, Jun 28, 2005 at 09:49:58AM +1000, Brad Bowman wrote:


Autrijus' journal mentions quasiquoting (Perl 5).



Yes... quasiquoting in Perl 5 is currently crudely emulated
by feeding things to PPI::Tokenizer and PPI::Transform. :-)


You're doing what now? :)

Just in case this ever comes up again, let me clear something up now. 
It's worth noting it once here for everyone.


PPI is not a code parser. By code parser I mean taking a string and 
turning it into working code. PPI is a document parser. It parses ONLY 
on syntax to form a model of a document. Any conclusions it might make 
on the structure of the resulting code are secondary.


It cannot determine implicit parameters for function calls, which also 
means it has difficulty or cannot determine operator precedence.


It is theoretically impossible to (document) parse Perl "fully" without 
also executing it, and even then perl doesn't (document) parse Perl, it 
just (code) parses Perl, or rather runs Perl.


So to summarise, PPI is of limited use when it comes to working with 
bytecode or something that will be executed. It is for working with 
documents, not code.


And I'm done here :)

Adam K

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

'while <> {' in Perl 6

[Adam Lopresto]

I was wondering whether the Perl 'while (<>){' idiom will continue to be
supported in Perl 6?  I seem to recall people posting example code the list
using it (although I can't dig any up), but it seems to me that if Perl 6's
lazy list implementation is sufficiently smart, it could just be replaced with
'for <> {'.  The only issues I can see are people using <> inside the loop, and
maybe something about the scope of $_.  (Does a topicalized $_ change the value
of $_ outside of the loop?) 
-- 
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/

perl -le '$_=(split q,",,`$^Xdoc -q japh`)[1].".";y/pj/PJ/;print'

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