Thus it was written in the epistle of Larry Wall,
> Before we get too carried away discussing the syntax of chomp, let's
> look a bit at the semantics. What's chomp supposed to work on if we
> make $/ go away?
Right. But that's not yet decided :-).
> I think any discussion of chomp without considering
> how the input discipline finds line terminators is destined to be a
> partial solution.
As is the destruction of $/ withought considering chomp ;-).
I, for one, would like to know where the assumption came from that there would
be no default filehandle. Is it necessary that instead of typing
print 'Hello World.';
we need now type
$STDOUT->print('Hello World.');
Is that not going the wrong direction? If, on the other hand, there *is* a
default filehandle, then would it not be reasonable for chomp to use the $/
thingy associated with it? Or, as Uri (I believe) suggests, why not have a
global $/ which is the default for all filehandles and which chomp uses
except on those cases where it is called as chomp(<$filehandle>) or
chomp($_ = <$filehandle>)?
> On the other end, we're constrained to be able to translate current
> uses of chop and chomp to something that will work in Perl 6, so we
> can't just throw them out and say the input disciplines will do it all.
> Even if chop and chomp are not longer the preferred way of doing it,
> we'll still have to emulate the functionality somehow.
chop() does not, I believe, either suffer from the $/ problem or stand as an
obvious candidate to join in this proposal. After all, there *are* uses for
the return value of chop() as it stands.
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
==========================================================
God is a child; and when he began to play, he cultivated mathematics. It is
the most godly of man's games.
-- Erath, V.
==========================================================
Deep thoughts to be found at http://www.southern.edu/~ashted
