Re: RFC 290 (v1) Remove -X

[Bart Lateur]

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

-- 
Bart.

Re: RFC 290 (v1) Remove -X

[Ariel Scolnicov]

Uri Guttman <[EMAIL PROTECTED]> writes:

> > "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. also the common prefix will make it clear tha tthey
> are part of the family of file test ops.
> 
> here are some ideas which you can shoot down:
> 
> a minus prefix like the current -r
> 
>   -readable
>   -tty
> 
> or has_ as the file has read permission:
> 
>   has_readable
>   has_executable
> 
> or is_ if the file is a text file:
> 
>   is_text
>   is_sticky
>   is_writable

I refer you to my previous message (archived in
http://tmtowtdi.perl.org/archive?35:mss:4575).  Basically, not have a
prefix predicates should have!

Another option is to stuff the long names into some namespace, and
export them upon request (or maybe not export them, upon request).

[...]

-- 
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd.  |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels

Re: RFC 283 (v1) C in array context should return a histogram

[Russ Allbery]

Paris Sinclair <[EMAIL PROTECTED]> writes:

> But as soon as a person labels me a minority, and implies that because I
> have been labeled such that I am a rioter, and that my opinions are
> based upon this label, then your choices are to filter me, or to listen
> to me protest.

Then perhaps you shouldn't have labelled him Euro-centric if you didn't
want a sarcastic response in kind.

I'd just prefer that we discussed the technical issues without this
pointless bickering.  If you were offended, fine; say you were offended
and move on.  I was offended by your implication that people who don't
agree with you are saying that only European scripts matter.  But please
don't escalate the argument as part of being offended.

I'll now stop replying to this thread.  Sorry for sticking my nose in; it
really bugs me when this happens in i18n discussions.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 283 (v1) C in array context should return a histogram

[Paris Sinclair]

>Could you please start from the assumption that we're all interested in
>supporting the full Unicode space to the greatest degree possible?  None
>of us are trying to force an ASCII-only alphabet on anyone (although some
>of us are interested in keeping ASCII-only operations fast and efficient
>since that's most of what we do).

I will start with no assumption. If my claim that what was said wasn't
compatible unicode and other encodings is false, pointing that out
would be more constructive than telling me to start making assumptions.

> > And, if my being or not being a minority is something that would effect
> > the value of my position, then you are even more dangerous than I had
> > suspected.
> 
> Comments like this don't help the discussion any.

Oh, I see, the problem isn't

> > > you're one of the persecuted minority

after all.

What a bunch of hogwash.

You don't like my comments? That is fine with me. I am only a user, and
you are something-or-other, and so you have the market cornered on the
right to be offended.

But as soon as a person labels me a minority, and implies that because I
have been labeled such that I am a rioter, and that my opinions are based
upon this label, then your choices are to filter me, or to listen to me
protest.

Yes, my aggressness is probably annoying to some people. Just like,
passive-aggressive sarcasm is annoying to me. I am sorry that this is
case.

Anyhow, I will not bother you anymore.

Re: RFC 283 (v1) C in array context should return a histogram

[Russ Allbery]

Paris Sinclair <[EMAIL PROTECTED]> writes:
> kOn Tue, 26 Sep 2000, Bennett Todd wrote:

>> Someone wrote:
>>> What's the upper bound in a 16bit language? Or does that case just
>>> have to break? "Sorry, you're not European. Please be assimilated
>>> before using this tool. Resistance is futile."

>> Lordie lordie lordie, you're one of the persecuted minority, and a
>> brand-waving rioter too. I've clearly stepped on a corn, not to mention
>> picked the wrong person to persecute. I'll go speak english to other
>> bigots who only speak english, and leave the future of the civilized
>> universe in your responsible hands.

> That's really ridiculous.

Bennett is reacting, I would assume, to the rather aggressive way of
phrasing arguments quoted above.  It's bothering me as well.  Could you
please start from the assumption that we're all interested in supporting
the full Unicode space to the greatest degree possible?  None of us are
trying to force an ASCII-only alphabet on anyone (although some of us are
interested in keeping ASCII-only operations fast and efficient since
that's most of what we do).

> And, if my being or not being a minority is something that would effect
> the value of my position, then you are even more dangerous than I had
> suspected.

Comments like this don't help the discussion any.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 283 (v1) C in array context should return a histogram

[Paris Sinclair]

kOn Tue, 26 Sep 2000, Bennett Todd wrote:

> > What's the upper bound in a 16bit language? Or does that case just
> > have to break? "Sorry, you're not European. Please be assimilated
> > before using this tool. Resistance is futile."
> 
> Lordie lordie lordie, you're one of the persecuted minority, and
> a brand-waving rioter too. I've clearly stepped on a corn, not to
> mention picked the wrong person to persecute. I'll go speak english
> to other bigots who only speak english, and leave the future of the
> civilized universe in your responsible hands.

That's really ridiculous. How do you know if I'm a minority? Mandarin is
the majority language, and it doesn't use 8bits. Not to say I speak
Mandarin. But, if you have to make assumptions about me to disagree with
my points, then it proves that your argument is flawed. And, if my being
or not being a minority is something that would effect the value of my
position, then you are even more dangerous than I had suspected.

As for a rioter, that is funny. I am not rioting, I am giving arguments in
support of an RFC. Am I "rioting" because I disagree with you?

Paris Sinclair|4a75737420416e6f74686572
[EMAIL PROTECTED]|205065726c204861636b6572
www.sinclairinternetwork.com

Re: RFC 283 (v1) C in array context should return a histogram

[Bennett Todd]

2000-09-26-21:56:04 Paris Sinclair:
> A "small" fixed upper bound? It is N that is bounded, that doesn't
> stop it from using N*50 variables to represent N, or N*150
> variables if I'm only matching vs 2 characters.

In big-O notation, the N is the size of the problem; in this case,
it could be the size of the alphabet, or the length of the string.
The rest of big-O notation describes the order of growth, ignoring
constant factors, of the resources consumed by the solution as a
function of the size of the input.

I was coding for reasonable-sized alphabets, so I used a simple
linear array; as I pointed out, if you have an alphabet of
preposterous size, where it's impractical to e.g. build a single
copy of it in memory, and any document's characters from that
alphabet are sparse, then use a hash.

> Perhaps instead of using O() I should have just said, "it is 0 to
> 150 times slower."

You're either going to build a dense array, which you can directly
subscript with some kind of ordinal value of the "letters", or
you're going to build a sparse array holding the chr => count map, a
hash. You can do either one inside the implementation of tr///. You
can do either one outside. There may be a significant performance
difference, there may not, that's not obvious to me.

> The overal algorithm, that is, I am assuming that this list is
> going to be iterated over.

You mean using something like 0..$#hist or keys(%hist)? Yup, I'd
expect that too. If the alphabet is reasonable sized, 0..$#hist is
so teensy it's free. If it's monster big, then keys(%hist) will be
scaling with the size of your input. Whether you do this with a loop
over split// incrementing array/hash buckets or whether it's done by
tr///, the O of the algorithms and their data structures are the
same.

> What's the upper bound in a 16bit language? Or does that case just
> have to break? "Sorry, you're not European. Please be assimilated
> before using this tool. Resistance is futile."

Lordie lordie lordie, you're one of the persecuted minority, and
a brand-waving rioter too. I've clearly stepped on a corn, not to
mention picked the wrong person to persecute. I'll go speak english
to other bigots who only speak english, and leave the future of the
civilized universe in your responsible hands.

Only kidding, I'm not about to let you off the hook that easy.

If you've got a variable-length coding where the values produced by
split /// are themselves strings, and ord() returns bignums, then
you need to

$hist{$_}++ for split //, $input;

and if you don't care to collect all the data, you're only
interested in xyz, then you can do various tricks; if someone forced
me to work in such a distressing environment, I might express it
something like

$hist{$_} = 0 for split //, "xyz";
for (split //, $input) { $hist{$_}++ if exists $hist{$_} }

or then again I might

for("$input") {
tr/xyz//cd; $hist{$_}++ for split //;
}

I dunno. If you expect some tr invocation to do something
reasonable and appropriate with weird multibyte encodings of
gigantic and sparse alphabets, do let us get this stated explicitly
in the RFC; otherwise it's not a reasonable argument for trying to
add this feature.

> > What's all this about eval?
> 
> That was in reference to my previous map example, which is the best
> general way I've seen proposed to handle the specified counting in p5.

Wow, I'd skipped that, now that you force me to review it, I see
why. Maybe it looks better when interpreted as UTF-32.

Perhaps neither of my previous constructs were as clean as

%hist = $input =~ tr/xyz//;

but then too, it's not awfully obvious just what that does, and it's
not something people need to do every day. If it's really cheap to
toss into the bucket, what the heck, I can't think of anything else
that the syntax would be better for. But I've also yet to hear
anything like a strong case made for it. For sure the ability to gen
up an equivalent expression that uses eval doesn't seem like
appealing grounds.

-Bennett

 PGP signature

Re: RFC 283 (v1) C in array context should return a histogram

[Paris Sinclair]

On Tue, 26 Sep 2000, Bennett Todd wrote:
> That sounds positively noble when you put it that way. I can
> actually hear choirs of cherubim providing atmosphere.

I heard them also, but I thought it was the radio.

> > And yes, a list of 250 items to store 5 items is HUGE. There is no way to
> > know how many items I will have.
> 
> Yup, but as long as you're working with 8-bit encodings the array
> will never get bigger than 256.

Who says I'm working with 8-bt encodings?!
Perl5 already has rudimentary support for multibyte encodings. So far I
haven't used them, but this is only because I'm dealing with my multibyte
input as binary data, and just passing it allong. Presumably I will want
to make some sanity checks once I learn enough to know what I'm checking
for.

When the Martians come out of hiding, we're going to have to add 13bit
fonts, so maybe we should keep our arbitrary character restrictions in the
core, in just one place, to make it easier to accomodate this inevitable
circumstance. If we make everything else general enough, we will be able
to meet their demands quicker, saving the world and bringing a new age of
prosperity to humankind.
 
> > O(N*50) is never going to make me happy.
> 
> O(1) should make you happy. It's got a small fixed upper bound.
> Unless, of course, split// and ord get interesting in the face of
> UTF-32 or something and the data is no longer bounded, in which case
> (as I said) your only hope is to change the [] to {}, at which point
> it's probably as fast as the hyper-sexy hash-building-tr///.

A "small" fixed upper bound? It is N that is bounded, that doesn't stop it
from using N*50 variables to represent N, or N*150 variables if I'm only
matching vs 2 characters. Perhaps instead of using O() I should have just
said, "it is 0 to 150 times slower." The overal algorithm, that is, I am
assuming that this list is going to be iterated over. Making this monster
list would add inefficiencies to each step in the algorithm. In any case,
that sollution doesn't seem to work, because of it's reliance on an
arbitrary set of conditions that are smaller than the conditions in the
problem domain. What's the upper bound in a 16bit language? Or does that
case just have to break? "Sorry, you're not European. Please be
assimilated before using this tool. Resistance is futile."

> What's all this about eval?

That was in reference to my previous map example, which is the best
general way I've seen proposed to handle the specified counting in p5.
Ugly as it is, there is hopefully a better way, but not one that is
obvious (to me). But given the changes proposed in RFC 283, it would not
only be easier, it would be more efficient, and fully compatible with
whatever character encodings Perl supports, now and into the future.

Paris Sinclair|4a75737420416e6f74686572
[EMAIL PROTECTED]|205065726c204861636b6572
www.sinclairinternetwork.com

Re: RFC 283 (v1) C in array context should return a histogram

[Bennett Todd]

2000-09-26-21:11:53 Paris Sinclair:
> Please keep your fetishes and/or geocentricism to yourself.

They get all ingrown and infested if I don't take 'em out and
air 'em out occasionally:-).

> There is no need to propose that others should share them.

No indeedy! I'm not opposed to i18n support in perl, or anywhere
else. In much the same way that I'm not opposed to various other
anti-discrimination measures even though I'm not in any of the
discriminated-against populations they aim to aid.

> If Perl is going to exist into the future, if Perl is going to be
> a great programming language for Humans, then it needs to support
> the different ways that Humans communicate.

That sounds positively noble when you put it that way. I can
actually hear choirs of cherubim providing atmosphere.

> Extending the context of C is an excellent general
> sollution to many problems, in many languages.

That's an interesting claim, and for all I know it could be true. If
folks believe it, and think it's a justification for the proposed
behavior in tr///, let's get this claim made nice and explicit in
the RFC, is all I'm saying.

> And yes, a list of 250 items to store 5 items is HUGE. There is no way to
> know how many items I will have.

Yup, but as long as you're working with 8-bit encodings the array
will never get bigger than 256.

> O(N*50) is never going to make me happy.

O(1) should make you happy. It's got a small fixed upper bound.
Unless, of course, split// and ord get interesting in the face of
UTF-32 or something and the data is no longer bounded, in which case
(as I said) your only hope is to change the [] to {}, at which point
it's probably as fast as the hyper-sexy hash-building-tr///.

> Which is why right now I would have to use a funky C
> and C.

You've lost me. If you want a hash, what's wrong with:

$hist{$_}++ for split //, $string;

What's all this about eval?

-Bennett

 PGP signature

Re: RFC 283 (v1) C in array context should return a histogram

[Paris Sinclair]

On Tue, 26 Sep 2000, Bennett Todd wrote:

> Yup, I'm a sick little monkey who truly doesn't care about anything
> other than US-ASCII

Please keep your fetishes and/or geocentricism to yourself. There is no
need to propose that others should share them. If Perl is going to exist
into the future, if Perl is going to be a great programming language for
Humans, then it needs to support the different ways that Humans
communicate.

It's doing a better job at it all the time. Extending the context of
C is an excellent general sollution to many problems, in many
languages. While it has been suggested that C isn't for
counting... well, the p5 manual says it IS for counting, amoung other
things. If it is a general language tool that makes counting easy as a
side effect, this is wonderful. And if making it a more general tool by
extending it's context makes it even better for counting, who does this
hurt? There are certainly those of us it would help.

And yes, a list of 250 items to store 5 items is HUGE. There is no way to
know how many items I will have. O(N*50) is never going to make me
happy. Which is why right now I would have to use a funky C
and C. Or a map and a match and an index, but that's a lot of
frivilous temp variables.

Paris Sinclair|4a75737420416e6f74686572
[EMAIL PROTECTED]|205065726c204861636b6572
www.sinclairinternetwork.com

Re: RFC 283 (v1) C in array context should return a histogram

[Bennett Todd]

2000-09-26-20:29:22 Paris Sinclair:
> On Tue, 26 Sep 2000, Bennett Todd wrote:
> > $hist[ord($_)]++ for split //, $string;
> 
> But would technique work with unicode?

Beats me, I've never tried programming against unicode, as I don't
speak any other language than english I don't expect I will do so in
the future either. I expect the answer to your question depends
partly on details of the encoding, and partly on the implementations
of split and ord in a unicoded-infested world.

Could be someone would try and feed some kanji through it or
something and produce a sparse array a trillion bytes long, for all
I know. If you're worried about a scary sparse alphabet, switch the
[] to {} and use a hash:-).

> What if I am just counting some Bulgarian characters? Most
> encodings put these in the extended ascii range. Making an array
> of 250 items for a count of 5 items isn't going to be more
> efficient.

I'd expect it would; an array of 250 items is teensy.

> Also, it requires jumping through more hoops, and doing
> more conversions, to figure out which index is which letter.

Yup, I'm a sick little monkey who truly doesn't care about anything
other than US-ASCII, and doesn't mind the mildly extended encodings
like ISO 8859-1 because they include ASCII as their 7-bit subset; if
I get a text file and it's not in ASCII I can't read it anyway, so I
toss it.

> A table could be built, but if it maps to an array index, based on
> ord(), then I couldn't support both KOI-8 and windows cyrillic
> encodings in the same @hist structure.

If you're gonna have both KOI-8 and windows cyrillic encodings in
the same single string being passed to split, I am really really
glad I don't share your problems. I'll stand way, way back, thanks.

If you're getting from different sources, you could map them as you
consolidate them. But I think most folks would go for a single
common encoding before they even began examining the contents.

> Using a hash, the only limits are the more general language
> supports in Perl, and I can still convert and store KOI8 and
> cp1251, and store the results without needing to know which coding
> it originated in; only needing to have a symbol for the character.

If the purpose for including histogram-generation as a builtin to
perl, as a context-triggered side-effect of tr///, is to support
i18n, let's do please make that very explicit in the RFC. If we
don't, the requirements to make that work might not get thought
completely through and the desired i18n might not actually work. Oh,
and if the implementation is going to have to do all the right
brilliant stuff for i18n in the face of every conceivable encoding,
I expect it's not gonna be faster than the hash-based equivalent
construct:

$hist{ord($_)}++ for split //, $string;

which only requires that split// and ord do something appropriately
consistent across encodings.

But when people claim i18n benefits for things I tend to just go
away to my corner and get quiet, since I don't planning on doing
multilingual code or work with multilingual data, I don't feel
qualified to hold an opinion.

-Bennett

 PGP signature

Re: RFC 283 (v1) C in array context should return a histogram

[Paris Sinclair]

On Tue, 26 Sep 2000, Bennett Todd wrote:

> 2000-09-26-05:18:57 Paris Sinclair:
> > > (%alphabet) = $string =~ tr/a-z//;
> > 
> > also a little more concise (and certainly more efficient...) than
> > 
> > %alphabet = map { $_ => eval "\$string =~ tr/$_//" } (a..z);
> 
> However, compared to say
> 
>   $hist[ord($_)]++ for split //, $string;
> 
> the performance edge might not be quite so dramatic. Then again,
> maybe it would be, I dunno.

But would technique work with unicode? What if I am just counting some 
Bulgarian characters? Most encodings put these in the extended ascii
range. Making an array of 250 items for a count of 5 items isn't going to
be more efficient. Also, it requires jumping through more hoops, and doing
more conversions, to figure out which index is which letter. A table could
be built, but if it maps to an array index, based on ord(), then I
couldn't support both KOI-8 and windows cyrillic encodings in the same
@hist structure. Using a hash, the only limits are the more general
language supports in Perl, and I can still convert and store KOI8 and
cp1251, and store the results without needing to know which coding it
originated in; only needing to have a symbol for the character.

There seem to be lots of beneficial side effects of extending context,
that allow for general sollutions that are much more powerful than any of
the specific sollutions.

Paris Sinclair|4a75737420416e6f74686572
[EMAIL PROTECTED]|205065726c204861636b6572
www.sinclairinternetwork.com

Re: RFC 290 (v1) Remove -X

[Alan Gutierrez]

On Tue, 26 Sep 2000, 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. also the common prefix will make it clear tha tthey
> are part of the family of file test ops.
> 
> here are some ideas which you can shoot down:
> 

Thought I'd add to the list of target ideas that someone else has
already proposed:

file ('/dev/null', 'rwx')

And I agree with Uri that a pragma is the way to go if we are going to
havea all those new function names.

Alan Gutierrez

Re: perl6storm #0050

[Simon Cozens]

On Tue, Sep 26, 2000 at 12:43:07PM -0700, Robert Mathews wrote:
> Ok, you've proved that lisp doesn't make sense without all those
> annoying parentheses.  Congratulations.  Fortunately, perl isn't lisp.

Correct, John bringing lisp into the discussion *was* a canard.

-- 
Writing software is more fun than working.

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

[Ilya Zakharevich]

On Mon, Sep 25, 2000 at 09:10:49PM -0700, Nathan Wiger wrote:
>if ( want->{count} > 2 ) { return $one, $two }
> 
> Will that be interpreted as:
> 
>'want'->{count}
>want()->{count}
> 
> To be consistent, it should mean the first one. That is, the infix
> operator -> should always autoquote the bareword to the left. Am I
> correct in assuming that's what you meant?

Yes.  Use want()->{count} instead.  Or, better, 

  use want;
  wantCount;

Ilya

Re: RFC 290 (v1) Remove -X

[Nathan Wiger]

Uri Guttman wrote:
> 
> not the best. would that be confused with a sub readable and a leading
> unary negation? in fact how does perl parse -r now vs - r()?

Yes it would, here's how Perl parses these right now:

perl -w -e '
  sub r { local $\; print "&r(@_) : "; }
  $\ = "\n";
  print "-r" if -r "/etc/motd";
  print "-r()" if -r("/etc/motd");
  print "- r" if - r "/etc/motd";
  print "- r()" if - r("/etc/motd");
'

Prints out:

  -r
  -r()
  &r(/etc/motd) : - r
  &r(/etc/motd) : - r()

Basically, the -r filetest always wins. Injecting a space makes the &r
sub always win, as would be expected.

-Nate

Re: RFC 290 (v1) Remove -X

[Uri Guttman]

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:

  NW> I think perhaps that Uri was suggesting more a common letter prefix,
  NW> such as:

  NW>   freadable($file);
  NW>   fwritable($file);
  NW>   fexecutable($file);

  NW> Than a piece of bastardized Pythonesque syntax. ;-)

basically correct. even a - as a prefix will be nicer and closer to the
original -X stuff. but that might conflict with the -rwx ideas (which i
am not fond of anyway).

if ( -readable( $filename ) ) {

not the best. would that be confused with a sub readable and a leading
unary negation? in fact how does perl parse -r now vs - r()?

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 290 (v1) Remove -X

[Uri Guttman]

> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:

  AT> On Tue, Sep 26, 2000 at 02:13:41PM -0400, Uri Guttman wrote:
  >> 
  AT> But I wouldn't want that pragma to override any other aspect of the
  AT> core library, such as async I/O.

agreed. but we can reconcile the name spaces then. or let larry do
it. :)


  AT> That's a stone's throw awaty from:

  AT>   import english
  AT>   from english import filetest

  AT>   result = filetest.readable("/dev/null")

blecchh!

  AT> I think the common prefix idea is a nonstarter.  There must be a way
  AT> to coming up with sensible names for all of -X that don't conflict
  AT> with the core library.  Besides, AIO has a requirement on 
  AT> 'sub Foo::readable()',  which means that main::readable is still 
  AT> accessible and doesn't conflict.  No, that's not desirable, but AIO
  AT> behavior looks more malleable to me.

what about my idea for is_ or has_? actually that could be used for
callbacks as well. we need some semantic distance from the socket/handle
is readable right now (buffers have data) and the file can be read
if/when it is opened (you can test an open handle too IIRC).

  >> i have not seen an attempt to name all of
  >> the -X ops yet. 

  AT> v2 fast approaching.  ;-)

awaiting with my whip so i can shred your names. :)

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: perl6storm #0050

