New loop construct

[Martin Piskernig]

Hi!

For release "6.5.8.1483 (Release Candidate)" on dev.eiffel.com there is a note:
"compiler: New loop constructs implementation per a draft specification of the
next ECMA standard.". I think this is it what Bertrand announced some months
ago when I asked about a "for each" loop in Eiffel but he apparently haven't
had time yet to post about it in his blog. Is there any other documentation on
the new loop construct?

Kind regards,
Martin

[Peter Horan]

On 5 Nov 2009, Manu wrote:

        NLC = New Loop Construct.

        This is a new ECMA proposal for doing something like

        across list as l_cursor
                loop
                   l_cursor.item.do_something
        end

without having to worry about calling `start' and `forth'.
--
Peter Horan             Faculty of Science and Technology
[hidden email]     Deakin University
[phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
[phone] (Mobile)

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

[helmut.brandl]

Does this loop have an invariant?

Regards
Helmut

Peter Horan wrote:

> On 5 Nov 2009, Manu wrote:
>
> NLC = New Loop Construct.
>
> This is a new ECMA proposal for doing something like
>
> across list as l_cursor
> loop
>   l_cursor.item.do_something
> end
>
> without having to worry about calling `start' and `forth'.
> --
> Peter Horan             Faculty of Science and Technology
> [hidden email]     Deakin University
> [phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
> [phone] (Mobile)
>
> -- The Eiffel guarantee: From specification to implementation
> -- (http://www.cetus-links.org/oo_eiffel.html)
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Peter Gummer-2]

Helmut Brandl wrote:

> Does this loop have an invariant?

There are some test cases in the EiffelStudio Subversion log that  
suggest yes. For example:

http://svn.origo.ethz.ch/wsvn/eiffelstudio/?op=comp&compare[]=
%2F@81446&compare[]=%2F@81447

- Peter Gummer

[ordovico]

The word "as" for the cursor attachment seems a bit awkward - were the words
"with" or "using" considered?

 

Jonathan Wilcox

 



[Non-text portions of this message have been removed]

[Emmanuel Stapf]

We are merely reusing the same keyword used for the same purpose in the object
test syntax:

attached expr as var
across container as var

Regards,
Manu

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jonathan Wilcox
> Sent: Friday, November 13, 2009 10:31 AM
> To: [hidden email]
> Subject: [eiffel_software] Re: New loop construct
>
> The word "as" for the cursor attachment seems a bit awkward - were the
> words
> "with" or "using" considered?
>
>
>
> Jonathan Wilcox
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Jann Röder]

In across container as c loop ... end,
why do you always have to use c.item instead of just c? Is there
anything else you can do on c except calling .item on it ?

Jann

Am 13.11.09 19:47, schrieb Emmanuel Stapf [ES]:

> We are merely reusing the same keyword used for the same purpose in the object
> test syntax:
>
> attached expr as var
> across container as var
>
> Regards,
> Manu
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Jonathan Wilcox
>> Sent: Friday, November 13, 2009 10:31 AM
>> To: [hidden email]
>> Subject: [eiffel_software] Re: New loop construct
>>
>> The word "as" for the cursor attachment seems a bit awkward - were the
>> words
>> "with" or "using" considered?
>>
>>
>>
>> Jonathan Wilcox
>>
>>
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Emmanuel Stapf]

> In across container as c loop ... end,
> why do you always have to use c.item instead of just c? Is there
> anything else you can do on c except calling .item on it ?

