Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!agate!ucbvax!TURING.CSE.NAU.EDU!sbw
From: sbw@TURING.CSE.NAU.EDU (Steve Wampler)
Newsgroups: comp.lang.icon
Subject: Re: longstr oops
Message-ID: <9103200244.AA15863@turing.cse.nau.edu>
Date: 20 Mar 91 02:44:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 31

On Mar 19 at 19:35, isidev!nowlin@uunet.uu.net writes:
} 
} The 'while' was not a mistake.  The program I posted with test data and a
} main procedure in it worked just fine with a 'while' instead of an
} 'every'.  I wasn't looking for iteration here.  I was looking for GOAL
} DIRECTED EVALUATION.  The 'while' forces the expression:
} 
}         m <:= *(s[i:j] ?  =!l)
} 
} to do everything it can to succeed.  Since there's a generator in this
} expression (!l) all the strings in 'l' are generated every time through the
} loop until one of the strings is matched and it's longer than the last
} string that was matched.  GOAL DIRECTED EVALUATION forces the generator to
} generate so you don't need an 'every'.  When there are no more strings in
} 'l' that will match and that are longer than the last match the loop
} terminates.
} 
} The 'every' works, but for a different reason.  The 'every' is probably
} faster since it only iterates through the list once.  It's important to
} understand why both work for different reasons.  They both work though.

Along the same lines, if the list were sorted by length of strings
(longest first), you can eliminate the 'while' and the 'every' and
let's GDE do it's thing.  It just doesn't seem worth it do so...

And anyway, I definitely like Bob Alexander's solution more.

-- 
	Steve Wampler
	{....!arizona!naucse!sbw}
	{sbw@turing.cse.nau.edu}