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
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
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
> >> 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...
>
> "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!
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
> 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/
> 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
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
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 "
> "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
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
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
> "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.
> > 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
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
> "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
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*
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
21 matches
Mail list logo