[John Porter]

Simon Cozens wrote:
> 
> Maybe you'd prefer this:
> 
> defun Schwartzian func list mapcar lambda x car x sort mapcar 
> lambda x cons x funcall func x list lambda x y < cdr x cdr y

What happened to the newlines?

Also, "no parens" is not the only alternative to having parens.
Other punctiation is available.  One of the improvements
ML makes over Lisp is the use of different bracketers to
signify semantically different kinds of lists.


-- 
John Porter

Aus des Weltalls ferne  funken Radiosterne.

Re: perl6storm #0050

[Robert Mathews]

Simon Cozens wrote:
> (defun Schwartzian (func list)
>   (mapcar
>(lambda (x) (car x))
>(sort
> (mapcar
>  (lambda (x) (cons x (funcall func x)))
>  list
>  )
> (lambda (x y) (< (cdr x) (cdr y)))
> )
>)
>   )
> 
> Maybe you'd prefer this:
> 
> defun Schwartzian func list mapcar lambda x car x sort mapcar
> lambda x cons x funcall func x list lambda x y < cdr x cdr y
> 
> I know which I'd rather read.

Ok, you've proved that lisp doesn't make sense without all those
annoying parentheses.  Congratulations.  Fortunately, perl isn't lisp.

Why does removing the parens force you to jam everything together on two
lines?  The only reason I can think of is that you're using some fancy
autoindenting lisp editor.  Fortunately, perl doesn't force you to use a
special editor just to tame the obvious shortcomings of the language
syntax.

Perl *lets* you include parentheses, or not, whichever makes the code
easier to read.  Yeah, you can write ugly or broken code by leaving too
many out.  So?

-- 
Robert Mathews
Software Engineer
Excite@Home

Re: RFC 283 (v1) C in array context should return a histogram

[Bennett Todd]

2000-09-26-05:18:57 Paris Sinclair:
> > (%alphabet) = $string =~ tr/a-z//;
> 
> also a little more concise (and certainly more efficient...) than
> 
>   %alphabet = map { $_ => eval "\$string =~ tr/$_//" } (a..z);

However, compared to say

$hist[ord($_)]++ for split //, $string;

the performance edge might not be quite so dramatic. Then again,
maybe it would be, I dunno.

-Bennett

 PGP signature

perl6storm #0073

[Nicola Meade]

No, not for 

   use 'strict';

That is not a bareword.  Hard to say why (have short time).
Only "$a = fred" is a bareword.  But "require Module", is not,
as it has another meaning, and is accomodated in the grammar.
Likewise, a prototype of sub fn(*) is not a bareword when
you call fn(Whatever).

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: PERL6STORM - tchrist's brainstorm list for perl6

[Nicola Meade]

Yes, while still allowing an explicit A()->B(), of course.
I just meant that A->B means A::->B(), or, if you would, "A"->B().
But A()->B would not change in meaning.

--tom, posting blind(ly)

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

perl6storm #0010: kill all defaults

[Nicola Meade]

Yes,  Phil, I mean things like abs() meaning abs($_) and
localtime() meaning localtime(time).
Actually, combined with the paren requirement thingie, it means
localtime(time()), and localtime
has to be written localtime().   These are two different suggestions,
though.

This is an attempt at sending from an account I can't get mail from, or
to, or read.
So I can only read this if it makes the public list.


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: perl6storm #0011: interactive perl mode

[Nicola Meade]

Russ, you can use "perl -" to punch/paste into that window.
But "foo | perl" would not be affected as you would not
be running interactively.  Essentially, only if there
are no arguments and stdin (and stdout) areatty would you
do that.

--tom, posting blind

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: RFC 290 (v1) Remove -X

[John L. Allen]

On Tue, 26 Sep 2000, Nathan Wiger wrote:

> I think perhaps that Uri was suggesting more a common letter prefix,
> such as:
> 
>   freadable($file);
>   fwritable($file);
>   fexecutable($file);
> 
> Than a piece of bastardized Pythonesque syntax. ;-)

Was that what the foo.bar("baz") syntax was?  I thought that was in another 
RFC I had to hunt down and read :-)  But I think I like this anyway:

  -f.r($file);# same as -r $file
  -f.rwx($file);  # same as -rwx $file

