On Apr 14, 2004, at 11:16 AM, Larry Wall wrote:
I think the idea of tagging complete strings with "language" is not
terribly useful. If it's to be of much use at all, then it should
be generalized to a metaproperty system for applying any property to
any range of characters within a string, such
On Thu, 2004-04-15 at 23:13, Dan Sugalski wrote:
> Nah, that turns out not to be the case. It's my plan, and it's
> reasonable to say I'm OK with it. :) While I'd prefer to have
> everyone agree, I can live with it if people don't.
Perhaps, as usual, I've been too verbose and everyone just skip
At 11:55 PM +0200 4/15/04, Leopold Toetsch wrote:
Aaron Sherman <[EMAIL PROTECTED]> wrote:
On Thu, 2004-04-15 at 05:00, Leopold Toetsch wrote:
$dog eq "my dog Fi\x{fb03}"
and C<$dog> hasn't some language info attached?
Looks good to me. Great example!
Seriously, why is that a problem?
Dan's
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-04-15 at 05:00, Leopold Toetsch wrote:
>> $dog eq "my dog Fi\x{fb03}"
>>
>> and C<$dog> hasn't some language info attached?
> Looks good to me. Great example!
> Seriously, why is that a problem?
Dan's problem to come up with better exa
On Thu, 2004-04-15 at 05:00, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>
> > So, why is that:
>
> > "my dog Fiffi":language("blah") eq "my dog Fi\x{fb03}":langauge("blah")
>
> > and not
>
> > use language "blah";
> > "my dog Fiffi" eq "my dog Fi\x{fb03}"
>
>
On 14 Apr 2004, at 20:16, Larry Wall wrote:
I think the idea of tagging complete strings with "language" is not
terribly useful. If it's to be of much use at all, then it should
be generalized to a metaproperty system for applying any property to
any range of characters within a string, such that
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> So, why is that:
> "my dog Fiffi":language("blah") eq "my dog Fi\x{fb03}":langauge("blah")
> and not
> use language "blah";
> "my dog Fiffi" eq "my dog Fi\x{fb03}"
What, if this is:
$dog eq "my dog Fi\x{fb03}"
and C<$dog> h
On Tue, 2004-04-13 at 18:23, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > For example, in Perl5/Ponie:
>
> > @names=;
> > print "Phone Book: ", sort(@names), "\n";
>
> > In this example, I don't see why I would care that NAMES might be a
> > pseudo-handle
At 1:39 PM +0200 4/14/04, Michael Scott wrote:
On 13 Apr 2004, at 23:43, Dan Sugalski wrote:
I've been assuming it's a left-side wins, as you're tacking onto an
existing string, so you'd get English in all cases. Alternately you
could get an exception. The end result of a mixed-language
operati
On Wed, Apr 14, 2004 at 01:39:17PM +0200, Michael Scott wrote:
:
: On 13 Apr 2004, at 23:43, Dan Sugalski wrote:
:
: >I've been assuming it's a left-side wins, as you're tacking onto an
: >existing string, so you'd get English in all cases. Alternately you
: >could get an exception. The end res
On 13 Apr 2004, at 23:43, Dan Sugalski wrote:
I've been assuming it's a left-side wins, as you're tacking onto an
existing string, so you'd get English in all cases. Alternately you
could get an exception. The end result of a mixed-language operation
could certainly be the Dunno language or the
Thanks for your response. I'm not sure that you and I are speaking about
exactly the same things, since you state that the logical extensions, if
not outright goals, of an alternate approach would be an exclusionary
monoculture. I'm not sure that's quite right
On Tue, 2004-04-13 at 15:06, Dan
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> For example, in Perl5/Ponie:
> @names=;
> print "Phone Book: ", sort(@names), "\n";
> In this example, I don't see why I would care that NAMES might be a
> pseudo-handle that iterates over several databases, and returns strings
> in the 7
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> I really see no reason to store strings as UTF-{8,16,32} and waste CPU
> cycles on decoding it when we can do a lossless conversion to a format
> that's both more compact (in the most common cases) and faster.
The default format now isn't UTF8
At 11:28 PM +0200 4/13/04, Michael Scott wrote:
On 13 Apr 2004, at 22:48, Dan Sugalski wrote:
Note that the language might be "Dunno". :) There'll be a default
that's assigned to input data and suchlike things, and the language
markers in the strings can be overridden by code.
Would this be rig
On 13 Apr 2004, at 22:48, Dan Sugalski wrote:
Note that the language might be "Dunno". :) There'll be a default
that's assigned to input data and suchlike things, and the language
markers in the strings can be overridden by code.
Would this be right?
English + English = English
English + Chine
At 10:44 PM +0200 4/13/04, Michael Scott wrote:
On 12 Apr 2004, at 17:43, Dan Sugalski wrote:
IW: Mush together (either concatenate or substr replacement) two
strings of different languages but same charset
TP: Checks to see if that's allowed. If not, an exception is
thrown. If so, we do the ope
On 12 Apr 2004, at 17:43, Dan Sugalski wrote:
IW: Mush together (either concatenate or substr replacement) two
strings of different languages but same charset
TP: Checks to see if that's allowed. If not, an exception is thrown.
If so, we do the operation. If one string is manipulated the languag
At 12:44 PM -0700 4/13/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
1) Parrot will *not* require Unicode. Period. Ever.
My old 8MB Visor Prism thanks you.
:) As does my gameboy.
*) Transform stream of bytes to and from a set of 32-bit integers
*) Manages byte buffer (so buffer positioni
Dan Sugalski wrote:
> 1) Parrot will *not* require Unicode. Period. Ever.
My old 8MB Visor Prism thanks you.
> *) Transform stream of bytes to and from a set of 32-bit integers
> *) Manages byte buffer (so buffer positioning and manipulation by code
> point offset is handled here)
What's wrong wit
At 1:55 PM -0400 4/13/04, Aaron Sherman wrote:
Ok, I'm still lost on the language thing. I'm not arguing, I just don't
get it, and I feel that if I'm going to do some of the things that I
want to for Perl 6, I'm going to have to get it.
On Mon, 2004-04-12 at 11:43, Dan Sugalski wrote:
Language
=
Ok, I'm still lost on the language thing. I'm not arguing, I just don't
get it, and I feel that if I'm going to do some of the things that I
want to for Perl 6, I'm going to have to get it.
On Mon, 2004-04-12 at 11:43, Dan Sugalski wrote:
> Language
>
> *) Provides language-sensitive man
At 10:42 AM +0300 4/13/04, Jarkko Hietaniemi wrote:
Matt Fowles wrote:
Dan~
I know that you are not technically required to defend your position,
but I would like an explanation of one part of this plan.
Dan Sugalski wrote:
4) We will *not* use ICU for core functions. (string to number or nu
Matt Fowles wrote:
> Dan~
>
> I know that you are not technically required to defend your position,
> but I would like an explanation of one part of this plan.
>
> Dan Sugalski wrote:
>
>>4) We will *not* use ICU for core functions. (string to number or number
>>to string conversions, for exa
Dan~
I know that you are not technically required to defend your position,
but I would like an explanation of one part of this plan.
Dan Sugalski wrote:
4) We will *not* use ICU for core functions. (string to number or number
to string conversions, for example)
Why not? It seems like we would
Just thought I'd mention that I'm in the process of trying to get
strings.pod updated to reflect the current state of affairs.
Mike
Okay, I've not dug through all the fallout from the ICU checkin, but
I can see there's an awful lot. I'll dig through that in a bit, but...
Here's the plan. We've gone over it in the past, but I'm not sure
everything's been gathered together, so it's time to do so.
Some declarations:
1) Parrot
27 matches
Mail list logo
