Distinguish listy ords/chrs from ord/chr

It will be too confusing to overload ord/chr with both scalar and
list semantics.  This will also give more information to the optimizer
at compile time, since it cannot know whether .ord will be passed
a single- or multi-character string

S29-functions.pod

@@ -19,8 +19,8 @@ Synopsis 29: Builtin Functions
 
     Created: 12 Mar 2005
 
-    Last Modified: 20 Nov 2010
-    Version: 47
+    Last Modified: 10 Dec 2010
+    Version: 48
 
 The document is a draft.
 
@@ -293,27 +293,29 @@ C<BUILDALL> routine for the current class, which initializes the object in
 least-derived to most-derived order. See L<S12/Objects>
 for more detailed information on object creation.
 
+=item chrs
+
+=item ords
+
 =item chr
 
 =item ord
 
+ multi sub chrs( Int *@grid  --> List of Char )
+ multi method ords( Str $string: --> List of Int ) is export
  multi method chr( Int $grid: --> Char ) is export
- multi sub chr( Int *@grid  --> Char )
  multi method ord( Str $string: --> Int ) is export
 
-C<chr> takes zero or more integer grapheme ids and returns the
+C<chrs> takes zero or more integer grapheme ids and returns the
 corresponding characters as a string.  If any grapheme id is used
 that represents a higher abstraction level than the current
 lexical scope supports, that grapheme is converted to the
 corresponding lower-level string of codepoints/bytes that would
 be appropriate to the current pragmatic context, just as any other Str
 would be downgraded in context.
 
-C<ord> goes the other direction; it takes a string value and returns
-character values as integers.  In item context, the return value
-is the just the integer value of the first character in the string. In
-list context, the return value is the list of integers representing
-the entire string.  The definition of character is pragma dependent.
+C<ords> goes the other direction; it takes a string value and returns
+character values as integers.  The definition of character is pragma dependent.
 Normally it's a grapheme id, but under codepoints or bytes scopes,
 the string is coerced to the appropriate low-level view and interpreted
 as codepoints or bytes.  Hence, under "use bytes" you will never see a
@@ -329,6 +331,10 @@ context knows its normalization preferences, and every byte's context
 also knows its encoding preferences. (These are knowable in the
 lexical scope via the $?NF and $?ENC compile-time constants).)
 
+The C<chr> and C<ord> variants are restricted to processing a single
+character.  As is customary, you may pass a longer string to C<ord>,
+but only the first character will be translated.
+
 =item item
 
  our Item multi item ( $item )