> Uh, have you followed this thread? It's nothing but another perlbashing
> session by a verbosity monger who can't handle $.
Well, you can bash him back in perl6, or continue the conversation on
advocacy. Up to you.
> Excuse me, but why would you send a perlbasher to the perl advocacy
> list. I
> OK, before this *completely* heads into the direction of advocacy,
which
> it's dangerous close to anyway, you need to qualify that.
Uh, have you followed this thread? It's nothing but another perlbashing
session by a verbosity monger who can't handle $.
Simon Cozens wrote:
> On Mon, Mar 26, 2001 at 04:36:35PM -0500, Uri Guttman wrote:
>
>> SC> Do you see any ESP there? Do you see any parsing of arbitrary
>> SC> pieces of code? No, me neither.
>>
>> and even creating a function to extract the key is not for beginners in
>> many case. most o
I think Simon meant '[EMAIL PROTECTED]', but isn't interested enough to
correct himself. :)
Dan Sugalski writes:
: I'm not sure that raw's the right word, given that the data is really
: Unicode. It's not raw in the sense that a JPEG image or executable is raw data.
I'm suggesting it might be raw in that very sense, and simultaneously
be perfectly valid "internal" Unicode. Otherwise y
On Tue, Mar 27, 2001 at 11:33:18PM +0200, Otto Wyss wrote:
> Could you imaging being the leader of a 10 people project where
> everybody design and codes in their own unique manner?
No, which is why in *those* situations, you have house rules. I don't
think Perl stops you doing that. It just does
At 11:06 AM 3/27/2001 -0800, Larry Wall wrote:
>Dan Sugalski writes:
>: At 07:21 AM 3/27/2001 -0800, Larry Wall wrote:
>: >Dan Sugalski writes:
>: >Assume that in practice most of the normalization will be done by the
>: >input disciplines. Then we might have a pragma that says to try to
>: >enfo
At 01:09 PM 3/27/2001 -0800, Hong Zhang wrote:
> > The only problem with that is it means we'll be potentially altering the
> > data as it comes in, which leads back to the problem of input and output
> > files not matching for simple filter programs. (Plus it means we spend CPU
> > cycles alterin
> Please CC Otto in all replies concerning this topic. I want to make sure he
> reads how wrong he is about Perl and its readability and I think Simon sums it
> up perfectly here.
>
Thank you very much for the CC and including Simon's message at the end.
> I also want to add that all of those s
> The only problem with that is it means we'll be potentially altering the
> data as it comes in, which leads back to the problem of input and output
> files not matching for simple filter programs. (Plus it means we spend CPU
> cycles altering data that we might not actually need to)
>
I don't t
please ignore my previous message. i think that my mind was trapped in an
alternate dimension :)
peter
Peter Buckingham wrote:
>
> James Mastros wrote:
> >
> [..]
> >
> > f("+123,456")=123456
> > f(f("+123,456))=123456
> >
> > The functon is not idempotent. Even if you checked f(x)==x (functio
James Mastros wrote:
>
[..]
>
> f("+123,456")=123456
> f(f("+123,456))=123456
>
> The functon is not idempotent. Even if you checked f(x)==x (function is the
> identity), an input of "123456" would work.
just a comment on this, we are talking about sorting which would generally
mean that the
Dan Sugalski writes:
: At 07:21 AM 3/27/2001 -0800, Larry Wall wrote:
: >Dan Sugalski writes:
: >Assume that in practice most of the normalization will be done by the
: >input disciplines. Then we might have a pragma that says to try to
: >enforce level 1, level 2, level 3 if your data doesn't ma
John Porter wrote:
> And I don't like the name ":constant", it smacks too much
> of OO. I'd hope we would come up with a better name.
:function ? :pure ?
--
John Porter
Peter Buckingham wrote:
> but the obvious question is if
> it isn't an idempotent function what do we do? do we abort? perhaps the real
> question is not whether we can require idempotency but what are we trying to
> achieve with it --- there may be another way :)
It is easy enough to test if the
On Tue, Mar 27, 2001 at 09:26:15AM -0800, Peter Buckingham wrote:
> I x A = I x A x A
> A = A^2
Problem with this: A isn't a matrix, nor is it even a vector (in the big
sense, not the pointy-arrow). It isn't that simple. Also, idempotent in
the CS world is diferent then in the algebe
On Tue, Mar 27, 2001 at 12:38:23PM -0500, Dan Sugalski wrote:
> I'm afraid this isn't what I'd normally think of--ord to me returns the
> integer value of the first code point in the string. That does mean that A
> is different for ASCII and EBCDIC, but that's just One Of Those Things.
My perso
> >could you not try a simple test (not guaranteed to be 100% accurate
> >though),
> >by copying the first data element and apply it twice and then check to see
> >that the result of applying it once is the same as applying it twice.
>
> Feels a little too magic to me, and awfully fragile. I'm n
At 09:26 AM 3/27/2001 -0800, Peter Buckingham wrote:
>Dan Sugalski wrote:
> >
> > At 09:50 PM 3/26/2001 -0500, James Mastros wrote:
>
>[..]
>
> > >I'd think /perl/ should complain if your comparison function isn't
> > >idempotent (if warnings on, of course). If nothing else, it's probably an
> >
At 08:37 PM 3/26/2001 +, [EMAIL PROTECTED] wrote:
>Damien Neil <[EMAIL PROTECTED]> writes:
> >> >So $c = chr(ord($c)) could change $c? That seems odd.
> >>
> >> It changes its _representation_ (e.g. from 0x45,ASCII to 0xC1,EBCDIC)
> >> but not its "fundamental" 'LATIN CAPITAL LETTER A'-ness.
Dan Sugalski wrote:
>
> At 09:50 PM 3/26/2001 -0500, James Mastros wrote:
[..]
> >I'd think /perl/ should complain if your comparison function isn't
> >idempotent (if warnings on, of course). If nothing else, it's probably an
> >indicator that you should be using that schwartz thang.
>
> If y
At 07:21 AM 3/27/2001 -0800, Larry Wall wrote:
>Dan Sugalski writes:
>: Fair enough. I think there are some cases where there's a base/combining
>: pair of codepoints that don't map to a single combined-character code
>: point. Not matching on a glyph boundary could make things really odd, but
>:
At 06:09 PM 3/27/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > >I'm happy think that we're using a special extractor rather than pod -
> > >cf embed.pl producing perlapi.pod. However, I'd rather a plain ^/*...^*/
> > >not be picked up.
> >
> > Same here. All the C c
At 10:30 AM 3/27/2001 +0100, Dave Mitchell wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 02:58 PM 3/26/2001 +0100, Dave Mitchell wrote:
> > >Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> > > > Perhaps we could teach pod that /* was alias for =pod
> > > > and */ an alias for =cut ?
> >
At 07:37 PM 3/26/2001 -0800, Russ Allbery wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > You're ignoring side-effects. The tied data may well be returned the
> > same every time it's accessed, but that doesn't mean that things aren't
> > happening behind the scenes. What if we were trackin
Garrett Goebel writes:
: Someone please clue me in. A pointer to an RFC which defines the use of
: colons in Perl6 among other things would help.
Heh. If you read the RFCs, you'll discover one of the basic rules of
language redesign: everybody wants the colon. And it never seems to
occur to peo
Dan Sugalski writes:
: Fair enough. I think there are some cases where there's a base/combining
: pair of codepoints that don't map to a single combined-character code
: point. Not matching on a glyph boundary could make things really odd, but
: I'd hate to have the checking code on by default,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 02:58 PM 3/26/2001 +0100, Dave Mitchell wrote:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> > > Perhaps we could teach pod that /* was alias for =pod
> > > and */ an alias for =cut ?
> >
> >or possibly
> >
> >/*=foo is an alias for =foo,
> >and */
Simon Cozens <[EMAIL PROTECTED]> writes:
>On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
>> SC> it? That is, @s = sort { f($a) <=> f($b) } @t
>>
>> because that would require the PSI::ESP module which isn't working
>> yet. how would perl intuit exactly the relationship between th
29 matches
Mail list logo