One thing you can do is query the `index' in the current iteration. It was debated over and we felt that providing the cursor rather than the item was much more powerful with little loss in the simplicity.

Regards,
Manu

[Jann Röder]

Sure it is more powerful, but this whole thing being a shortcut, I would
assume its main purpose is to be short for probably 95% of its uses.

I was surprised anyway. Eiffel always prided itself for having only one
good way of doing things - now we are getting a second loop construct.
What's next?

Since the decision has already been made it is pointless to start a
discussion, I'm just a bit confused.

Jann

Am 14.11.09 00:26, schrieb Emmanuel Stapf [ES]:

>> In across container as c loop ... end,
>> why do you always have to use c.item instead of just c? Is there
>> anything else you can do on c except calling .item on it ?
>
> One thing you can do is query the `index' in the current iteration. It was debated over and we felt that providing the cursor rather than the item was much more powerful with little loss in the simplicity.
>
> Regards,
> Manu
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Bertrand Meyer]

We do not have a tutorial document yet, so misunderstandings are inevitable.

> I was surprised anyway. Eiffel always prided itself for having only one
> good way of doing things - now we are getting a second loop construct.
> What's next?

There is no new construct, only a small extension of the existing loop construct, which remains the only loop mechanism in Eiffel. The extension follows the long-standing Eiffel tradition of providing shortcuts for common cases, with the new variants defined in terms of the basic ones. The basic idea is simple: you may abbreviate the common pattern

[1] from
                l.start
        until
                l.after
        loop
                some_action (l.item)
                l.forth
        end

as

[2] across l as ll do some_action (ll.item) end

The mechanism also offers `some' and `all' forms, useful in particular for contracts, as in

[3] across l as ll all ll.item > 0 end
               

