# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #38931]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38931 >
This is a suggestion regarding double-quoted string literals
in Parrot. Currentl
On Sun, Apr 16, 2006 at 11:22:40AM -0700, Patrick R. Michaud wrote:
> This is a suggestion regarding double-quoted string literals
> in Parrot. Currently double-quoted strings are always assumed
> to be ASCII unless prefixed by a different charset identifier
> such as 'unicode:' or 'iso-8859-1:'.
On Sun, Apr 16, 2006 at 11:36:10AM -0700, Nicholas Clark via RT wrote:
> IIRC having ASCII as the default was a deliberate design choice to avoid
> the confusion of "is it iso-8859-1 or is it utf-8" when encountering a
> string literal with bytes outside the range 0-127.
Reasonable. Essentially
On Sun, Apr 16, 2006 at 04:41:05PM -0500, Patrick R. Michaud wrote:
> > If PGE is always outputting UTF-8 literals, what stops it from always
> > prefixing every literal "unicode:", even if it only uses Unicode characters
> > 0 to 127?
> [...]
> Also, once introduced unicode strings tend can easily
On Sun, Apr 16, 2006 at 04:41:05PM -0500, Patrick R. Michaud wrote:
> I also realized this past week that using 'unicode:' on
> strings with \x (codepoints 128-255) may *still* be a bit
> too liberal -- the « french angles » will still cause
> "no ICU library present" errors, but would seemingly
On Thu, Apr 13, 2006 at 01:55:28AM +0200, Leopold Toetsch wrote:
> On Apr 11, 2006, at 19:03, Chip Salzenberg wrote:
> >2. "Reference Model" for value objects
> > In Parrot, this mostly amounts to unique read-only PMCs.
> > We'll have the read-only part, but the "unique" part, probably not.
>
Nicholas Clark wrote:
> On Sun, Apr 16, 2006 at 11:22:40AM -0700, Patrick R. Michaud wrote:
>> $S1 = "He said, \xabHello\xbb"
>> $S2 = "3 \u2212 4 = \u207b 1"
>>
>> are treated as ASCII strings even though they obviously contain
>> codepoints outside of the ASCII range. (The first results
Author: chip
Date: Sun Apr 16 20:33:54 2006
New Revision: 12283
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
* Added requirement that ."load_library"() throw an exception on
failure. Also noted that the exception is only covering for the lack of a
universal error PMC, which I would
Author: chip
Date: Sun Apr 16 21:21:53 2006
New Revision: 12284
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
* Documented clearly & consistently that all namespace opcodes start their
search in the HLL root namespace, *not* at the global root.
* Added a second namespace method to the
This is an old message I'm replying to, so I'll copy most of it.
On Fri, Mar 10, 2006 at 07:05:34PM +0100, Leopold Toetsch wrote:
>Code snippet # NameSpace::name
>
> .sub main # '' actually parrot [1]
> store_global 'x', $P0#
Based on a status report from Leo {thanks!} and my recent revisions to
pdd21, here's a list of things that need to be done to bring parrot fully
into the new world of namespaces. The items are roughly in descending order
of importance. There's room for several contributors here
[[ NAMESPACE
On Sunday 16 April 2006 22:00, Chip Salzenberg wrote:
> * standard Parrot libraries not associated with any HLL should have their
> own namespaces
>
> For example, PGE should live in a ["pge"] namespace, or, conceivably,
> under ["parrot";"PGE"]. In any case, the current double colons a
12 matches
Mail list logo