etc.  Or leave off the -, or even the -f ... oh well, I guess there are 
syntax possibilities ad nauseum, but none very satisfying.

John.

Re: RFC 290 (v1) Remove -X

[Nathan Wiger]

Adam Turoff wrote:
>
> 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. 

I think perhaps that Uri was suggesting more a common letter prefix,
such as:

  freadable($file);
  fwritable($file);
  fexecutable($file);

Than a piece of bastardized Pythonesque syntax. ;-)

-Nate

Re: perl6storm #0050

[Simon Cozens]

On Tue, Sep 26, 2000 at 02:06:47PM -0400, John Porter wrote:
> > Since when do parentheses make things less readable?
> 
> Can you say "lisp"?

"lisp".

(defun Schwartzian (func list)
  (mapcar
   (lambda (x) (car x))
   (sort
(mapcar
 (lambda (x) (cons x (funcall func x)))
 list
 )
(lambda (x y) (< (cdr x) (cdr y)))
)
   )
  )

Maybe you'd prefer this:

defun Schwartzian func list mapcar lambda x car x sort mapcar 
lambda x cons x funcall func x list lambda x y < cdr x cdr y
 
I know which I'd rather read.
   

-- 
God gave man two ears and one tongue so that we listen twice as much as
we speak.
-- Arab proverb

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 292 (v1) Extensions to the perl debugger

