pdcawley <[EMAIL PROTECTED]> writes:
> Bugger, I used L and pod2text broke it.
> http:[EMAIL PROTECTED]/msg10797.html
perlpodspec sez you can't use L<...|...> with a URL, and I'm guessing that
I just didn't look at that case when writing the parsing code in po
e (a bit of) a
> pain. That problem doesn't exist with "!<" and "!>".
Every other programming language I've ever seen uses >= and <=. I think
adding additional comparison operators not found in any other language and
identical to (and harder to type than!) exis
Sterin, Ilya <[EMAIL PROTECTED]> writes:
>> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
>> How is !< different from >=?
> It's just more syntax just like foo != bar
> is the same as (foo > bar || foo < bar).
> It might prove convenient to expr
raptor <[EMAIL PROTECTED]> writes:
> I was looking at Interbase SELECT syntax and saw these two handy
> shortcuts :
> = {= | < | > | <= | >= | !< | !> | <> | !=}
> !< and !>
How is !< different from >=?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
t; For what it's worth, I like it.
So do I, actually... it's sort of growing on me.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
they're a lot
more unconventional.
You can still trace nearly everything that was proposed back to C, Lisp,
or Generic Object-Oriented Language, if not in inspiration than at least
in fundamental similarities.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ython are really almost entirely just attempting to make
practical ideas already explored in other practical and experimental
languages.
Perl is far more practical than experimental.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Simon Cozens <[EMAIL PROTECTED]> writes:
> Personally, I'd rather not deal with a toke.c that knows more of
> /usr/dict/words than I do.
use thesaurus;
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ters (in particular, something that
doesn't require explicit dereferencing), then using . to access object
members is entirely compatible with C.
I tried to make this point before, but I don't think people understood
what I was getting at.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> It seems relatively unlikely in the course of normal Perl that you're
>> going to end up with very many references to objects.
> Well, right now in Perl, an object *is* a reference.
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> The switch from -> to . makes perfect sense from a C perspective if we're
>> turning objects into first-class entities rather than pointers; think
>> about a struct versus a p
C perspective if we're
turning objects into first-class entities rather than pointers; think
about a struct versus a pointer to a struct.
-> makes you remember that things are pointers.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
uper-long lines? Going to the shell syntax of:
PATH=/some/long:/bunch/of:/stuff
PATH="${PATH}:/more/stuff"
would really be a shame.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
t so bad. People just kept
> their p4 binaries around for running those old scripts. No biggie.
There's quite a lot more Perl 5 code out there than there was Perl 4 code.
And it's rather annoying to still be maintaining a perl4 installation at
this point for the stragglers, althou
get a copy of
> all these little gems from? :)
<ftp://ftp.cpan.org/CPAN/misc/lwall-quotes.txt.gz>
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
't about what I
expected, so I didn't have much additional response, apart from saying
that that was rather more Perl 5 compatibility than I was expecting.
Interesting.
Oh, and I wholeheartedly approve of the approach to handling objects.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
John Porter <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> It looks like I was misremembering; I remember a proposal for a "pure"
>> attribute in gcc, but it looks like the attribute used for functions
>> with no memory references and no side effec
ces and no side effects is "const" (a la C++). I think
"pure" was proposed for the somewhat relaxed version of that that allowed
memory references but not side effects.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Doesn't have the right ring to it, unfortunately. It's not really
> immutable, it just has no side-effects.
gcc and the literature both use "pure"; I'd recommend that.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ute, is that such an
attribute will be fairly rarely used and that most of your gains will come
from managing to teach the compiler to figure out that information for
itself.
This will probably be harder in Perl than in C because C can afford to
take more time to do global optimization passes.
--
n* Yeah, that's the main thing that gets in the way
of optimizing C.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
so that Perl *can* usefully memoize, I can't think
of any realistic sort function where this would be a problem.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
tched or subs inside the sort sub are called" then life
> becomes much easier.
I am strongly in favor of that approach. I see no reason to allow for
weird side effects in Perl 6. (Perl 5 would be a different matter, of
course.)
Not only is it simpler to deal with, it's simpler
de. the supposed goal of this hypothetical builtin ST is to
> make it easier to use it. i say it is not worth the effort since you
> have to do almost as much work anyway.
Less mental effort is the important part, not how many characters have to
be typed. I don't want to be thinki
Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>>> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
> RA> Uri Guttman <[EMAIL PROTECTED]> writes:
> map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
>
see a few YAPHs
with such properties, but I don't think we were guaranteeing that Perl 6
would be YAPH-compatible anyway.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
nners in
> many case.
Without creating a function to extract the key, you can't sort in Perl at
all. sort { $a <=> $b } contains two functions to extract the keys.
Functions don't have to be complicated, you know.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
over-the-top whining that may have been intended to be funny and ended up
just being stupid and grating.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
So since when did perl6-language become perl-advocacy? Rephrased: Could
people please take the advocacy traffic elsewhere where it isn't noise?
Thanks.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
aspect of the Perl language; I use that sort
of construct all over the place. We don't want to turn Perl into C, where
if you want to return anything non-trivial without allocation you have to
pass in somewhere to put it.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ally good reason to learn Python.
> the TIL speedup over pure interpretation might win that back and
> more.
If that's true, that's a different ballgame of course.
If at all possible, Perl 6 should be *faster* than Perl 5. Perl is
already too slow IMO.
--
Russ Allb
I'm concerned, *any*
SGML-derived markup language is write-only and usable only as an output
format. It's slightly more readable than PostScript, and that's about all
I can say for it.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
that, or taking uuencode out of pack and putting it plus those
other things into a standard module.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
David Olbersen <[EMAIL PROTECTED]> writes:
>> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
>> Just out of curiosity, and I'm not objecting to this RFC, has anyone
>> reading this mailing list actually intentionally used a vertical tab
>> for something related
> in regular expressions.
Just out of curiosity, and I'm not objecting to this RFC, has anyone
reading this mailing list actually intentionally used a vertical tab for
something related to its supposed purpose in the past ten years?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
scenes), in a separate module that only
those programs that need to do UID fiddling need to load.
I guess the exception is getpwuid($<), which is probably done more than
any other operation on UIDs, but maybe just keep that single variable.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
don't find this a particularly important feature in a language. In those
cases where it is, I'd use a language other than Perl.
use English doesn't really address the syntactical points of Perl that
make it hard to read for someone who doesn't know Perl; it strikes me, and
ugh the program trying to find where they're defined
for a while before realizing they're weird use English things.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
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
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]) <http://www.eyrie.org/~eagle/>
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> Perhaps I don't use those warnings in the same way that you do. I
>> *very* rarely have undefined value warnings in my programs, and when I
>> do they're usually not actually bugs, just t
> Having Perl tell me 'this is perl5.7.0\n> ' or similar would have been
> nice. But that's just me.
As long as it's possible to get the current "perl" behavior; I actually
use that a lot.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
't actually know what type of Perl I
write or whether or not I'd use the semantics or not. As a matter of
fact, I find them very interesting and fully do expect to use those
semantics if they're implemented in Perl, particularly given that I'm
likely to be doing a lot more da
NULL semantics to undef would be bad. The
> counterproposals to RFC 263, along the lines of "use tristate", seem to
> overlook this sort of situation.
I'm not overlooking it; I just don't agree with you. There *is* a
difference.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
typing and reads more clearly (to me, at least).
Hm, yeah, good point.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
uot;==" operator returns
> only 1 or "". Both are defined.
But if you say:
use tristate;
then $a == 42 returns undef if $a is undef. Most Perl programs may not
want these semantics, but they're often useful, and for more things than
just databases. Think error propagation.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
lled
"null" behave differently in Perl, *that* would be a serious bug in my
opinion. Talk about horribly confusing.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
is in real code?
I don't believe you actually need both semantics active at the same time;
it might take really minor rewording of the code (initialize to 0 instead
of undef for counters, etc.), but I'm very unconvinced that you need both
concepts active at the same time.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
eat idea, but I don't expect to see it ever widely used.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
g languages, something used by the
majority of Perl scripts that I write, and something that's very
intuitive. undef semantics, on the other hand, are specific to Perl and
the default is chosen to be friendly to quick and dirty scripts. Changing
those semantics to propagate undef makes perfect sense to me.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> I agree with Tom; I think it's pretty self-evident that they're the
>> same thing. undef means exactly the same thing as null; that's not the
>> problem. The problem is that Per
realized its futility.]
I agree with Tom; I think it's pretty self-evident that they're the same
thing. undef means exactly the same thing as null; that's not the
problem. The problem is that Perl doesn't implement the tri-state logic
semantics that most users of null are used
here are the curlies.
Removing the *one* @ in that expression isn't going to make it look any
simpler.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
;ll agree with; I find the @{ $$hash{value} } syntax rather
bletcherous. But I think that's a separate problem and could well have a
separate solution.
Perhaps @->$$hash{value} as has been proposed before, and Perl 6 can deal
with the issue of the @- array in some other way.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
John Porter <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> $args = 'first second third';
>> @args = split (' ', $args);
>> my $i = 0;
>> %args = map { $_ => ++$i } @args;
>> This is very Perlish to me; the
ave to guarantee a sorted traversal of the hash keys, your choices
of data structures are *far* more limited.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
t it the order in which the members show up may be different (maybe
garbage collection happened behind the scenes, the hash was reorganized
due to an observation of how you were using it, etc.).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
rrected back by xntpd or something, but
in practice time on a Unix clock is monotonic.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
nfusing. Please let's not
mandate programming style. Often times the difference between the
variables changes some as the program proceeds, but context makes it quite
clear what's going on.
This strikes me as the same sort of meaningless style guideline as "all
variables must have names that are at least five characters long."
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
oduce arrays that don't start
with @, that's the mistake.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
#x27;first second third';
@args = split (' ', $args);
my $i = 0;
%args = map { $_ => ++$i } @args;
This is very Perlish to me; the punctuation is part of the variable name
and disambiguates nicely. I'd be very upset if this idiom went away.
--
Russ Allbe
Tim Jenness <[EMAIL PROTECTED]> writes:
> On 14 Aug 2000, Russ Allbery wrote:
>> Day resolution is insufficient for most purposes in all the Perl
>> scripts I've worked on. I practically never need sub-second precision;
>> I almost always need precision be
ugh a different interface to
return something like TAI64NA or something, that would make sense to me.
What doesn't make sense to me is a change of epoch; I just don't see what
would be gained.
I must be very confused. I don't understand what we gain from MJD dates
at all, and
ething that works?
Is Perl currently using different epochs on different platforms? If so, I
can definitely see the wisdom in doing something about *that* and
off-loading the system-local time processing into modules (although I can
also see the wisdom in leaving well enough alone). But why n
represent times before 1970
just fine. The range problem is easily solved by making it a 64-bit
value, something that apparently we'd need to do with an MJD-based time
anyway. And everyone already knows how it works and often relies on the
base being consistent with their other applicatio
skud <[EMAIL PROTECTED]> writes:
> I don't think this is a language issue. However, I don't believe
> there's a -doc working group yet, either.
> Is it time for a -doc group to form?
[EMAIL PROTECTED] already exists; maybe it should be blessed as a Perl 6
wo
based on TAI with corrections for UT1).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
onds, making it rather incompatible with
computers.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
> s/gmt/ut/
> IIRC GMT got obsoleted in the 70s by UT (Universal Time).
Officially called UTC, so utcdate would be a better name I think.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ctually isn't one.
You can require that it be passed as a string, but writing something like
the above would be a *very* common new user mistake.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
; people in Newfoundland are going to expect to be
able to pass in -0230 and have that work, and that's interestingly hard.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
operating system. If you call localtime
in C, you should get back local time, whatever the local time zone. The
whole point is to not try to duplicate that information in Perl core.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
John Tobey <[EMAIL PROTECTED]> writes:
> On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:
>> It's far worse than non-portable; it's completely insufficient. The
>> POSIX TZ syntax cannot represent many real time zones. You need the
>> Olso
these problems would be a Herculean task which I simply
> doubt that anyone here is willing to do. Therefore, I oppose the
> notion that Perl 6 will magically handle all this.
> -John
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
; replace "if" with "unless" and it
> chops the head off.
Why do you need one-time matching here? /^$/ should work fine.
I've very rarely found cases where ?? was useful and // didn't work, and
never in regular code.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
llow a timezone offset; this
doesn't deal with daylight savings time and historic time zone changes,
but it provides enough power for most of what people want to do and if you
want to deal with the rest you have to deal with time zone naming.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
quently used.
I do agree that there's a lot to be said for using /* ... */ for multiline
comments, but then I'm a C programmer.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
;s being done here is in other languages often
called shadowing. What about C?
shadow $/ = "\n";
seems to have the right implications to me.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
eceive them unless I care a lot about that particular topic.
Instead, what about a temporary freeze when each list is created? Give it
a day or two after it's created before it will accept traffic; have the
traffic be held for that long while people subscribe. Would that help
this problem?
--
Rus
s.
cpp, on the other hand, has very few active constructs or characters, just
identifiers, function calls, and # at the beginning of a line. It still
causes a few problems where it recognizes something it shouldn't, but it's
trivial to deal with compared to m4.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Myers, Dirk <[EMAIL PROTECTED]> writes:
> If a remove() is added, it should (IMHO) seek-and-destroy.
This is impossible on a Unix file system.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
default
quoting characters would interact very poorly with Perl.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
82 matches
Mail list logo
