From: Franck A. <fr...@ne...> - 2008-08-19 16:49:17
|
> No it doesn't. What about variant and invariant? Does it go without > saying that you are going to remove invariant? It goes without saying for variant, and it goes without saying that the non-loop invariant stays. > And until might want to be re-used. yes, I'm only talking of the looping construct, it might indeed be an opportunity to reuse the keywords, keyword reuse would require some saying. > Franck> INTEGER_INTERVAL.do_all, I'd use recursion, it would help > Franck> if the compiler recognises it in some way so that the > Franck> generated code does not use stack space, but it's the only > Franck> place where you need a slight implementation-level cheat. > > If the compiler can implement tail recursion, why can't you? well you can actually: class INTEGER_INTERVAL ... do_all (a_agent: PROCEDURE [ANY, TUPLE[INTEGER]) -- Apply to all integers between 'lower' and 'upper'. local i: INTEGER do if i <= count then a_agent.call ([i + lower]) i := i + 1 raise ("forth") end -- else exit loop rescue retry end end arguably that's a bit sick. but it also confirms that we have too many looping constructs as we stand. also a drawback is that when I will suggest removing "retry" you're going to argue that we need it to implement INTEGER_INTERVAL :-). > Franck> as for loops which are open ended and not index-based, (1 > Franck> |..| Maximum_integer).do_until should be OK, and again if > > Not for network servers which implement do forever until shutdown > request. This might well exceed Maximum_integer. that's debatable. with 64 bit integers you can do_forever 1 billion times a second for 100 years, which is a hell of an uptime for a network server, and a hell of a lot of transaction throughput. for 32 bit it is perhaps slightly more debatable but then you can implement 64 bit one on top of 2 32 bits ones. > Franck> all else fails you can always fallback on recursion but > Oh no you can't! in what way? |