perl should be improved and perl6

[John Bokma]

I've been doing so for years son

I hate to break the news, you being the product of severe inbreeding
doesn't make me your son.

 

[Andrew DeFaria]

I hate to break the news, you being the product of severe inbreeding
doesn't make me your son.

Care to post something relevant?

You are my son in that you are my intellectual inferior son. I see you
decided to neglect everything else I said, thereby cementing the fact
that you're being totally intellectually dishonest as well as inferior.

Now git back in the house 'cause momma needs to give you a whooping fer
sure!

I've already spanking you so many ways my hand hurts....

 

[Gordon Etly]

Yes there is. I can be hired as a Perl programmer, but if you are
looking for a perl programmer, I have to turn your project down.

Based on 'man perl' or 'perdoc perl', you would be wrong to pass
rejection on these grounds.


$ perldoc perl | head -n 6
PERL(1) User Contributed Perl Documentation PERL(1)


NAME
perl - Practical Extraction and Report Language


So according to Perl's own documentation, PERL or perl, Perl, "Practical
Extraction and Report Language" are all perfectly reasonable.

Who do you trust more? People who make a living working with Perl on a
daily basis, who have contributed to the language in one way or
another, or some dictionary entry?

I trust perldoc and the man pages. Or do they suddenly not matter
anymore?

Do 'man perl' or 'perldoc perl' yourself.

Based on my experience of quite some years: *anyone* I have seen
constantly refering to Perl as PERL had either never programmed a
single line in Perl, or was an absolute newbie.

Complete nonsense. Anyone who has read Perl's own documentation could
say PERL or perl or "Practical Extraction and Report Language" and be
perfectly legitimate programmers.

Seems also hypocritical, considering
some of the more well known people in this group are known for doing
thing differently (Abigail for her interesting alternate forms of
quoting in replies,

Yes, used to annoy me as well. But the alternate quoting has nothing
to do with Perl or perl (heh, or a lot ;-) ), and the value of the
content of *his* [1] posts severely outweights the quoting.

Well I would say the way someone write the word "perl" is just as
harmless, yet some of you insist on being so stubborn, despite how
Perl's own docs prove you wrong.

Yeah, those people who have English as their second lenguage :-D.

English isn't the only language to capitalize at the beginning of a
sentence, proper nouns, etc.

If his piece was well written, nobody would have made a point of his
misspelling of Perl.

Why make such a point at all? As far as I'm concerned, considering how
'man perl'/'perldoc perl' put it, there is NO reason to make such a
point in the first place, or do Perl's own docs not matter when it's
inconvenient?

 

[Gordon Etly]

Uri avoids the shift key for one reason or another. Regs here don't
mistake Uri for a newbie, and hence read over this.

But he's telling everyone else to use "Perl" and instead writes
"perl"... is there nothing wrong with that picture? Especially if Perl's
own docs point to the contrary?

The problem with people who use PERL, or perl if they mean Perl, and
vice versa, often are newbies.

Or they actually read Perl's documentation. Or again, does perldoc/man
suddenly not matter because it's inconvenient?

 

[Gordon Etly]

Oops, you just lost any credebility :-D

While on UseNet you generally do not post HTML, since you have pointed
out there is plain-text version, should not a sensible news reader use
only that part if all you want is plain-text, just as any sensible mail
reader does? This is how mine behaves. Surely what ever reader you have
could do the same?

With that said, it would be nice to keep everything in plain-text only,
though in this day and age, I don't think it should be so surprising to
see messages in multiple formats?

 

[Gordon Etly]

John Bokma wrote:
...
Moreover, Perl is the programming language, and perl is the
executable, hence there is a good reason to be case sensitive.
Hence, perl [...] is poorly typed seems to refer to the
executable, hence Dr. Ruud's question.
As someone else pointed out, in many other groups centered around
a particular programming language, no one pays this kind of
attention of people like your self seem to.
Have you tried posting a question about a non-existence language
called C/C++ in comp.lang.c?

Yes I have. They are related languages. C++ is based on C. Most
people seem to understand that, while also understanding what sets
them apart.

Think of the distinction between Perl and perl a clue-meter.

But that is just wrong. If the man/perldoc page for "perl" reads
like, $ perldoc perl | head -n 10
PERL(1) User Contributed Perl Documentation PERL(1)
^^^^