[Dave Storrs]

On 26 Sep 2000, Johan Vromans wrote:

> Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> 
> > The ability to easily retrieve and edit your N most recent commands to the
> > debugger (much like a bash_history).
> and
> > A better default pager.  The default pager should assume a 24x80 term
> > window ...
> 
> To me, these clearly indicates that the debugger should be run as a
> subsystem of some other tool that takes care of this. It is not part
> of the debugger itself. For example, take a look at how emacs runs the
> debugger.


I'm confused...are you suggesting that the debugger should no
longer be integrated into perl?  If so, I disagree...I absolutely insist
that, no matter what pathological distribution someone may put together
for Perl, I will get the debugger so at least I have a chance of figuring
out what's wrong. The only way to absolutely ensure this is to have it
built into the interpreter itself.

As to the history file...this is something that I've wanted since
I first touched the debugger, and I suspect others would like it as well.
As to the pager...the "default pager" is currently "no pager", which is
silly.  I distinctly remember having the following thought pattern, from
back when I was learning how to use the debugger:


"Ok, what commands are available?  Let's type 'h' "

"Hmm...it scrolls off the screen...aha! look, down here at the
bottom it says I can do '|dbcmd' to pipe the output of a debugger command
through the current pager!  Excellent, that's just what I need."

" '|h' " [it runs off the screen again]

"DOH!"


All humor aside, there is too much information in the debugger
help screen to fit in 50 lines.  That means that anyone trying to use the
debugger through a DOS window, or a fixed-size telnet client, can't see
the majority of the information.

Dave

Re: proposed RFC. lindex() function...

[Webmaster]

Dear Iain,
I had a few moments, so I tried to put together a subroutine that would
express what I was thinking. It's attached with the script that I used to
test it.
Grant M.
[EMAIL PROTECTED]


 lndxexmp.pl
 lindex.pl

Re: RFC 290 (v1) Remove -X

[Uri Guttman]

> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:

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

well, that is debatable. i rarely seem to use -X operators as i just
check for the failure of open in most cases. as for my callback names, i
had them first. :)

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. 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. i have not seen an attempt to name all of
the -X ops yet. i think it will be obvious that a prefix would be good
to make them all have a similar style. and what about the -r/-r name
space? please address those issues and later we can fight over who owns
the name readable! :)

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 320 (v1) Allow grouping of -X file tests and add C builtin

[Nathan Wiger]

John Porter wrote:
> 
> Yeah, not to mention the fact that many modules, notably CGI.pm,
> are arranged to allow to use unquoted strings of the form -name:
> 
> print textfield( -name => 'description' );

Well, this one's not an issue, because => auto-quotes the LHS. It's the
same as this:

  print textfield( "-name", 'description' );

Which obviously wouldn't be a problem.

> John L. Allen wrote:
> >
> > I can't believe that special-casing the token -[rwxoRWXOezsfdlpSbctugkTBMAC]+
> > is an acceptble solution.  I mean think of all the existing perl keywords
> > that that already matches: -pos, -cos, -lc, -uc, -fork, -use, -pop, -exp,
> > -oct, -log, -ord + others!.  A lot of these already have a legitimate
> > not-filetest meaning, others not :-)

Obviously, I wouldn't want to push incompatibility. But I personally
have never wanted to say:

   $result = -exp($num);

So badly that this:

   $result = - exp($num);

Would be too much of a burden. There's only a very small number of
functions where direct negation would even make sense, as you yourself
note. And a simple space or set of parens would be all you'd need.

Any type of -syntax runs the risk of these problems. For example:

   -r $file; # sub r {} already broken
   -rwx $file;   # now many more broken
   -1;   # still works ok

   -[rwx];   # negation of an arrayref
   -{rwx};   # negation of a hashref
   -/rwx/;   # negation of a pattern match
   -(rwx);   # negation of a list
   -^rwx;# negation of a higher-order function
   -!rwx;# negation of boolean test
   -#rwx#;   # negation of a comment

Basically, the - is already used as a negation symbol, which is a unary
operator and as such can be attached to anything. Perl already has a
special catch in the grammar so that these two:

   $num = -1;
   $str = -r;

Do not work the same. Simply make a blanket rule that -[a-zA-Z]+ is
always special. Then the documentation that says:

http://www.perl.com/pub/doc/manual/html/pod/perlfunc/_X.html

   Note that -s/a/b/ does not do a negated substitution.
   Saying -exp($foo) still works as expected, however--
   only single letters following a minus are interpreted as
   file tests.

Could be changed to:

   A - following by any purely alpabetic string will not
   negate that string. Saying -exp($foo) will attempt a
   file test on $foo. However, saying - exp($foo) will
   work as expected -- a single space is all that is
   needed. Note -1 and other numbers will always work.

