Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <d...@sidhe.org>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 96422 invoked by uid 76); 14 Apr 2004 19:04:07 -0000
Received: from x1.develooper.com (HELO x1.develooper.com) (63.251.223.170)
  by onion.perl.org (qpsmtpd/0.27.1) with SMTP; Wed, 14 Apr 2004 12:04:07 -0700
Received: (qmail 15092 invoked by uid 225); 14 Apr 2004 19:04:03 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 15065 invoked by alias); 14 Apr 2004 19:04:02 -0000
X-Spam-Status: No, hits=0.0 required=7.0
	tests=
X-Spam-Check-By: la.mx.develooper.com
Received: from 178.94.252.64.snet.net (HELO sprite.sidhe.org) (64.252.94.178)
  by la.mx.develooper.com (qpsmtpd/0.27.1) with SMTP; Wed, 14 Apr 2004 12:04:01 -0700
Received: (qmail 19874 invoked from network); 14 Apr 2004 19:03:22 -0000
X-Scanned-By: AMaViS-ng at sidhe.org
Received: from unknown (HELO ?10.0.1.2?) (d...@65.75.18.11)
  by 178.94.252.64.snet.net with SMTP; 14 Apr 2004 19:03:19 -0000
Mime-Version: 1.0
X-Sender: dan@localhost
Message-ID: <a06100503bca33afa00b8@[10.0.1.2]>
In-Reply-To: <5CDA67D0-8E08-11D8-9E7F-000A95C50226@mac.com>
References: <a06100500bca0384ce81c@[10.0.1.2]>
 <56A9B660-8D8B-11D8-9E7F-000A95C50226@mac.com>
 <a06100510bca202500fff@[10.0.1.2]>
 <82C7C521-8D91-11D8-9E7F-000A95C50226@mac.com>
 <a06100511bca20cd887a8@[10.0.1.2]>
 <5CDA67D0-8E08-11D8-9E7F-000A95C50226@mac.com>
Date: Wed, 14 Apr 2004 15:02:55 -0400
To: Michael Scott <michael_sc...@mac.com>
Subject: Re: Plans for string processing
Cc: P6I List <perl6-intern...@perl.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Approved: n...@nntp.perl.org
From: d...@sidhe.org (Dan Sugalski)

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 
>>operation could certainly be the Dunno language or the current 
>>default--both'd be reasonable.
>>
>
>Would I be right in thinking that *language* in the context of 
>Parrot strings is not necessarily an accurate description of the 
>actual language of the string, but rather a means of specifying a 
>particular set of idiosyncratic behavior normally associated with an 
>actual language?

Basically, yes.

>Is there ever a situation where the contents of the 
>appended/inserted strings are altered because of the change in 
>*language*? In other words, are there any *language* (as distinct 
>from character set) transforms? And, can new *languages* be defined?

New language code could certainly be defined, yes. I'm not sure you'd 
see too many explicit transforms from one to another past some sort 
of initial classification.

>For example, will there be a way to define a *language* "toetsch" 
>where 'ro' becomes '0r' in 'b0rken', and 'see' becomes 's.'?

Probably not, no, unless you really wanted to mangle the 
upcase/downcase/titlecase transformations.
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk