On Thu, Mar 31, 2005 at 03:03:09PM +0200, Thomas Sandlaß wrote:
: Larry Wall wrote:
: >On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: >: How can you have a level independent position?
: >
: >By not confusing positions with numbers. They're just pointers into
: >a particular string.
:
: I'm not the Unicode guru but my understanding is that all composition
: sequences are finite and stateless with respect to everything before
: and after them in the string. Which brings me to the question if these
: positions are defined like positions in Emacs as lying *between* the
: chars? Then the set of positions of a higher level is a subset of the
: positions of lower levels.
Yes, that's how I've been thinking of them. Thanks for making that explicit.
: With defining position as between chars many operations on strings are
: downwards compatible between levels, e.g. splitting. If one determines
: e.g. an insert position on a higher level there's no problem in letting
: the actual insertion beeing handled by a lower level. With fractional
: positions on higher levels some degree of upward or tunneling
: compatibility can be achieved.
That's my feeling.
: BTW, will bidirectionality be supported? Does it make sense to reflect
: it in the StrPos type such that $pos_start < $pos_end means a non-empty
: left to right string, $pos_start > $pos_end is a non-empty right to left
: string and $pos_start == $pos_end delimit an empty (sub)string? As a
: natural consequence the sign indicates direction with negative length
: beeing right to left. And that leads to two times two types of iterators:
: left to right, right to left, start to end and end to start.
Offhand I'd rather have end < start be undefined, I think, but I
suppose we could give it a meaning if it turns out not to be an
easily generated degenerate case like 0..-1. On the other hand,
I think right-to-left might deserve more Huffman visibility than an
itty-bitty sign that might be hidden down in a varible.
But then, we've played games with signs in substr and splice before.
It's not clear that people would want substr($x, -3) to return the
characters in reversed order, though.
: All the above leads me to rant about an array like type. Please forgive
: me if the following is not proper Perl6. My point is to illustrate how
: I imagine the future communication between implementor and user of such
: a class. Actually some POD support for extracting the type information
: into the documentation would be great, too!
:
: And yes, the :analyse should be made lazy. The distinction between the
: first and second index method could be even more specific by using
: type 'Index ^ List of Str where { $_.elems == 1 }' to convey the
: information that indexing with a list of one element doesn't result
: in a List of Str but a plain Str. OTOH this will incur a performance
: penalty and violate the intuitive notion "list in, list out".
MEGO.
: class StrPosArray does Array where { ::Index does StrPos }
: {
: has Str $:data;
: has StrPos @:pos;
:
: multi method postcircumfix:<[ ]>
: (: Index $i ) returns Str {...}
: multi method postcircumfix:<[ ]>
: (: List of Index $i ) returns List of Str {...}
: multi method postcircumfix:<[ ]>
: (: Range of Index $i ) returns List of Str {...}
: multi method postcircumfix:<[ ]>
: (: Int $i ) returns Str {...}
:
: # more stuff here for push, pop, shift etc.
:
: method infix:<=> (: Str $rhs ) returns ::?CLASS
: {
: $:data = $rhs;
: :analyse;
: }
:
: method :analyse ()
: {
: # scan $:data for all between char positions
: # and store them into @:pos
: }
: }
:
: Question:
: does the compiler go over this source in multiple passes
: such that the declaration of :analyse is known before its
: usage in infix:<=>?
No, you just throw in a forward declaration with {...} in that case.
Larry