Are you saying that the roff(7) formatting of a header implies
something?

Actually, yes. Because any perldoc or man I've tested on 8 different
types of platforms all display it the same way and this is how people
would read it. Even man2html shows "PERL (1)" at the top.

Although, it's not so much the header formatting (maybe I should not of
underscored on the header), it's the fact that (which you conveniently
snipped: ),


$ perldoc perl | head -n 10
PERL(1) User Contributed Perl Documentation PERL(1)

NAME
perl - Practical Extraction and Report Language
^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

"Practical Extraction and Report Language" implies an acronym in some
way or another, and so you cannot really blame someone for using "perl"
or "PERL" as both forms could be used to denote an acronym. Since this
is in the main Documentation for Perl, then it is fair game, unless you
no longer consider Perl's own documentation to be of value.

 

[Andrew DeFaria]

And the IETF.

Or was never really a part of, as the case probably is... In any case,
ASCII "art", as the kind referred to here, is decidedly inferior to all
other arts. Besides I have no requirement to admire or respect it.
Respect is earned!

 

[Andrew DeFaria]

[...]

Yes, used to annoy me as well. But the alternate quoting has nothing
to do with Perl or perl (heh, or a lot ;-) ), and the value of the
content of *his* [1] posts severely outweights the quoting.

Foot note not found.

Perhaps because his foot is inserted in his mouth!

 

[Gordon Etly]

IMO a good Perl programmer knows the difference between Perl and perl,
and knows when to use which one.

There you go again, completely ignoring what 'man perl' and 'perldoc
perl' say:

I would think a good programmer would also have read Perl's own
documentation, which validates the usage of Perl as an acronym:

$ perldoc perl | head -n 10
PERL(1) User Contributed Perl Documentation PERL(1)


NAME
perl - Practical Extraction and Report Language
^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Even http://perldoc.perl.org/perl.html says:
"perl - Practical Extraction and Report Language"

 

[Andrew DeFaria]

While on UseNet you generally do not post HTML,

No, when on Usenet *you* generally do not post HTML. I do.

since you have pointed out there is plain-text version, Did I? Or did you mean John?
should not a sensible news reader use only that part if all you want
is plain-text, just as any sensible mail
reader does? This is how mine behaves. Surely what ever reader you
have could do the same?

Indeed. This is, last time I checked, 2008. Surely software can be smart
enough to tell the difference. Ya know once on SuSE Linux I typed "more
file.html". More rendered the html file and put out a little note that
stated if I wanted to see the raw file to type "more file.html:". Gee
imagine that. Plain old more (probably less as I have long since aliased
more=less) taught a new trick to render html. In 2004 no less!

The post has plain text part first and HTML part second. After seeing
the plain text and coming upon HTML in your plain text, psychedelic
60's, ASCII only news reading software, why, praytell didn't you simply
skip to the next message? And don't complain to me that it's ugly! I
mean it you who is using a ASCII only news reader. Surely you are used
to ugly by now!

With that said, it would be nice to keep everything in plain-text
only, though in this day and age, I don't think it should be so
surprising to see messages in multiple formats?

And I would not think it's so abnormal to acquire decent software that
can handle such things as HTML. It's only been what? Some 15 years now...

Then again we are arguing with pinheads who like to argue about the
cosmic significance between "perl" and "Perl"... :-(

 

[Andrew DeFaria]

Actually, yes. Because any perldoc or man I've tested on 8 different
types of platforms all display it the same way and this is how people
would read it. Even man2html shows "PERL (1)" at the top.

Although, it's not so much the header formatting (maybe I should not
of underscored on the header), it's the fact that (which you
conveniently snipped: ),

$ perldoc perl | head -n 10
PERL(1) User Contributed Perl Documentation PERL(1)

NAME
perl - Practical Extraction and Report Language
^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

"Practical Extraction and Report Language" implies an acronym in some
way or another, and so you cannot really blame someone for using
"perl" or "PERL" as both forms could be used to denote an acronym.
Since this is in the main Documentation for Perl, then it is fair
game, unless you no longer consider Perl's own documentation to be of
value.

No he didn't conveniently snipped rather he deliberately snipped it
because such facts are inconvenient to his argument... which, I might
add, doesn't hold water....

 

[jm]

Uri Guttman a écrit :

j> perl provides good things and bad ones.
j> In the good thing, such as:
j> * it is adapted for text processing
j> * it is poorly typed

me thinks you don't understand typing well. perl actually has stronger
typing than many langs. it just types on the variable type (scalar vs
array vs hash) instead of the data type.

When passing a parameter to a function, in Perl, I do not know any way
to say that the type of the parameter is a hash table which associate
strings to integer, for example.

When in a language such as java (or Java) you can say it is a
HashMap<String, Integer>

In Perl, I know a $ parameter is a scalar, a %, a hash, a @, a table,
and; optionals.

For the rest, I believe type is not checked at function call, but at
data use.

j> * it is enough powerful with unicode
j> * provide arrays and hash and reference (and objects)
j> * transparently manage any kind of numbers.
j> * is C interfacable
j> * has basic network and IPC possibilities

basic??? cpan has modules for almost every protocol out there and IPC
support is all done too. you don't know perl well if you say this is basic.

I used basic to mean low level.

It is clear than when you have enough good low-level functions, you can
use them to provide higher level functions (such as those protocols)

j> * pack/unpack

that is a major part of perl? it is used but not that often by most
coders.

It is one practical way to access binary data.

And binary is not so uncommon.

j> In the bad things, such as:
j> * bytes/unicode confusion
j> * stack overflow within bad regular expression

huh?? then don't write bad regexes. most likely if it blows up in perl
it will do worse in other langs.

I have yet read that Perl regexs are best than every other ones.

What I mean here is there is no way (I know) to check a coder did not
write bad regexes.

When Perl 5 encourages use of regexs,

But I need to read some Perl 6 rules documentation.

j> * memory consumption (might be an issue when energy will be more expensive?)

what?? you are smoking very strange stuff. ram is cheap and always
getting cheaper. cpu speed is the power hog.

According to some web sites (1),
1 Gbytes memory might "smoke" 60 watts, when
Pentium 4 3.2 Ghz version E might "smoke" 75 watts.

But I do not know if those figures are good.

Also, I read that in developed countries, data center energy consumption
is greater than 1% of (electrical?) energy. When energy is not less
and less expensive (2).

I do not know this subject, so you might be right, waste of energy might
be not related to memory.

j> * insufficient typing

again, you don't know what you are talking about.

I explained the way I consider this upper.

j> * some portability issue, notably with function «system».

proof of the last comment. system is the way to call external
programs. how could that POSSIBLY BE PORTABLE if the external programs
vary from box to box?

I assume that what you call the external program is the shell.

In my opinion, call to external programs should be done based on one of
the two following ideas:

idea 1/ A function which provides pipes for stdin, stdout, stderr and
(if possible) portable access to exit values.

idea 2/ Some minishell embedded within Perl, in order to interpret pipes
and redirections from to files.

I prefer idea 1 to idea 2.

j> * some $@% issues.

no, you have some issues.

Yes this is the point.

In Perl 5, some coders might be confused by sigils ($@%).

It seams I have read they will be modified in Perl 6 to improve this issue.

j> * pack limitation: cannot just modify one byte.

huh??? pack doesn't modify anything. pack converts a list of values to a
single buffer string. and the C format can pack a single byte.

Yes, thats what pack/unpack does.

In C, some coders access binary data with struct/union.
I do not like this because it is not portable.

I do not like the way Java access binary data, because bytes are signed.

At first, the pack/unpack looks pleasant to me, an elegant way, based on
a format string to separate low level bytes from upper level data.

But one day, I just wanted to modify just one single byte.

j> perl6 looks like a cleanup of perl, but I am wondering:

j> how will memory be handled in perl6?

just find with true gc.

Does this mean an effort will be done to reduce memory consumption?

j> how will bytes be handled in perl6?

with stone tablets.

What a pity. This mean it will be not improved.

j> why perl6 encourages complex regex (as x become standard)?

wtf are you babbling about? perl6 has grammars and rules which blow away
all current regex engines. you need to read up on them. in fact you can
use a bunch of it in perl5 now with cpan modules.

I did not yet understand how works rules in Perl 6.

Might be it gives a way to simplify the following expression from perlfaq6:

