RE: Uses for array notation (was Re: RFC 104 (v1) Backtracking)

2000-08-22 Thread Brust, Corwin
-Original Message- From: Jeremy Howard [mailto:[EMAIL PROTECTED]] [...] Programmers shouldn't have to know how a computer implements things behind the scenes--which is really what requiring explicit looping forces. Great point, this should be in the RFC. -Corwin

Re: RFC 104 (v1) Backtracking

2000-08-17 Thread David L. Nicol
Jonathan Scott Duff wrote: > > On Tue, Aug 15, 2000 at 05:47:53PM -0600, Nathan Torkington wrote: > > I want > > @result = @a || @b; > > to be like: > > (@result = @a) or (@result = @b); > > > > That's what all my students keep expecting it to mean. > > And that's what I keep wishing it mea

Re: RFC 104 (v1) Backtracking :ref

2000-08-17 Thread raptor
=head1 REFERENCE Icon language brief intro : http://www.cs.arizona.edu/icon/intro.htm

Re: RFC 104 (v1) Backtracking

2000-08-17 Thread raptor
hi, > > So how is that different from: > > > > do BLOCK1 until do BLOCK2 > > It's the same. > But the real fun starts when blocks and functions can suspend and > resume. > >{ ... > # Return value and suspend. > suspend $i; > # Next iteration will resume here > ... >} a

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread John Porter
Johan Vromans wrote: > > So how is that different from: > > > > do BLOCK1 until do BLOCK2 > > It's the same. No, not quite. See my other post. -- John Porter

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread Jonathan Scott Duff
On Wed, Aug 16, 2000 at 07:42:33PM +1000, Jeremy Howard wrote: > raptor wrote: > > ]- I tried minimalistic approach as small as possible additions to the > Perl > > language, we get only the "backtrack" mechanism i.e. something that is > > harder or slower to be done outside of the perl core. > >

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread John Porter
Damian Conway wrote: > > So how is that different from: > > do BLOCK1 until do BLOCK2 > > ??? Because if BLOCK1 ever evaluates to False, the operation terminates. It's more like do { r = f1() } until ( not r or f2() ); -- John Porter

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread Chaim Frenkel
> "MC" == Mark Cogan <[EMAIL PROTECTED]> writes: >> is equivalent to >> >> @a = (\$a, \$b, \$c); >> >> rather than what you wrote. MC> Ah, so it is. I'd argue that that's broken and should be handled with map MC> or for. Err, That's not an accident. Larry designed that in. -- Chaim F

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread Jeremy Howard
Johan Vromans wrote: > Damian Conway <[EMAIL PROTECTED]> writes: > > >> As I understand things: > >> > >> BLOCK1 andthen BLOCK2 > >> > >> evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates > >> BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2 > >

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread Johan Vromans
Damian Conway <[EMAIL PROTECTED]> writes: >> As I understand things: >> >> BLOCK1 andthen BLOCK2 >> >> evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates >> BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2 >> evaluates to "false", then BL

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread Jeremy Howard
raptor wrote: > ]- I tried minimalistic approach as small as possible additions to the Perl > language, we get only the "backtrack" mechanism i.e. something that is > harder or slower to be done outside of the perl core. > The rest should be done outside . (I too want all in the core) I don't

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread raptor
> > They behave similarly like &&, ||, and, or operator with one main > > distinction they "backtrack" for example: > > > > { block1 } B { block2 }; > > This would be a good use of the to-be-liberated => operator: > > { block1 } => { block2 }; > > In any case, "andthen" doesn't seem like a good

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread raptor
> There's also the cut operator which I didn't see mentioned in the RFC. > It blocks backtracking so that something like this: > > B1 andthen B2 andthen cut B3 andthen B4 andthen B5 > wouldn't backtrack to B2 once it forwardtracked to B3. ]- I tried minimalistic approach as small as possible addi

Array notation (was Re: RFC 104 (v1) Backtracking)

2000-08-15 Thread Jeremy Howard
Mark Cogan wrote: > At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote: > >You are missing the beauty of vector/matrix operations. > > No, I'm not; I'm opining that the vast majority of Perl users don't need to > do vector/matrix ops, and that they don't belong in the core. > The vast majority of Perl

Uses for array notation (was Re: RFC 104 (v1) Backtracking)

2000-08-15 Thread Jeremy Howard
Mark Cogan wrote: > At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote: > >It seems obvious that @a should be the whole array @a, not the size of the > >array. If I want to check the size of @a, I should have to do so explicitly, > >with scalar or $#. > > > >This is non-obvious if you think that || is

Re: Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)

2000-08-15 Thread Damien Neil
On Tue, Aug 15, 2000 at 10:26:13PM -0600, Nathan Torkington wrote: > I like the idea of adding the context-aware operators, but I don't > think I'd use them as often as I use "the number of things in the > array". I think most Perl programmers would be in the same camp. > Unless you can show a co

RFC 104 (v1) Backtracking

2000-08-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Backtracking =head1 VERSION Maintainer: iVAN Georgiev <[EMAIL PROTECTED]> Date: 14 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 104 =head1 ABSTRACT Backtraking mechanism is core f