Could someone summarize the arguments for such an operator? Doing so, to
me, seems to subtrack from the scripting domain something which belongs
there. Teaching the transform in classes is a wonderful way to both
illustrate the power of Perl's map, and more importantly, help programmers
understand
> > The normalization has something to do with encoding. If you compare two
> > strings with the same encoding, of course you don't have to care about
it.
>
> Of course you do. Think about it.
I said "you don't have to". You can use "==" for codepoint comparison, and
something like "Normalizer.co
> this would have to be a proper module and not a builtin op. there is no
> reason to make this built in.
This was essentially my point with regards to naming this op
"map_sort_map". Just explaining the function of the op negates its
usefulness *as* an op, because of the complexity of extracting
Zenon Zabinski wrote:
> Personally, I have never used the Schwartzian Transform ...
> so I may not be fully knowledgeable of its usefulness.
>
> do you need to understand the
> intricacies if you can just cut and paste and just change a few
> variables?
Not to be harsh, but you probably *do*
Here is some of my experience with HotSpot for Linux port.
> I've read, in the glibc info manuals, the the similar situation
> exists in C programming -- you don't want to do a lot inside the
> signal handler; just set a flag and return, then check that flag from
> your main loop, and run a "
> "Hong" == Hong Zhang <[EMAIL PROTECTED]> writes:
>> What if, at the C level, you had a signal handler that sets or
>> increments a flag or counter, stuffs a struct with information about
>> the signal's context, then pushes (by "push", I mean "(cons v ls)",
>> not "(append!
> "Dan" == Dan Brian <[EMAIL PROTECTED]> writes:
Dan> IMO the very quest for a name would be reason enough to not do it.
Dan> "map_sort_map"? That begs the question. And since Randal asks that it not
Dan> be named after him ... (I heard he filed a trademark on Schwartzian, so
Dan> that's out.
At Thu, 22 Mar 2001 13:37:29 -0800,
John Harper wrote:
>
> |> I've looked, a little, (and months ago at that) at the LibREP (ala
> |> "sawfish") virtual machine. It's a pretty good indirect threaded VM
> |> that uses techniques pioneered by Forth engines. It utilizes the GCC
> |> ability to
Brent Dax wrote:
>
> Someone else showed a very ugly syntax with an anonymous
> hash, and I was out to prove there was a prettier way to do it.
Do we want prettier? Or do we want more useful?
Perl is not exactly known for its pretty syntax.
--
John Porter
>> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes:
> Brent> @s = schwartzian(
> Please, if we're going to add an operator, let's not call it schwartzian!
> I have enough trouble already telling people how to spell my name. :)
Which is why my real suggestion was a 'tsort' ('tsort' eq 'tr
> 6) There will be a glyph boundary/non-glyph boundary pair of regex
> characters to match the word/non-word boundary ones we already have.
(While
> I'd personally like \g and \G, that won't work as \G is already taken)
>
> I also realize that the decomposition flag on regexes would mean that
> s/
> >> What if, at the C level, you had a signal handler that sets or
> >> increments a flag or counter, stuffs a struct with information
about
> >> the signal's context, then pushes (by "push", I mean "(cons v ls)",
> >> not "(append! ls v)" 'whatever ;-) that struct on a stack...
>
> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes:
Brent> @s = schwartzian(
Please, if we're going to add an operator, let's not call it schwartzian!
I have enough trouble already telling people how to spell my name. :)
Maybe I should have a kid named "Ian", so I can see on a roster some
At 11:14 AM 03-22-2001 -0800, Hong Zhang wrote:
>Please not fight on wording. For most encodings I know of, the concept of
>normalization does not even exist. What is your definition of normalization?
To me, the usual definition of "normalization' is conversion of something
into a standard form
I've not researched this at all... perhaps it's a "known" way of
doing things and there is research writing out there already, etc...
I've not even looked at this point. I have about 30 minutes to
outline this and bounce it off of you all this morning. 8-)
I was reading Lincoln D. Stein's
On Thu, Mar 22, 2001 at 11:14:53AM -0800, Hong Zhang wrote:
> Please not fight on wording. For most encodings I know of, the concept of
> normalization does not even exist.
*boggle*. I don't think we're talking about the same Unicode.
> What is your definition of normalization?
Well, either ca
On Thu, Mar 22, 2001 at 04:10:28PM -0500, Dan Sugalski wrote:
> 1) All Unicode data perl does regular expressions against will be in
> Normalization Form C, except for...
> 2) Regexes tagged to run against a decomposed form will instead be run
> against data in Normalization Form D. (What the ta
Hong Zhang writes:
|> I've looked, a little, (and months ago at that) at the LibREP (ala
|> "sawfish") virtual machine. It's a pretty good indirect threaded VM
|> that uses techniques pioneered by Forth engines. It utilizes the GCC
|> ability to take the address of a label to build a jump ta
At the moment, I'm not particularly inclined to argue unicode. Short of
Larry handing down an edict and invoking Rule #1, the following rules will
be in effect:
1) All Unicode data perl does regular expressions against will be in
Normalization Form C, except for...
2) Regexes tagged to run aga
On Tue, Mar 06, 2001 at 01:21:20PM -0800, Hong Zhang wrote:
> The normalization has something to do with encoding. If you compare two
> strings with the same encoding, of course you don't have to care about it.
Of course you do. Think about it.
If I'm comparing "(Greek letter lower case alpha wi
> "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes:
RLS> sort { $a/$b expression } { transforming expression, glued with $_ } @list
RLS> so $a->[0] is guaranteed to be the original element, and the list-return
RLS> value of the second block becomes $a->[1]... $a->[$#$a].
RLS> S
21 matches
Mail list logo