s{
/\* ## Start of /* ... */ comment
[^*]*\*+ ## Non-* followed by 1-or-more *’s
(
[^/*][^*]*\*+
)* ## 0-or-more things which don’t start with /
## but do end with ’*’
/ ## End of /* ... */ comment

| ## OR various things which aren’t comments:

(
" ## Start of " ... " string
(
\\. ## Escaped char
| ## OR
[^"\\] ## Non "\
)*
" ## End of " ... " string

| ## OR

’ ## Start of ’ ... ’ string
(
\\. ## Escaped char
| ## OR
[^’\\] ## Non ’\
)*
’ ## End of ’ ... ’ string

| ## OR

. ## Anything other char
[^/"’\\]* ## Chars which doesn’t start a comment,
string or escape
)
}{defined $2 ? $2 : ""}gxse;

j> how will perl6 address portability issues?

what issues?

There was so much portability issues in Perl 5 than the first question
is probably bad.

j> how will perl6 address IPC issues?

again, what issues? there are no IPC issues, other than your
delusions. perl has fine IPC.

A function which provides pipes for stdin, stdout, stderr and (if
possible) portable access to exit values.

When I tried to do IPC, what I was missing was a function similar to
system, but which
allow managing every pipes (stdin, stdout, stderr) and any kind of
return vale (exit code, signal).
I did not find this in perlfunc.

uri

1/
http://www.ginjfo.com/Publics/Actua...on-de-la-consommation-electrique-d-un-PC.html

2/
«dans les pays développés, la consommation énergétique des data centers
dépasse largement 1% de la consommation globale.
Or, la tendance n'est pas franchement à la baisse du coût de l'énergie.»
http://www.guideinformatique.com/fiche-consommation_electrique_des_data_centers-846.htm

 

[Gordon Etly]

No, when on Usenet *you* generally do not post HTML. I do.

Did I? Or did you mean John?

I think you misunderstood me. I was just pointing out that your posts
are multipart messages (a section for "Content-Type: text/plain;" and
another for "Content-Type: text/html;") and that people who wish to read
only in plain-text should be seeing just the plain-text section, if the
reader works in such a sensible way. Those who do not mind html will
likely view that part. This was all I meant. And this is why I don't
feel it should be a much of a problem as some people make it out to be.

What part one sees by default should be as par one's preferences.

 

[Andrew DeFaria]

On Sun, 06 Apr 2008 14:12:56 -0700, Andrew DeFaria

David Formosa (aka ? the Platypus) wrote: [...]

Indeed! It shows that I have a lot more taste than to admire ASCII
"art". That's for geeks who have never quite graduated from DOS
And the IETF.

Or was never really a part of, as the case probably is... In any
case, ASCII "art", as the kind referred to here, is decidedly
inferior to all other arts. Besides I have no requirement to admire
or respect it.

So you have no respect for RFC793?

Is that the RFC that requires all people to respect ASCII "art"? If not
then please explain. AFAICT this RFC is for TCP. How does TCP and ASCII
art relate?

 

[Gordon Etly]

David Formosa (aka ? the Platypus) wrote:
[...]

Because reading the FAQ, paying attention to detail and
understanding what people tell them are aspects of knowing how to
program in Perl.

No, you can judge someone purely on grounds like that.

And we don't. We also judge people on how they respond to being
corrected.

Well, given 'perldoc perl'/'man perl', stating near the top,
"perl - Practical Extraction and Report Language",
it is perfectly valid to use "perl" or "PERL", as that abbreviates the
above.

So the attempting to "correct" someone for using "perl" or "PERL"
contradicts Perl's own documentation. The "regulars" are always saying
to read perldoc, amongst other things, yet conveniently forget about the
main document.

Since it's in Perl's own docs, using the acronym of, or in full,
"Practical Extraction and Report Language" is fair game.

[...]

Yes, but "PERL" and "Practical Extraction and Report Language" come
fro mthe man/perldoc page for "perl", how can one get more official
then something's own man page?

The all cap sequence is a side effect of man.

Are you saying the FAQ for this group, a user
contributed document, as valvuable as it may be, carries more weight
then Perl's own man page?

man perlfaq

They carry the same waight as perl's own man page because perl's man
page incorperates the FAQ for this group.

That may be, but how does that change the fact that the main document,
'perdoc perl'/'man perl', completely contradicts those attempting to
impose such corrections on people who use "perl" or "PERL"?

 

[Gordon Etly]

Another (better?) citation: http://tinyurl.com/o6ll4

Perhaps.

"Randal Schwartz capitalised the language's name to
make it stand out better when typeset. This convention
was adopted by the community"

Ok.

"You may or may not choose to follow this usage"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Alright.

"But never write "PERL", because perl is not an acronym,
apocryphal folklore and post-facto expansions
notwithstanding."

This last quote is contradicted by the main Perl document, that gives
the "NAME" of the language as:

"perl - Practical Extraction and Report Language"

Which IS an acronym. Or at the very least allows one to write "perl" or
"PERL" to abbreviate that. Again, you just cannot ignore the main
document.

 

[Uri Guttman]

j> Uri Guttman a écrit :j> perl provides good things and bad ones.
j> In the good thing, such as:
j> * it is adapted for text processing
j> * it is poorly typed
j> When passing a parameter to a function, in Perl, I do not know any way
j> to say that the type of the parameter is a hash table which associate
j> strings to integer, for example.

why do you need such a beast? you name the variable according to its
use. if you use it incorrectly, that then is your fault. that sort of
typing is anal to an extreme. what if there is no class type for the
hash you want? what if different members of the hash have different
value types (as in a structure)? you can't prename hash types for all
possible types so why even bother?

j> When in a language such as java (or Java) you can say it is a
j> HashMap<String, Integer>

useless information as it should be in the variable name.

j> In Perl, I know a $ parameter is a scalar, a %, a hash, a @, a table,
j> and; optionals.

those are prototypes and you have it wrong. besides, prototypes in perl
are not a good thing and no experienced hacker uses them.

j> For the rest, I believe type is not checked at function call, but at
j> data use.

correct. and that is stronger than compile time checking as you can fake
out compile time with all sorts of tricks in most langs.

j> * it is enough powerful with unicode
j> * provide arrays and hash and reference (and objects)
j> * transparently manage any kind of numbers.
j> * is C interfacable
j> * has basic network and IPC possibilities
j> I used basic to mean low level.

and what high level IPC do you mean and what is missing? you don't know
IPC if you claim that about perl.

j> It is clear than when you have enough good low-level functions, you can
j> use them to provide higher level functions (such as those protocols)

j> * pack/unpack
j> It is one practical way to access binary data.

j> And binary is not so uncommon.

it isn't used in most perl programs. as someone who is a professional
perl code reviewer i don't see pack nor binary used in perl nearly as
much as text. that isn't to say pack/binary aren't important but it
isn't a major part of perl as such. and even for many binary things,
there are modules that handle it for you. cpan is your friend.


j> In the bad things, such as:
j> * bytes/unicode confusion
j> * stack overflow within bad regular expression
j> I have yet read that Perl regexs are best than every other ones.

huh? ever heard the expression 'perl compatible regular expressions'?
every other language claims that (check out 'pcre' and you will
see). they all want to have perl's regexes. and none of them really do.


j> * memory consumption (might be an issue when energy will be more expensive?)

j> According to some web sites (1),
j> 1 Gbytes memory might "smoke" 60 watts, when
j> Pentium 4 3.2 Ghz version E might "smoke" 75 watts.

this makes no sense. the whole motherboard 'smokes' even more. disk
drives smoke the most. where did you learn how to smoke?

j> I do not know this subject, so you might be right, waste of energy might
j> be not related to memory.

that is ram in the cpu, not ram used in the program. they are different
beasts.


j> * some portability issue, notably with function «system».
j> I assume that what you call the external program is the shell.

no, you can call directly to any external program bypassing the
shell. learn more about qx, system and exec from the docs.

j> In my opinion, call to external programs should be done based on one of
j> the two following ideas:

j> idea 1/ A function which provides pipes for stdin, stdout, stderr and
j> (if possible) portable access to exit values.

and perl has those in IPC::Run and many other modules. hmm, IPC modules!

j> idea 2/ Some minishell embedded within Perl, in order to interpret pipes
j> and redirections from to files.

huh??? perl doesn't need pipes internally as you don't have processes
inside perl. you need to learn more about this.


j> * some $@% issues.
j> Yes this is the point.

j> In Perl 5, some coders might be confused by sigils ($@%).

maybe you but most seem to learn it just fine.

j> * pack limitation: cannot just modify one byte.
j> Yes, thats what pack/unpack does.

but your statement about modifying one byte made no sense. i sense a
pattern here.

j> In C, some coders access binary data with struct/union.
j> I do not like this because it is not portable.

huh?? you can make c structs portable. the issues are more with
endianess.

j> At first, the pack/unpack looks pleasant to me, an elegant way, based on
j> a format string to separate low level bytes from upper level data.

j> But one day, I just wanted to modify just one single byte.

and you couldn't? why? show your code.

j> perl6 looks like a cleanup of perl, but I am wondering:
j> Does this mean an effort will be done to reduce memory consumption?

that doesn't compute. ram usage and gc are not related.

j> how will bytes be handled in perl6?
j> What a pity. This mean it will be not improved.

perl6 has very sharp chisels!

j> why perl6 encourages complex regex (as x become standard)?
j> I did not yet understand how works rules in Perl 6.

so don't denigrate them. you seem to have a habit of bitching about
stuff which you don't understand well.

j> Might be it gives a way to simplify the following expression from perlfaq6:

sure it does. but i won't translate it. this regex is an example just to
show how something CAN be done. and it is a very tricky problem
involving c style comments and strings. perl6 rules will be able to
parse nested complex stuff in a very high level way with libraries
(called grammars) of reusable rules.


j> how will perl6 address IPC issues?
j> A function which provides pipes for stdin, stdout, stderr and (if
j> possible) portable access to exit values.

you don't understand IPC at all it seems. perl5 has full access (both
high and low level) to all IPC features. you just don't see them.

uri

 

[Tad J McClellan]

man perlfaq

They carry the same waight as perl's own man page because perl's man
page incorperates the FAQ for this group.

There is no FAQ for this newsgroup.

There is a FAQ for Perl, that ships with perl (but not with PERL).

So there is a FAQ for the topic of this newsgroup rather than
a FAQ for this newsgroup.

 

[Tad J McClellan]

While on UseNet you generally do not post HTML, since you have pointed
out there is plain-text version, should not a sensible news reader use
only that part if all you want is plain-text, just as any sensible mail
reader does? This is how mine behaves. Surely what ever reader you have
could do the same?

With that said, it would be nice to keep everything in plain-text only,
though in this day and age, I don't think it should be so surprising to
see messages in multiple formats?

I find HTML attachments on Usenet postings to be useful to me.

 

[Uri Guttman]

AD> Uri Guttman wrote:
j> When passing a parameter to a function, in Perl, I do not know any way
j> to say that the type of the parameter is a hash table which associate
j> strings to integer, for example.

AD> why do you need such a beast? you name the variable according
AD> to its use. if you use it incorrectly, that then is your
AD> fault.

AD> Ah... to cut down the the number of "well it's your fault" type
AD> errors. Humans make mistakes (like the constant mistake you keep
AD> making by not properly capitalizing letters).

mistake? i lost my caps lock key!! it is now control which is where it
should be.

j> When in a language such as java (or Java) you can say it is a
j> HashMap<String, Integer>

AD> useless information as it should be in the variable name.

AD> Just because you can't understand it does not mean it's useless.

huh?? i understand more code before 6am than you do in a year!

j> In Perl, I know a $ parameter is a scalar, a %, a hash, a @, a table,
j> and; optionals.

AD> those are prototypes and you have it wrong. besides,
AD> prototypes in perl are not a good thing and no experienced
AD> hacker uses them.

AD> Yes, script kiddies don't. Experienced professional programmers on
AD> the other hand...

huh? show me one serious perl hacker that uses and likes prototypes?
they have about one useful purpose (can you name it?). otherwise even
larry wall says they were a mistake. they aren't even prototypes as
other langs use the term.

j> For the rest, I believe type is not checked at function call, but at
j> data use.

AD> correct. and that is stronger than compile time checking as you can fake
AD> out compile time with all sorts of tricks in most langs.

AD> Yes so let's all rely on the weakest form of enforcement -
AD> convention of the names of variables...

you seem to be contrarian with no actual defense of your position. oh
well, off with your head!

uri