If we decide to extend the filetest mechanism, then we're going to run
into problems with the unary negation - no matter what syntax we choose.
I personally think that just making -string special is a simple,
consistent rule. If someone really needs to negate a string, they simply
insert a space.

However, any notation that made sense and did not introduce
incompatibility or inconsistency of some sort would be welcome.

-Nate

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: perl6storm #0050

[John Porter]

Johan Vromans wrote:
> Philip Newton <[EMAIL PROTECTED]> writes:
> 
> > so fewer "cluttering"
> > parentheses are needed to make things readable while still being correct.
> 
> Since when do parentheses make things less readable?
> What is your definition of readable?

Can you say "lisp"?

-- 
John Porter

Re: RFC 290 (v1) Remove -X

[Clayton Scott]

"John L. Allen" wrote:
> The use of a caret was to prevent decimation of the user's namespace,
>
> perl -e 'print -^rwx $_'
> syntax error at -e line 1, near "-^"
> Execution of -e aborted due to compilation errors.

The only problem I have with a caret is that to me the proposal 
 doesn't "jibe" with it's current use of negating a character class in
 a regexp and it's proposed use for currying.

Clayton

Re: perl6storm #0050

[Johan Vromans]

Philip Newton <[EMAIL PROTECTED]> writes:

> so fewer "cluttering"
> parentheses are needed to make things readable while still being correct.

By the same reasoning, you can reduce the use of curlies by using
indentation to define block structure.

-- Johan

Re: perl6storm #0050

[Johan Vromans]

Philip Newton <[EMAIL PROTECTED]> writes:

> so fewer "cluttering"
> parentheses are needed to make things readable while still being correct.

Since when do parentheses make things less readable?
What is your definition of readable?

-- Johan

Re: RFC 292 (v1) Extensions to the perl debugger

[Johan Vromans]

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

> The ability to easily retrieve and edit your N most recent commands to the
> debugger (much like a bash_history).

and

> A better default pager.  The default pager should assume a 24x80 term
> window ...

To me, these clearly indicates that the debugger should be run as a
subsystem of some other tool that takes care of this. It is not part
of the debugger itself. For example, take a look at how emacs runs the
debugger.

-- Johan

Re: RFC 320 (v1) Allow grouping of -X file tests and add C builtin

[John Porter]

John L. Allen wrote:
> 
> I can't believe that special-casing the token -[rwxoRWXOezsfdlpSbctugkTBMAC]+
> is an acceptble solution.  I mean think of all the existing perl keywords 
> that that already matches: -pos, -cos, -lc, -uc, -fork, -use, -pop, -exp, 
> -oct, -log, -ord + others!.  A lot of these already have a legitimate 
> not-filetest meaning, others not :-)  

Yeah, not to mention the fact that many modules, notably CGI.pm,
are arranged to allow to use unquoted strings of the form -name:

print textfield( -name => 'description' );

-- 
John Porter

Aus des Weltalls ferne  funken Radiosterne.

Re: RFC 290 (v1) Remove -X

[Uri Guttman]

> "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. also the common prefix will make it clear tha tthey
are part of the family of file test ops.

here are some ideas which you can shoot down:

a minus prefix like the current -r

-readable
-tty

or has_ as the file has read permission:

has_readable
has_executable

or is_ if the file is a text file:

is_text
is_sticky
is_writable

also you have to differentiate -R from -r.

is_euid_readable
is_ruid_writeable

and then names for -M/A/C don't work with is/has:

file_mod_time
file_access_time


i don't mind having the longer names as an option, but it should be a
pragma/module and the namespace has to be clean.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 320 (v1) Allow grouping of -X file tests and add C builtin

[John L. Allen]

On 26 Sep 2000, Perl6 RFC Librarian wrote:

> =head1 TITLE
> 
> Allow grouping of -X file tests and add C builtin

Nice summary.  Thanks.

> =head1 IMPLEMENTATION
> 
> This would involve making C<-[a-zA-Z]+> a special token in all contexts,
> serving as a shortcut for the C builtin.
> 
> =head1 MIGRATION
> 
> There is a subtle trap if you are negating subroutines:
> 
>$result = -drwx $file;
> 
> And expect this to be parsed like this:
> 
>$result = - &drwx($file);
> 
> However, usage such as this is exceedingly unlikely, and can simply be
> resolved by the p52p6 translator looking for C<-([a-zA-Z]{2,})> and
> replacing it with C<- $1>, since injecting a single space will break up
> the token.

I can't believe that special-casing the token -[rwxoRWXOezsfdlpSbctugkTBMAC]+
is an acceptble solution.  I mean think of all the existing perl keywords 
that that already matches: -pos, -cos, -lc, -uc, -fork, -use, -pop, -exp, 
-oct, -log, -ord + others!.  A lot of these already have a legitimate 
not-filetest meaning, others not :-)  So it still seems to me that some 
sort of disambiguating syntax is needed, if not actually findable, to 
save this filetest grouping idea of mine from the scrap heap.  I guess 
the p5-to-p6 converter could still resolve this as you stated, but I just 
don't like it...

John.

Re: RFC 320 (v1) Allow grouping of -X file tests and add C builtin

[Jonathan Scott Duff]

On Tue, Sep 26, 2000 at 05:53:13AM -, Nate Wiger wrote:
> Currently, file tests cannot be grouped, resulting in very long
> expressions when one wants to check to make sure some thing is a
> readable, writeable, executable directory:
> 
>if ( -d $file && -r $file && -w $file && -x $file ) { ... }

Non-novice perl programmers would probably write this as you have
below with the special _ filehandle.  Perhaps you should move that to
the fore and comment on it's unreadability and general ickiness :-)