The language definition introduces [2] explicitly as an abbreviation for [1], and similarly for [3], so there is nothing really new. The invariant clause can and should still be there. The variant can also be included, as well as the `until' clause if the iteration must stop before the end of the structure. The `from' clause too can appear, if an explicit initialization is required. So it's the good old Eiffel loop construct as we have always had it, with a simplified form covering the common case of iterating on a linearizable data structure (the type of `l', e.g. a list type, must be based on a descendant of the library class ITERABLE).

There will remain "one good way" to do loops. For standard cases of data structure iteration,  [2] and [3] are more concise and avoid the risk of forgetting the call to `forth'. [1] will remain useful for sophisticated cases in which the programmer needs finer control, for non-data-structure-related loops, and possibly to teach beginners what [2] means. In addition, the new versions carry, in the current implementation, a performance penalty, causing some programmers to retain the original form in time-critical loops for the time being.


To avoid perpetuating the misunderstandings, I have made available temporarily at

        http://se.ethz.ch/~meyer/down/temp-loop/iterloop.html

a copy of the ECMA TC49-TG4 committee's working document. Caveats:

        - This is not a tutorial but a technical specification in
          the style that we are using for language evolution proposals
          within the committee. It is not designed to be easy to
          understand by newcomers; you need to know the existing
          standard well, and probably to read the new document
          twice anyway. Still, reading sections 1 and 2 will give
          you a good idea of what this is about.

        - The mechanism is in EiffelStudio 6.5 but experimentally,
          and you will not be able to use it effectively until
          EiffelBase has been adapted (to make iterable classes
          such as LIST and HASH_TABLE inherit from the new
          library class ITERABLE, making examples such as the
          above and those in section 2 of the document valid).
          The updated, experimental EiffelBase will be released
          in a few weeks.

A tutorial will be provided.

The mechanism is an incremental extension to an existing construct; my expectation, if the experiment succeeds, is that in a few months Eiffel programmers will be using it extensively.

-- BM

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jann Röder
> Sent: 15 November, 2009 12:39
> To: [hidden email]
> Subject: Re: [eiffel_software] Re: New loop construct
>
>
>
> Sure it is more powerful, but this whole thing being a shortcut, I
> would
> assume its main purpose is to be short for probably 95% of its uses.
>
> I was surprised anyway. Eiffel always prided itself for having only one
> good way of doing things - now we are getting a second loop construct.
> What's next?
>
> Since the decision has already been made it is pointless to start a
> discussion, I'm just a bit confused.
>
> Jann
>
> Am 14.11.09 00:26, schrieb Emmanuel Stapf [ES]:
> >> In across container as c loop ... end,
> >> why do you always have to use c.item instead of just c? Is there
> >> anything else you can do on c except calling .item on it ?
> >
> > One thing you can do is query the `index' in the current iteration.
> It was debated over and we felt that providing the cursor rather than
> the item was much more powerful with little loss in the simplicity.
> >
> > Regards,
> > Manu
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>
>

[Martin Piskernig]

First, Bertrand, let me thank you for your very helpful explanations!

Am Sonntag, 15. November 2009 14:36:49 schrieb Bertrand Meyer:
> There is no new construct, only a small extension of the existing loop
>  construct, which remains the only loop mechanism in Eiffel.

But, then, Isn't every loop construct in every (practical) programming
language just an extended/limited variant of each other possible loop
construct?

In Java it is of course possible to express every expressable loop with a
"while", "do-while" and "for" loop, it is usually only a bit more awkward with
one construct or the other. But it is IMHO not common sense to view a "for"
loop just as a small extension of the "while" loop (or the other way round,
whatever you like better) even if it is possible to trivially translate every
"for" loop into an equivalent "while" loop.

I think Bertrand's sentence from above would have also been true for Eiffel's
"if-then" and "inspect-when" constructs when you exchange the word "loop" with
"branching":
"There is no new construct, only a small extension of the existing branching
construct, which remains the only branching mechanism in Eiffel. "

Some operators fall into the same category: If there were "only one way of
doing it" there wouldn't be assigners and the [] alias in Eiffel. There are
many more examples (e.g. external routines, which can be given by a signature
or by explicit inline code, ...).

Don't understand me wrong: I _really_ appreciate having and using these
constructs; it's just that the "only one way of doing something in Eiffel"
principle maybe was true once but is not any more since a long time.

Regards,
Martin


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Jonathan S. Ostroff]

If I do

        expanded class B [G ->{NUMERIC, COMPARABLE} create default_create
end]
        inherit {NONE}
                A[G]
        create
                default_create,
                make ... etc

I get

> Error code: VTGC(3)
>
> Error: Every feature name listed in the creators part of
>   the constraint must occur in exactly one constraining
>   class.
> What to do: Use renaming if there are several candidates
>   or make sure that the creation constraint feature really
>   exists.

NUMERIC and COMPARABLE both inherit from ANY, therefore they have a
default_create. The VTGC error code in ECMA says "one of the constraining
types must have the feature" from which I infer that the above code should
compile error free. Are ECMA and ES in conflict because the ES error says
"exactly one".

If we write

  class CG[G -> {CONSTRAINT1,CONSTRAINT2} create make_xxx end] ... end

we are stating that the actual generic parameter must conform to CONSTRAINT1
and CONSTRAINT and must have a feature make_xxx which is available for
creation.

Thanks

Jonathan

[Jonathan S. Ostroff]

I am finding that the runtime catcall detection produces hundreds of what I
believe are spurious warnings in the console.

In the ECF file I have something like:

        <cluster name="X" location" recursive="true">
                        <option cat_call_detection="false"
is_attached_by_default="true" void_safety="all" syntax="standard">
                        </option>


Catcalls can be disabled in the debugger, but I would like to do this for
the console as well. The above declaration does not do this. Is there a way
to prevent catcall reports to the console?

Also, what is the status of catcall detection? For example, bug report
Compiler #15937 (IIRC) provides some examples of what may be spurious
catcalls. Should I be submitting bug reports very time I see these?

Thanks

Jonathan

[Colin LeMahieu]

If you go in to Debugger -> Exceptions there are two check boxes on the top
for Catcall notifications.  Do these help?

On Sun, Nov 15, 2009 at 3:32 PM, Jonathan S. Ostroff <[hidden email]>wrote:

>
>
> I am finding that the runtime catcall detection produces hundreds of what I
> believe are spurious warnings in the console.
>
> In the ECF file I have something like:
>
> <cluster name="X" location" recursive="true">
> <option cat_call_detection="false"
> is_attached_by_default="true" void_safety="all" syntax="standard">
> </option>
>
> Catcalls can be disabled in the debugger, but I would like to do this for
> the console as well. The above declaration does not do this. Is there a way
> to prevent catcall reports to the console?
>
> Also, what is the status of catcall detection? For example, bug report
> Compiler #15937 (IIRC) provides some examples of what may be spurious
> catcalls. Should I be submitting bug reports very time I see these?
>
> Thanks
>
> Jonathan
>
>  
>

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Jonathan S. Ostroff]

Colin:

The debugger check box works but not the console check box.

That did get me thinking though, and I realized that I had not declared it
as a console application. However, when I did that, ES crashed on the
compile (submitted as bug: [EiffelStudio #16445] Feature call on void
target).

I am still left wondering what option cat_call_detection="false" does?


There is no end to the catcall warnings in my app -- I have run it for 15
minutes and it still generates (what I think are spurious) catcalls, never
getting to the point of actually executing code.

Jonathan

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Colin LeMahieu
Sent: Sunday, November 15, 2009 7:46 PM
To: [hidden email]
Subject: Re: [eiffel_software] ES6.5: How to stop catcall detection:
cat_call_detection="false"

If you go in to Debugger -> Exceptions there are two check boxes on the top
for Catcall notifications.  Do these help?

On Sun, Nov 15, 2009 at 3:32 PM, Jonathan S. Ostroff
<[hidden email]>wrote:

>
>
> I am finding that the runtime catcall detection produces hundreds of what
I

> believe are spurious warnings in the console.
>
> In the ECF file I have something like:
>
> <cluster name="X" location" recursive="true">
> <option cat_call_detection="false"
> is_attached_by_default="true" void_safety="all" syntax="standard">
> </option>
>
> Catcalls can be disabled in the debugger, but I would like to do this for
> the console as well. The above declaration does not do this. Is there a

way

> to prevent catcall reports to the console?
>
> Also, what is the status of catcall detection? For example, bug report
> Compiler #15937 (IIRC) provides some examples of what may be spurious
> catcalls. Should I be submitting bug reports very time I see these?
>
> Thanks
>
> Jonathan
>
>  
>

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

[Jonathan S. Ostroff]

An update to the email below. I made a few changes/workarounds to avoid the
compiler crash mentioned below. There is now a declaration

        <setting name="console_application" value="true"/>

And the "disable catcall console warning" is ticked.

I am still getting many spurious catcall detected warnings on the console.
Version = EiffelStudio 6 (6.5.8.1483 GPL Edition - windows)

Jonathan

====================

Colin:

The debugger check box works but not the console check box.

That did get me thinking though, and I realized that I had not declared it
as a console application. However, when I did that, ES crashed on the
compile (submitted as bug: [EiffelStudio #16445] Feature call on void
target).

I am still left wondering what option cat_call_detection="false" does?


There is no end to the catcall warnings in my app -- I have run it for 15
minutes and it still generates (what I think are spurious) catcalls, never
getting to the point of actually executing code.

Jonathan

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Colin LeMahieu
Sent: Sunday, November 15, 2009 7:46 PM
To: [hidden email]
Subject: Re: [eiffel_software] ES6.5: How to stop catcall detection:
cat_call_detection="false"

If you go in to Debugger -> Exceptions there are two check boxes on the top
for Catcall notifications.  Do these help?

On Sun, Nov 15, 2009 at 3:32 PM, Jonathan S. Ostroff
<[hidden email]>wrote:

>
>
> I am finding that the runtime catcall detection produces hundreds of what
I

> believe are spurious warnings in the console.
>
> In the ECF file I have something like:
>
> <cluster name="X" location" recursive="true">
> <option cat_call_detection="false"
> is_attached_by_default="true" void_safety="all" syntax="standard">
> </option>
>
> Catcalls can be disabled in the debugger, but I would like to do this for
> the console as well. The above declaration does not do this. Is there a

way

> to prevent catcall reports to the console?
>
> Also, what is the status of catcall detection? For example, bug report
> Compiler #15937 (IIRC) provides some examples of what may be spurious
> catcalls. Should I be submitting bug reports very time I see these?
>
> Thanks
>
> Jonathan
>
>  
>

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links






------------------------------------

Yahoo! Groups Links

[Peter Gummer-2]

Bertrand Meyer wrote:

> To avoid perpetuating the misunderstandings, I have made available  
> temporarily at
>
> http://se.ethz.ch/~meyer/down/temp-loop/iterloop.html
>
> a copy of the ECMA TC49-TG4 committee's working document.


Thanks for posting this. It looks great.

There's an error in 3.5.2.2 and 3.5.2.2.2, which mention "Some_body".  
It should be "All_body".

- Peter Gummer

[fivaarno]

I agree, the new loop construct will be very useful and it is really just an extension of the loop construct. But why not take it a step further and generalize it even more?

The new loop constructs has two purposes, one is iterating over all elements to perform some actions with/on them. The other purpose is to return some status of the list in form of a "for all" or "there exists" query, which is definitely nicer than passing agents to "for_all" and "there_exists" routines provided by most linear data structures in the base library.

The construct could be extended to return an arbitrary type, not only BOOLEAN. Provided there is a notion of a Result returned by the loop, the sum example in the ECMA document could be rewritten as

across
       my_integer_list
as
       c
loop
       Result := Result + c.item
end

The initial start value Result := 0 is not necessary, since the default value of INTEGER is 0. In fact, the only requirement for the return type of the loop is that it has a default value, which is inline with the latest void-safety mechanisms. For non expanded types this means that the return type of the loop must be detachable (an exception could be the case where you initialize the Result in the "from" clause). In the case of empty lists, the construct will simply return the default value. Note that the current "across ... all ... end" and "across ... some ... end" are special cases of this.

Of course the idea is taken from functional programming languages, where some recursive computations on list elements can be written very simple. Now the goal of this is not to start porting functional programming constructs into Eiffel just to write things in an even shorter manner. The main advantage is having more expressiveness in contracts. For example using the above sum computation in a contract becomes very simple:

sum_is_equal_to_value: value == across my_integer_list as c loop Result := Result + c.item end

Note that once you have keyword highlighting the above becomes readable again :-) So far the simplest way to do something similar is using inline agents, which sometimes makes the contracts have more lines of code than the routine implementation itself.

Any thoughts on this?


Regards,
Arno Fiva




--- In [hidden email], Martin Piskernig <martin.piskernig@...> wrote:

>
> Hi!
>
> For release "6.5.8.1483 (Release Candidate)" on dev.eiffel.com there is a note:
> "compiler: New loop constructs implementation per a draft specification of the
> next ECMA standard.". I think this is it what Bertrand announced some months
> ago when I asked about a "for each" loop in Eiffel but he apparently haven't
> had time yet to post about it in his blog. Is there any other documentation on
> the new loop construct?
>
> Kind regards,
> Martin
>

[dlebansais]

--- In [hidden email], "fivaarno" <arnofiva@...> wrote:

>
>
> I agree, the new loop construct will be very useful and it is really just an extension of the loop construct. But why not take it a step further and generalize it even more?
>
> The new loop constructs has two purposes, one is iterating over all elements to perform some actions with/on them. The other purpose is to return some status of the list in form of a "for all" or "there exists" query, which is definitely nicer than passing agents to "for_all" and "there_exists" routines provided by most linear data structures in the base library.
>
> The construct could be extended to return an arbitrary type, not only BOOLEAN. Provided there is a notion of a Result returned by the loop, the sum example in the ECMA document could be rewritten as
>
> across
>        my_integer_list
> as
>        c
> loop
>        Result := Result + c.item
> end
>
> The initial start value Result := 0 is not necessary, since the default value of INTEGER is 0. In fact, the only requirement for the return type of the loop is that it has a default value, which is inline with the latest void-safety mechanisms. For non expanded types this means that the return type of the loop must be detachable (an exception could be the case where you initialize the Result in the "from" clause). In the case of empty lists, the construct will simply return the default value. Note that the current "across ... all ... end" and "across ... some ... end" are special cases of this.
>
> Of course the idea is taken from functional programming languages, where some recursive computations on list elements can be written very simple. Now the goal of this is not to start porting functional programming constructs into Eiffel just to write things in an even shorter manner. The main advantage is having more expressiveness in contracts. For example using the above sum computation in a contract becomes very simple:
>
> sum_is_equal_to_value: value == across my_integer_list as c loop Result := Result + c.item end
>
> Note that once you have keyword highlighting the above becomes readable again :-) So far the simplest way to do something similar is using inline agents, which sometimes makes the contracts have more lines of code than the routine implementation itself.
>
> Any thoughts on this?
>
>
> Regards,
> Arno Fiva
>

If I get it right, you're using 'Result' to hold the result of the 'across...end' expression, right? Isn't it conflicting with Result as the result of a query?

Regards,
David.

[fivaarno]

That's correct, Result plays an ambiguous role in the above example. I also left away any type declaration for Result which is probably needed (maybe not, as it is missing for the "all" and "some" cases too). Object test doesn't need a type declaration either, however with regard to readability I think having a type declaration doesn't hurt.
The above suggestion is not ready to use yet. I just wanted to point out that since the current construct already returns BOOLEAN values, there shouldn't be a reason it can't return arbitrary values. The benefit, especially for writing contracts, would definitely be worth looking into it.



--- In [hidden email], "David" <dlebansais@...> wrote:

>
> --- In [hidden email], "fivaarno" <arnofiva@> wrote:
> >
> >
> > I agree, the new loop construct will be very useful and it is really just an extension of the loop construct. But why not take it a step further and generalize it even more?
> >
> > The new loop constructs has two purposes, one is iterating over all elements to perform some actions with/on them. The other purpose is to return some status of the list in form of a "for all" or "there exists" query, which is definitely nicer than passing agents to "for_all" and "there_exists" routines provided by most linear data structures in the base library.
> >
> > The construct could be extended to return an arbitrary type, not only BOOLEAN. Provided there is a notion of a Result returned by the loop, the sum example in the ECMA document could be rewritten as
> >
> > across
> >        my_integer_list
> > as
> >        c
> > loop
> >        Result := Result + c.item
> > end
> >
> > The initial start value Result := 0 is not necessary, since the default value of INTEGER is 0. In fact, the only requirement for the return type of the loop is that it has a default value, which is inline with the latest void-safety mechanisms. For non expanded types this means that the return type of the loop must be detachable (an exception could be the case where you initialize the Result in the "from" clause). In the case of empty lists, the construct will simply return the default value. Note that the current "across ... all ... end" and "across ... some ... end" are special cases of this.
> >
> > Of course the idea is taken from functional programming languages, where some recursive computations on list elements can be written very simple. Now the goal of this is not to start porting functional programming constructs into Eiffel just to write things in an even shorter manner. The main advantage is having more expressiveness in contracts. For example using the above sum computation in a contract becomes very simple:
> >
> > sum_is_equal_to_value: value == across my_integer_list as c loop Result := Result + c.item end
> >
> > Note that once you have keyword highlighting the above becomes readable again :-) So far the simplest way to do something similar is using inline agents, which sometimes makes the contracts have more lines of code than the routine implementation itself.
> >
> > Any thoughts on this?
> >
> >
> > Regards,
> > Arno Fiva
> >
>
> If I get it right, you're using 'Result' to hold the result of the 'across...end' expression, right? Isn't it conflicting with Result as the result of a query?
>
> Regards,
> David.
>