Re: scalar subscripting

[Luke Palmer]

Hans Ginzel writes:
> On Thu, Jul 08, 2004 at 09:12:16PM +1000, Gautam Gopalakrishnan wrote:
> > about string subscripting. Since $a[0] cannot be mistaken for array subscripting
> > anymore, could this now be used to peep into scalars? Looks easier than using
> 
>Are there plans in Perl 6 for string modifiers? 

Not exactly.  But method calls can be interpolated into strings, so most
of this is pretty straightforward:

> As they are in bash eg.:
>   ${var%glob_or_regexp}
>   ${var%%glob_or_regexp}

my $newfile = "$str.subst(rx|\.\w+$|, '')\.bin";

>   ${var#glob_or_regexp}
>   ${var##glob_or_regexp}

say "Basename is $str.subst(rx|.*/|, '')"

>   ${var/pattern/string}

say "$str.subst(rx|foo|, 'bar')"

>   ${var:[+-=]word}

# ${var:-word}
say "You chose $($value // 'no value')";

# ${var:=word}
say "You chose $($value //= 'no value')";

# ${var:?word}
say "You chose $($value // die 'please choose a value')"

Luke

Re: scalar subscripting

[Hans Ginzel]

On Thu, Jul 08, 2004 at 09:12:16PM +1000, Gautam Gopalakrishnan wrote:
> about string subscripting. Since $a[0] cannot be mistaken for array subscripting
> anymore, could this now be used to peep into scalars? Looks easier than using

   Are there plans in Perl 6 for string modifiers? As they are in bash
eg.:
${var%glob_or_regexp}
${var%%glob_or_regexp}
${var#glob_or_regexp}
${var##glob_or_regexp}
${var/pattern/string}
${var:[+-=]word}

Best regards

Hans Ginzel

Re: push with lazy lists

[JOSEPH RYAN]

> On Wed, Jul 07, 2004 at 11:50:16PM -0400, JOSEPH RYAN wrote:
>
> To answer the latter first, rand (with no arguments) returns a number
> greater than or equal to 0 and less than 1 which when used as an index
> into an array gets turned into a 0.
> 
> As to why the second pop would take forever, I'd imagine that in order
> to pop the last item from the array, all of the elements must 
> first be
> generated (i.e. we lose all laziness). And unless we have some 
> magic for
> generating them from either end, it'll start at the begining and
> continue until the end, then stop before it ever does the pop. :-)

Ah, right, I should known that, in both cases. (:  Thanks for answering my silly 
questions.

- Joe

Re: fast question

[Larry Wall]

On Thu, Jul 08, 2004 at 11:46:25AM -0700, Larry Wall wrote:
: With an array
: match, you might find yourself redispatching individual operators in a
: switch statement to provide that kind of specificity.

In particular, macros with "is parsed" will want to have a place to
hang their special parse rules without having to look up the macro name
twice.  And when you think about it, maybe ordinary left parenthesis
is just stored as a circumfix macro with an "is parsed" rule of "expr".
Then circumfix:() and postcircumfix:() can automatically dispatch to
different locations.  Likewise for {} and [].

Larry

Re: fast question

[Larry Wall]

On Thu, Jul 08, 2004 at 04:49:33AM -0600, Luke Palmer wrote:
: Michele Dondi writes:
: > On the wild side of things, could there be the possibility of even
: > defining new ones?
: 
: That's what I meant by:
: 
: grammatical_category:postcircumfix
: 
: Though it wouldn't be so magical as to just know what you mean.  If your
: mucking with the grammar, though, you should be able to insert hooks.
: After all, the writers of the perl 6 parser have to do it.
: 
: rule prefix_op() {
: (@(%Perl::guts::grammatical_categories«prefix»))
: 
:   |
: 
: }
: 
: Or something.

I like it when someone says "or something" about the same place I'd
say "or something".  :-)

However, in the interests of dewaffling, I have a couple of quibbles.
I don't know what that @() is doing there--I presume you meant @{}.
Also, it's not clear that you want an array there, but I understand
you're indicating that the tokens have to be matched in some particular
order that is unspecified but not arbitrary (presumably longer
tokens preceding any shorter prefixes of those tokens).  As I said in
another message, though, we might want to force hashes to automatically
tokenize in a longest-token-first fashion (or at least have the option
of doing so), and using a hash would allow the keys to be the strings
and the values to be individual actions to be taken.  With an array
match, you might find yourself redispatching individual operators in a
switch statement to provide that kind of specificity.  For efficiency,
either an array or a hash would want to be preprocessed into some
other kind of trie or other data structure for fast tokenizing anyway,
so it's not like doing it with an array is buying you much unless you
really need to specify the order of matching.

You might think we need to specify order so that lexicalized operator
definitions can override more global ones, but I suspect we actually
have to copy the array or hash into the derived grammar in any event to
properly emulate method overriding for things that aren't really methods,
so that when we revert the grammar it reverts the user-defined operators
as well.

Or something...

My other quibble is that I hope this level of operator can be parsed
with operator precedence rather than rules.  Higher level rules
drop into the operator precedence parser when they see things like
, and the operator precedence parser drops into lower level
rules before returning a "term" token (or if a macro specifies a
particular followup parsing rule).  Of course, it's possible that
our tokener is just a fancy rule, in which case it would strongly
resemble what you have above, only maybe with more alternatives,
depending on where we decide to recognize the various kinds of terms.

Oddly, depending on how we decide to do operator precedence, we might
not do the conventional thing of treating parenthesized expressions
as terms, but just make parens into pseudo operators that jack up
the internal precedence and return the parens as individual tokens.
But maybe we should stick with the ordinary recursive definition--it
might give better error messages on missing parens, and we've already
eliminated the 20-odd recursion levels that a strict recursive descent
parser would impose on parentheses anyway.

Or something.  :-)

Larry

Re: The .bytes/.codepoints/.graphemes methods

[Austin Hastings]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 29, 2004 at 10:52:34AM -0500, Jonathan Scott Duff wrote:
> 
> : Or was that to imply that a literal "a" in the RE would be
> : interpretted as a "grapheme a" when :u2 is active?
> 
> I don't know what you mean by "grapheme a" there.  If you mean, "Does
> it match any grapheme that happens to be exactly U+0061?", then the
> answer is yes.  

In my original question, I meant to differentiate between 'grapheme'
and 'possible component of a multibyte expression'.

> If you mean "Does it wildcard to any grapheme that uses
> U+0061 as the base character?", then the answer is probably no.  We
> have not yet come up with a syntax for that kind of wildcarding,
> other than dropping down to codepoints [:u1 a \pM+] or some such. 
> That may or may not be sufficient.  It'd be pretty easy to define a 
>  assertion in any case.

I think this is something that we'll want as a "mode", a la
case-insensitivity. Think of it as "mark insensitivity."

I'm not sure if this should be language/locale dependent or not, but a
basic search feature for text is "fre'd" -> "fred". 

Maybe it can just roll into :i?

=Austin

Re: This week's summary

[Dan Sugalski]

On Thu, 8 Jul 2004, Piers Cawley wrote:

> "Jonadab the Unsightly One" <[EMAIL PROTECTED]> writes:
>
> > The Perl 6 Summarizer <[EMAIL PROTECTED]> writes:
> >
> >>   Different OO models
> >> Jonadab the Unsightly One had wondered about having objects
> >> inheriting behaviour from objects rather than classes in Perl 6.
> >
> > Urgle.  I've completely failed to explain myself so as to be
> > understood.  That wasn't at *all* what I had in mind.
>
> It could well be that I didn't read things carefully enough.

Maybe, but that's what I got out of it as well.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: scalar subscripting

[Luke Palmer]

Gautam Gopalakrishnan writes:
> Hello,
> 
> I've tried the archives and the 'Perl 6 essentials' book and I can't
> find anything
> about string subscripting. Since $a[0] cannot be mistaken for array subscripting
> anymore, could this now be used to peep into scalars? Looks easier than using
> substr or unpack. Hope I've not missed anything obvious.

Well, no, it can't really.  $a[0] now means what Perl 5 called $a->[0]
(or @$a[0]).  So it's still an array subscript, it's just subscripting
$a, not @a.

But there's talk about using the various character type methods to
return lists of characters.  So if you want the first byte of your
string, you can say:

$str.bytes[0];

And if you want the first codepoint:

$str.codepoints[0];

Etc.

Luke

Re: scalar subscripting

[Juerd]

Gautam Gopalakrishnan skribis 2004-07-08 21:12 (+1000):
> about string subscripting. Since $a[0] cannot be mistaken for array subscripting
> anymore, could this now be used to peep into scalars? Looks easier than using

$a[0] is $a.[0]. That means that if there is a @$a, it still is array
subscripting.

Accessing strings as if they are arrays was discussed recently. Please
read the archives. (groups.google.com is my favourite interface)


Juerd

scalar subscripting

[Gautam Gopalakrishnan]

Hello,

I've tried the archives and the 'Perl 6 essentials' book and I can't
find anything
about string subscripting. Since $a[0] cannot be mistaken for array subscripting
anymore, could this now be used to peep into scalars? Looks easier than using
substr or unpack. Hope I've not missed anything obvious.

Cheers
Gautam

Re: fast question

[Luke Palmer]

Michele Dondi writes:
> On Wed, 7 Jul 2004, Luke Palmer wrote:
> 
> > > Are there others, aside from these:  ?
> > > 
> > > prefix: a unary prefix operator
> > > infix:  a binary infix operator
> > > postfix:a binary suffix operator
> > > circumfix:  a bracketing operator
> > 
> > Tons.  From A12:
> [snip]
> 
> On the wild side of things, could there be the possibility of even
> defining new ones?

That's what I meant by:

grammatical_category:postcircumfix

Though it wouldn't be so magical as to just know what you mean.  If your
mucking with the grammar, though, you should be able to insert hooks.
After all, the writers of the perl 6 parser have to do it.

rule prefix_op() {
(@(%Perl::guts::grammatical_categoriesÂprefixÂ))

  |

}

Or something.

Luke

> Michele
> -- 
> DAX ODIA ANCORA
> - Scritta su diversi muri milanesi

Re: This week's summary

[Piers Cawley]

"Jonadab the Unsightly One" <[EMAIL PROTECTED]> writes:

> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes:
>
>>   Different OO models
>> Jonadab the Unsightly One had wondered about having objects
>> inheriting behaviour from objects rather than classes in Perl 6.
>
> Urgle.  I've completely failed to explain myself so as to be
> understood.  That wasn't at *all* what I had in mind.

It could well be that I didn't read things carefully enough.

Re: fast question

[Michele Dondi]

On Wed, 7 Jul 2004, Luke Palmer wrote:

> > Are there others, aside from these:  ?
> > 
> > prefix: a unary prefix operator
> > infix:  a binary infix operator
> > postfix:a binary suffix operator
> > circumfix:  a bracketing operator
> 
> Tons.  From A12:
[snip]

On the wild side of things, could there be the possibility of even
defining new ones?


Michele
-- 
DAX ODIA ANCORA
- Scritta su diversi muri milanesi