> It would be really nice if these could be grouped instead:
> 
>if ( -drwx $file ) { ... }

Indeed it would.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 290 (v1) Remove -X

[Jonathan Scott Duff]

On Tue, Sep 26, 2000 at 12:34:00AM -0400, Adam Turoff wrote:
> Making '@permissions = -rwx $filename;' work is an interesting new
> suggestion.

Yep.

> Of course, I should say that I've been hanging out with some
> snake-hearders recently.  

Hey, we could learn a thing or two from some snake herders.  (Watch
how they get bit and don't do the same ;-)

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

Excellent.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

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

[Jonathan Scott Duff]

On Tue, Sep 26, 2000 at 12:04:50AM -0400, Adam Turoff wrote:
> 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?

I wouldn't think so.  Tainting is a Perl thing.  Perl does it's best
to mark "unsafe" things as tainted.  What's unsafe and Perl's best
vary from platform to platform, but tainting still happens.  (But this
is from a guy who has only used but 6 or 7 of the OSes that Perl has
been ported to)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

RE: RFC 264 (v1) Provide a standard module to simplify the creation of source filters

[Paul Marquess]

From: Damian Conway [mailto:[EMAIL PROTECTED]]

...
>
> No. That's my point. I want to match BANG followed by maximal whitespace
> followed by another BANG. But a line-by-line filter fails dismally if that
> maximal whitespace contains a newline.
>
> Admittedly this particular example is contrived for effect, but I have
> now used your excellent module in numerous projects when constructs *can*
> cross newline boundaries and it's always painful to do (hence the new
> module). In fact, I would claim that filtering constructs across
> newline boundaries is the *norm*, since newlines are just whitespace most
> places in Perl.

Aaah! I see where you are coming from now. Is that mentioned in the RFC and
module docs? If not, it really needs to be emphasised. It completely passed
me by.

If you like, next time I do a Filters release, I'll update my documentation
to mention your module.

Paul


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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 283 (v1) C in array context should return a histogram

[Paris Sinclair]

On Mon, 25 Sep 2000, Simon Cozens wrote:

> On Mon, Sep 25, 2000 at 09:55:38AM +0100, Richard Proctor wrote:
> > While this may be a fun thing to do - why?  what is the application?
> 
> I think I said in the RFC, didn't I? It's extending the counting use of tr///
> to allow you to count several different letters at once. For instance, letter
> frequencies in text is an important metric for linguists, codebreakers and
> others; think about how you'd get letter frequency from a string:
> 
> $as = $string =~ tr/a//;
> $bs = $string =~ tr/b//;
> $cs = $string =~ tr/c//;
> ...
> $zs = $string =~ tr/z//;
> 
> Ugh.
> 
> (%alphabet) = $string =~ tr/a-z//;
> 
> Yum.

also a little more concise (and certainly more efficient...) than

%alphabet = map { $_ => eval "\$string =~ tr/$_//" } (a..z);

Context is beautiful; it's at least 50% of the reason I love Perl. I would
love to see it extended here.

Paris Sinclair|4a75737420416e6f74686572
[EMAIL PROTECTED]|205065726c204861636b6572
www.sinclairinternetwork.com

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

[Alan Gutierrez]

On Tue, 26 Sep 2000, iain truskett wrote:

> * Adam Turoff ([EMAIL PROTECTED]) [26 Sep 2000 17:15]:
> > 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'.

Agreed. The bottleneck in standard CGI is not parsing the query string
or form post, it is the fork.
 
> > 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.

Make it so. Find a way to turn tainting on for CGI. But don't clutter
the core with application specific functions. Doesn't everyone want to
remove the sockets library from the core?

> But is anything else? I like what Nathan Wiger suggested --- that of the
> common headers function, but I also believe that belongs as a separate
> module. Hence:

 Nice code Mr. Truskett.

Agreed. Split CGI into component parts. If all you want is headers, or
cookies, then you can use those modules without incurring the penalty of
loading all of CGI.pm.

> > > > Robust input parsing: yes.
> > > 
> > > > General purpose output formatting: no, [...]
> > > 
> > > > Rudimentary HTTP header emission: probably.

So this is the definition of first-class? 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.

> > > I think it all belongs in the CGI module really.
> 
> > Then you're probably against this proposal.  No biggie.
> 
> Yeah. I contemplated saying that outright in the previous one but was
> having trouble phrasing it in a friendly sense =)

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?

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

Tainting sure. Functions no.

Alan Gutierrez

Re: RFC 143 (v2) Case ignoring eq and cmp operators

[Markus Peter]

"David L. Nicol" wrote:
> 
> > Perl currently only has C and C operators which work case-sensitively.
> > It would be a useful addition to add case-insensitive equivalents.
> 
> As I recall, the consensus the last time this came up was that C and
> C would be perfect examples w/in a RFC proposing a way to declare
> a function to take it's arguments in infix instead of prefix manner.

Well - it only came to the list again as I retired the RFC as most
people
thought this was not important enough :-)

-- 
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

[Paris Sinclair]

On 24 Sep 2000, Perl6 RFC Librarian wrote:

> Eliminate unquoted barewords from Perl entirely

Ugh, don't force me to select a One True Way, PLEASE. I don't think there
is really any unresolvable ambiguities the way it is in Perl5. Lets not
sacrifice the ability to do it the right way, just to prevent people from
doing it the wrong way. That is to say, P6 should be P5++, not P5--.

Paris Sinclair|4a75737420416e6f74686572
[EMAIL PROTECTED]|205065726c204861636b6572
www.sinclairinternetwork.com