Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #74685 > unrolled thread

CAlive to introduce flowofs

Back to article view | Back to comp.lang.c

Contents

  CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 11:20 -0800
    Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 11:27 -0800
      Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 11:34 -0800
    Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 11:57 -0800
    Re: CAlive to introduce flowofs supercat@casperkitty.com - 2015-11-02 12:18 -0800
      Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 12:24 -0800
        Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 12:48 -0800
      Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 12:40 -0800
    Re: CAlive to introduce flowofs Bartc <bc@freeuk.com> - 2015-11-02 21:08 +0000
      Re: CAlive to introduce flowofs Ian Collins <ian-news@hotmail.com> - 2015-11-03 10:13 +1300
        Re: CAlive to introduce flowofs Bartc <bc@freeuk.com> - 2015-11-02 21:14 +0000
          Re: CAlive to introduce flowofs Ian Collins <ian-news@hotmail.com> - 2015-11-03 10:31 +1300
            Re: CAlive to introduce flowofs Bartc <bc@freeuk.com> - 2015-11-02 21:48 +0000
              Re: CAlive to introduce flowofs Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:20 +1300
                Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 14:33 -0800
                  Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 15:03 -0800
                  Re: CAlive to introduce flowofs Ian Collins <ian-news@hotmail.com> - 2015-11-03 12:05 +1300
                    Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 15:08 -0800
                      Re: CAlive to introduce flowofs supercat@casperkitty.com - 2015-11-02 16:44 -0800
                        Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 17:20 -0800
                          Re: CAlive to introduce flowofs Ian Collins <ian-news@hotmail.com> - 2015-11-03 17:06 +1300
                            Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 20:13 -0800
                Re: CAlive to introduce flowofs Bartc <bc@freeuk.com> - 2015-11-03 12:43 +0000
                  Re: CAlive to introduce flowofs David Brown <david.brown@hesbynett.no> - 2015-11-03 14:20 +0100
                  Re: CAlive to introduce flowofs Ian Collins <ian-news@hotmail.com> - 2015-11-04 08:57 +1300
        Re: CAlive to introduce flowofs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 14:31 -0800

Page 1 of 2  [1] 2  Next page →

#74685 — CAlive to introduce flowofs

Note:  The flowof is pronounced "flow of" (like "there's a flow of water"),
       with flowofs simply being the plural form.

-----
A flowof is a new way to simplify source code and extract details from a
code block, replacing the code that's extracted with a token name that
relates verbally to its purpose, and is the name of the flowof.  The code
is then put back into the body of a flowof definition where it inherits
the full source code context and environment wherein it's referenced.

Here's a fabricated example:

    int my_function(int count, int value)
    {
        if (count < 5)
        {
            if (value < 50)
            {
                // Code here to process <5x < 50
            } else if (value < 100) {
                // Code here to process <5x < 100
            } else if (value < 500) {
                // Code here to process <5x < 500
            } else {
                // Code here to process <5x >= 500
            }

       } else if (count < 10) {
            if (value < 50)
            {
                // Code here to process <10x < 50
            } else if (value < 100) {
                // Code here to process <10x < 100
            } else if (value < 500) {
                // Code here to process <10x < 500
            } else {
                // Code here to process <10x >= 500
            }

       } else {
            if (value < 50)
            {
                // Code here to process >=10x < 50
            } else if (value < 100) {
                // Code here to process >=10x < 100
            } else if (value < 500) {
                // Code here to process >=10x < 500
            } else {
                // Code here to process >=10x >= 500
            }
       }
    }

This type of code block can be pretty long.  It's a little difficult
to wield especially if there is non-trivial code in each of the
"// Code here" portions.

You could call functions to handle each one and break them out that
way.  And that's probably fine.  It may consume some processing time
to fill and spill the stack for the function calls, but most modern
optimizing compilers will probably automatically do for you what I'm
about to demonstrate through the flowof, but by using flowofs you'll
be able to see how you (the developer) can do this not only in the
binary, but also in source code.

Consider a refactoring where the details of each handler is moved
away to another place, yet without function calls.  It uses a
similar syntax to the class::member_function syntax, but in this
case it relates explicitly to identifying which function the
flowof relates to, as these can appear at any location in the
source code:

    int my_function(int count, int value)
    {
        if (count < 5)         five_count;
        else if (count < 10)   ten_count;
        else                   greater_than_ten_count;
    }

    flowof my_function::five_count
    {
        if (value < 50)
        {
            // Code here to process <5x < 50
        } else if (value < 100) {
            // Code here to process <5x < 100
        } else if (value < 500) {
            // Code here to process <5x < 500
        } else {
            // Code here to process <5x >= 500
        }
    }

    flowof my_function::ten_count
    {
        if (value < 50)
        {
            // Code here to process <10x < 50
        } else if (value < 100) {
            // Code here to process <10x < 100
        } else if (value < 500) {
            // Code here to process <10x < 500
        } else {
            // Code here to process <10x >= 500
        }
    }

    flowof my_function::greater_than_ten_count
    {
        if (value < 50)
        {
            // Code here to process >=10x < 50
        } else if (value < 100) {
            // Code here to process >=10x < 100
        } else if (value < 500) {
            // Code here to process >=10x < 500
        } else {
            // Code here to process >=10x >= 500
        }
    }

In this example, the code is extracted from its more-indented portion
in the original my_function(), and pulled into a more left-justified
block, each of which is now manageable singularly.

Each flowof receives the full context, meaning the values passed as
parameters (count and value) are available, as are any local variables
that may have been defined in my_function().  In addition, the flowof
can receive its own parameters (not shown here),  and also have its
own local variables (also not shown here).

No return value is required because it's basically a continued flow
from the original location in my_function.  It uses the { } body with
the { and } characters to mark off itself, so that it is fully
enclosed as in the above example, yet without requiring additional or
separate { } around the flowof names.

-----
Flowofs allow complex code to be removed from its original location,
yet provides a context by which the GUI editor can re-introduce the
code exactly where it goes when it's needed to be edited in context.
Then after it's edited in context, it is moved back out to the flowofs
automatically, allowing for easier understanding with regards to long-
term maintenance (people operate in ways which relate to concepts, and
not the mechanical details of implementation).

The flowof is one part of the new "flow" features which exist in
CAlive.  The other is a flow { } block which performs the same
operation as above, but does so within the single function, thereby
providing a better form for shorter blocks of code.

The flow { } block will be demonstrated sometime soon (Lord willing).

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#74688

On Monday, November 2, 2015 at 2:20:47 PM UTC-5, Rick C. Hodgin wrote:
> Note:  The flowof is pronounced "flow of" (like "there's a flow of water"),
>        with flowofs simply being the plural form.
> 
> -----
> A flowof is a new way to simplify source code and extract details from a
> code block, replacing the code that's extracted with a token name that
> relates verbally to its purpose, and is the name of the flowof.  The code
> is then put back into the body of a flowof definition where it inherits
> the full source code context and environment wherein it's referenced.
> 
> Here's a fabricated example:
> 
>     int my_function(int count, int value)
>     {
>         if (count < 5)
>         {
>             if (value < 50)
>             {
>                 // Code here to process <5x < 50
>             } else if (value < 100) {
>                 // Code here to process <5x < 100
>             } else if (value < 500) {
>                 // Code here to process <5x < 500
>             } else {
>                 // Code here to process <5x >= 500
>             }
> 
>        } else if (count < 10) {
>             if (value < 50)
>             {
>                 // Code here to process <10x < 50
>             } else if (value < 100) {
>                 // Code here to process <10x < 100
>             } else if (value < 500) {
>                 // Code here to process <10x < 500
>             } else {
>                 // Code here to process <10x >= 500
>             }
> 
>        } else {
>             if (value < 50)
>             {
>                 // Code here to process >=10x < 50
>             } else if (value < 100) {
>                 // Code here to process >=10x < 100
>             } else if (value < 500) {
>                 // Code here to process >=10x < 500
>             } else {
>                 // Code here to process >=10x >= 500
>             }
>        }
>     }
> 
> This type of code block can be pretty long.  It's a little difficult
> to wield especially if there is non-trivial code in each of the
> "// Code here" portions.
> 
> You could call functions to handle each one and break them out that
> way.  And that's probably fine.  It may consume some processing time
> to fill and spill the stack for the function calls, but most modern
> optimizing compilers will probably automatically do for you what I'm
> about to demonstrate through the flowof, but by using flowofs you'll
> be able to see how you (the developer) can do this not only in the
> binary, but also in source code.
> 
> Consider a refactoring where the details of each handler is moved
> away to another place, yet without function calls.  It uses a
> similar syntax to the class::member_function syntax, but in this
> case it relates explicitly to identifying which function the
> flowof relates to, as these can appear at any location in the
> source code:
> 
>     int my_function(int count, int value)
>     {
>         if (count < 5)         five_count;
>         else if (count < 10)   ten_count;
>         else                   greater_than_ten_count;
>     }
> 
>     flowof my_function::five_count
>     {
>         if (value < 50)
>         {
>             // Code here to process <5x < 50
>         } else if (value < 100) {
>             // Code here to process <5x < 100
>         } else if (value < 500) {
>             // Code here to process <5x < 500
>         } else {
>             // Code here to process <5x >= 500
>         }
>     }
> 
>     flowof my_function::ten_count
>     {
>         if (value < 50)
>         {
>             // Code here to process <10x < 50
>         } else if (value < 100) {
>             // Code here to process <10x < 100
>         } else if (value < 500) {
>             // Code here to process <10x < 500
>         } else {
>             // Code here to process <10x >= 500
>         }
>     }
> 
>     flowof my_function::greater_than_ten_count
>     {
>         if (value < 50)
>         {
>             // Code here to process >=10x < 50
>         } else if (value < 100) {
>             // Code here to process >=10x < 100
>         } else if (value < 500) {
>             // Code here to process >=10x < 500
>         } else {
>             // Code here to process >=10x >= 500
>         }
>     }
> 
> In this example, the code is extracted from its more-indented portion
> in the original my_function(), and pulled into a more left-justified
> block, each of which is now manageable singularly.
> 
> Each flowof receives the full context, meaning the values passed as
> parameters (count and value) are available, as are any local variables
> that may have been defined in my_function().  In addition, the flowof
> can receive its own parameters (not shown here),  and also have its
> own local variables (also not shown here).
> 
> No return value is required because it's basically a continued flow
> from the original location in my_function.  It uses the { } body with
> the { and } characters to mark off itself, so that it is fully
> enclosed as in the above example, yet without requiring additional or
> separate { } around the flowof names.
> 
> -----
> Flowofs allow complex code to be removed from its original location,
> yet provides a context by which the GUI editor can re-introduce the
> code exactly where it goes when it's needed to be edited in context.
> Then after it's edited in context, it is moved back out to the flowofs
> automatically, allowing for easier understanding with regards to long-
> term maintenance (people operate in ways which relate to concepts, and
> not the mechanical details of implementation).
> 
> The flowof is one part of the new "flow" features which exist in
> CAlive.  The other is a flow { } block which performs the same
> operation as above, but does so within the single function, thereby
> providing a better form for shorter blocks of code.
> 
> The flow { } block will be demonstrated sometime soon (Lord willing).
> 
> Best regards,
> Rick C. Hodgin

In the case where non-mated { and } are pulled out, which may be useful
at times, you can use the double-{{ and double-}} for marking off blocks:

Another fabricated example:

    int my_function(int count)
    {
        five_count;
        ten_count;
        greater_than_ten_count;
    }
    }

    flowof my_function::five_count
    {{
        if (count < 5)
        {
            // Code to handle <5 goes here
    }}

    flowof my_function::ten_count
    {{
        } else if (count < 10) {
            // Code to handle <10 goes here
    }}

    flowof my_function::greater_than_count
    {{
        } else {
            // Code to handle >= 10 goes here
        }
    }}

Here we see un-matched { and } blocks within each flowof.  These do not
cause a syntax error, but are allowed because the context whereby each
flowof is compiled is where its name token is in the original function,
and when these code blocks are re-assembled at that location, everything
is correct.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74690

On Monday, November 2, 2015 at 2:28:13 PM UTC-5, Rick C. Hodgin wrote:
>     int my_function(int count)
>     {
>         five_count;
>         ten_count;
>         greater_than_ten_count;
>     }
>     }

The second } here is a typo.  It should not be there.  The code should
look like this:

    int my_function(int count)
    {
        five_count;
        ten_count;
        greater_than_ten_count;
    }

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74691

On Monday, November 2, 2015 at 2:20:47 PM UTC-5, Rick C. Hodgin wrote:
>     flowof my_function::greater_than_ten_count
>     {
>         if (value < 50)
>         {
>             // Code here to process >=10x < 50
>         } else if (value < 100) {
>             // Code here to process >=10x < 100
>         } else if (value < 500) {
>             // Code here to process >=10x < 500
>         } else {
>             // Code here to process >=10x >= 500
>         }
>     }

Flowofs can also have flowof blocks, simply increase the scope definition:

    flowof my_function::greater_than_ten_count
    {
        less_than_50;
        less_than_100;
        less_than_500;
        greater_than_500;
    }

    flowof my_function::greater_than_ten_count:less_than_50
    {{
        if (value < 50)
        {
            // Code here to process >=10x < 50
    }}

    flowof my_function::greater_than_ten_count:less_than_100
    {{
        } else if (value < 100) {
            // Code here to process >=10x < 100
    }}

    flowof my_function::greater_than_ten_count:less_than_500
    {{
        } else if (value < 500) {
            // Code here to process >=10x < 500
    }}

    flowof my_function::greater_than_ten_count:greater_than_500
    {{
        } else {
            // Code here to process >=10x >= 500
        }
    }}

In addition, the keyword flowof is made available, and is optional,
but can be used to document what's happening in code a little more
clearly, so a follow-on maintainer knows that the "less_than_50"
token is a flowof, and not a macro, for example:

    flowof my_function::greater_than_ten_count
    {
        flowof less_than_50;
        flowof less_than_100;
        flowof less_than_500;
        flowof greater_than_500;
    }

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74693

I see two things at work here: the ability to access the parent-function's variables in the way that Pascal allows with nested functions, and the ability
to criss-cross control structures in weird ways.  While I could see usefulness
 for being able to use "goto" to branch from a nested function out to the main
 one, or else return directly from the main one, I'm not sure I see a good
argument for having something that looks like a function call unbalance braces
in the apparent caller.  If the issue is that control constructs are sometimes
inadequate to accommodate needs, perhaps you could focus on those, though I'd
suggest that a lot of inadequacies in C's control structures can be overcome
via willingness to use "goto" when appropriate [e.g. if one has a control tree
with many more branches than possible actions, it may be better to have
every branch perform a "goto" to the appropriate code than to kludge together
more complicated code to accomplish the same thing.

[toc] | [prev] | [next] | [standalone]

#74694

On Monday, November 2, 2015 at 3:18:31 PM UTC-5, supe...@casperkitty.com wrote:
> I see two things at work here: the ability to access the parent-function's variables in the way that Pascal allows with nested functions, and the ability
> to criss-cross control structures in weird ways.  While I could see usefulness
>  for being able to use "goto" to branch from a nested function out to the main
>  one, or else return directly from the main one, I'm not sure I see a good
> argument for having something that looks like a function call unbalance braces
> in the apparent caller.  If the issue is that control constructs are sometimes
> inadequate to accommodate needs, perhaps you could focus on those, though I'd
> suggest that a lot of inadequacies in C's control structures can be overcome
> via willingness to use "goto" when appropriate [e.g. if one has a control tree
> with many more branches than possible actions, it may be better to have
> every branch perform a "goto" to the appropriate code than to kludge together
> more complicated code to accomplish the same thing.

The flow { } blocks are more what you're talking about here.  If you
go to Google Groups and search the comp.lang.c group for flow { }
blocks, you'll probably find a discussion from 2014 or thereabouts.

I've described them before.  They're basically what you see here, but
are in a the original function, and instead of being flowofs, they are
flows.

You can also see it documented already in my book somewhere (search
for "flow":

    https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc.odt

I'll try to post about flow { } blocks later this evening.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74697

On Monday, November 2, 2015 at 3:24:28 PM UTC-5, Rick C. Hodgin wrote:
> The flow { } blocks are more what you're talking about here.  If you
> go to Google Groups and search the comp.lang.c group for flow { }
> blocks, you'll probably find a discussion from 2014 or thereabouts.

Here's the starting link (I think this is the first one):

    https://groups.google.com/d/msg/comp.lang.c/267zbRSwpLg/DOJ77ZHwU4QJ

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74696

On Monday, November 2, 2015 at 3:18:31 PM UTC-5, supe...@casperkitty.com wrote:
> I see two things at work here: the ability to access the parent-function's variables in the way that Pascal allows with nested functions, and the ability
> to criss-cross control structures in weird ways.  While I could see usefulness
>  for being able to use "goto" to branch from a nested function out to the main
>  one, or else return directly from the main one, I'm not sure I see a good
> argument for having something that looks like a function call unbalance braces
> in the apparent caller.  If the issue is that control constructs are sometimes
> inadequate to accommodate needs, perhaps you could focus on those, though I'd
> suggest that a lot of inadequacies in C's control structures can be overcome
> via willingness to use "goto" when appropriate [e.g. if one has a control tree
> with many more branches than possible actions, it may be better to have
> every branch perform a "goto" to the appropriate code than to kludge together
> more complicated code to accomplish the same thing.

To be clear, flow { } blocks were created to give unstructured programming
techniques, like the use of goto's, some structure.  Their other primary
goal was to pull nested logic out of it's deeply indented location, and
make it less indented for reading.

The abilities of the GUI editor allow it to all be re-introduced in a
linear top-down form for maintenance without it being broken out into
flows (or flowofs).  But the re-integration of them into flows and
flowofs allow for the code to be more easily understood at a high level
for follow-on long-term maintenance.

Remember, CAlive has, by definition, a tight coupling to a GUI editor.
It is expected that some of the things which appear obtuse in source
code will be rendered properly in the editor, thereby encouraging use
of that tool and environment.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74699

On 02/11/2015 19:20, Rick C. Hodgin wrote:
> Note:  The flowof is pronounced "flow of" (like "there's a flow of water"),
>         with flowofs simply being the plural form.

> Consider a refactoring where the details of each handler is moved
> away to another place, yet without function calls.  It uses a
> similar syntax to the class::member_function syntax, but in this
> case it relates explicitly to identifying which function the
> flowof relates to, as these can appear at any location in the
> source code:
>
>      int my_function(int count, int value)
>      {
>          if (count < 5)         five_count;
>          else if (count < 10)   ten_count;
>          else                   greater_than_ten_count;
>      }
>
>      flowof my_function::five_count
>      {
>          if (value < 50)
>          {
>              // Code here to process <5x < 50
>          } else if (value < 100) {
>              // Code here to process <5x < 100
>          } else if (value < 500) {
>              // Code here to process <5x < 500
>          } else {
>              // Code here to process <5x >= 500
>          }
>      }
>
>      flowof my_function::ten_count
>      {
>          if (value < 50)
>          {
>              // Code here to process <10x < 50
>          } else if (value < 100) {
>              // Code here to process <10x < 100
>          } else if (value < 500) {
>              // Code here to process <10x < 500
>          } else {
>              // Code here to process <10x >= 500
>          }
>      }
....

This is one of your ideas that I like, and have implemented my own 
version. This is not in C, but in C terms, these 'flow blocks' work like 
this:

* Any compound statement can be named in a special way, then it becomes 
a flow block:

    {name::
       a=10;
       b=20;
    }

* Any statement can 'call' a flow block like this:

    @name;

   This passes control to the block named 'name', and at the end of the 
block, control passes back here.

* All flow blocks must be defined within the same function.

* Flow blocks can exist anywhere in the function. To prevent execution 
in normal flow of code, a special keyword is used:

    blockdef {name::
       a=10;
       b=20;
    }

  Then normal flow will just jump across such blocks.

I implemented it to be able to easily share common code within a function.

Your example, again with the above syntax superimposed on normal C, 
would be:

void myfunc(int count, int value) {

     if (count<5)
         @fivecount;
     else if (count<10)
         @tencount;
     else
         @greaterthantencount;

     blockdef {fivecount::
         printf("Five count: %d\n",value);
     }
     blockdef {tencount::
         printf("Ten count: %d\n",value);
     }
     blockdef {greaterthantencount::
         printf("Greater than Ten count: %d\n",value);
     }

}

(I implement this, when the original source is converted to C, via gcc's 
label pointers. The code is messy. There are some restrictions, such not 
jumping in or out of such a block, and no recursive invocations of named 
blocks.

I've used the feature in a couple of places, but I feel it's a little 
unsatisfactory because it's not that much higher level than a 'goto', 
and more on a par with Basic's 'gosub'.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#74700

Bartc wrote:
> On 02/11/2015 19:20, Rick C. Hodgin wrote:
>> Note:  The flowof is pronounced "flow of" (like "there's a flow of water"),
>>          with flowofs simply being the plural form.

My initial reading was "blow offs", but I'm still a schoolboy at heart..

<snip>
>
> This is one of your ideas that I like, and have implemented my own
> version.

It is also one which (as discussed last year) already available in C++ :)

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#74701

On 02/11/2015 21:13, Ian Collins wrote:
> Bartc wrote:
>> On 02/11/2015 19:20, Rick C. Hodgin wrote:
>>> Note:  The flowof is pronounced "flow of" (like "there's a flow of
>>> water"),
>>>          with flowofs simply being the plural form.
>
> My initial reading was "blow offs", but I'm still a schoolboy at heart..
>
> <snip>
>>
>> This is one of your ideas that I like, and have implemented my own
>> version.
>
> It is also one which (as discussed last year) already available in C++ :)

I don't remember the C++ version. What's the feature called there?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#74704

Bartc wrote:
> On 02/11/2015 21:13, Ian Collins wrote:
>> Bartc wrote:
>>> On 02/11/2015 19:20, Rick C. Hodgin wrote:
>>>> Note:  The flowof is pronounced "flow of" (like "there's a flow of
>>>> water"),
>>>>           with flowofs simply being the plural form.
>>
>> My initial reading was "blow offs", but I'm still a schoolboy at heart..
>>
>> <snip>
>>>
>>> This is one of your ideas that I like, and have implemented my own
>>> version.
>>
>> It is also one which (as discussed last year) already available in C++ :)
>
> I don't remember the C++ version. What's the feature called there?

A function object (functor).

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#74707

On 02/11/2015 21:31, Ian Collins wrote:
> Bartc wrote:
>> On 02/11/2015 21:13, Ian Collins wrote:
>>> Bartc wrote:

>>>> This is one of your ideas that I like, and have implemented my own
>>>> version.
>>>
>>> It is also one which (as discussed last year) already available in
>>> C++ :)
>>
>> I don't remember the C++ version. What's the feature called there?
>
> A function object (functor).

OK. My initial reading suggests that the concept is rather more 
elaborate and general purpose than what is being discussed here, which 
is a way of getting from X in a function to Y in the same function, then 
returning to just after X. I believe that what I've implemented is very 
easy to understand.

(I've looked at the link to last year's thread, I couldn't see any 
examples of functors there. What would my version of Rick's example look 
like using functors? (The fact that I have to ask doesn't bode well!). A 
link to one of last year's posts will do.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#74710

Bartc wrote:
> On 02/11/2015 21:31, Ian Collins wrote:
>> Bartc wrote:
>>> On 02/11/2015 21:13, Ian Collins wrote:
>>>> Bartc wrote:
>
>>>>> This is one of your ideas that I like, and have implemented my own
>>>>> version.
>>>>
>>>> It is also one which (as discussed last year) already available in
>>>> C++ :)
>>>
>>> I don't remember the C++ version. What's the feature called there?
>>
>> A function object (functor).
>
> OK. My initial reading suggests that the concept is rather more
> elaborate and general purpose than what is being discussed here, which
> is a way of getting from X in a function to Y in the same function, then
> returning to just after X. I believe that what I've implemented is very
> easy to understand.
>
> (I've looked at the link to last year's thread, I couldn't see any
> examples of functors there. What would my version of Rick's example look
> like using functors? (The fact that I have to ask doesn't bode well!). A
> link to one of last year's posts will do.)

One form would be:

struct my_function
{
   int result;
   int count;
   int value;

   void five_count()
   {
     result = 5*value;
   }

   void ten_count()
   {
     result = 10*value;
   }

   void greater_than_ten_count()
   {
     result = 42*value;
   }

   int operator()( int c, int v )
   {
     count = c;
     value = v;

     if (count < 5)         five_count();
     else if (count < 10)   ten_count();
     else                   greater_than_ten_count();

     return result;
   }
};

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#74713

On Monday, November 2, 2015 at 5:20:57 PM UTC-5, Ian Collins wrote:
> Bartc wrote:
> > On 02/11/2015 21:31, Ian Collins wrote:
> >> Bartc wrote:
> >>> On 02/11/2015 21:13, Ian Collins wrote:
> >>>> Bartc wrote:
> >
> >>>>> This is one of your ideas that I like, and have implemented my own
> >>>>> version.
> >>>>
> >>>> It is also one which (as discussed last year) already available in
> >>>> C++ :)
> >>>
> >>> I don't remember the C++ version. What's the feature called there?
> >>
> >> A function object (functor).
> >
> > OK. My initial reading suggests that the concept is rather more
> > elaborate and general purpose than what is being discussed here, which
> > is a way of getting from X in a function to Y in the same function, then
> > returning to just after X. I believe that what I've implemented is very
> > easy to understand.
> >
> > (I've looked at the link to last year's thread, I couldn't see any
> > examples of functors there. What would my version of Rick's example look
> > like using functors? (The fact that I have to ask doesn't bode well!). A
> > link to one of last year's posts will do.)
> 
> One form would be:
> 
> struct my_function
> {
>    int result;
>    int count;
>    int value;
> 
>    void five_count()
>    {
>      result = 5*value;
>    }
> 
>    void ten_count()
>    {
>      result = 10*value;
>    }
> 
>    void greater_than_ten_count()
>    {
>      result = 42*value;
>    }
> 
>    int operator()( int c, int v )
>    {
>      count = c;
>      value = v;
> 
>      if (count < 5)         five_count();
>      else if (count < 10)   ten_count();
>      else                   greater_than_ten_count();
> 
>      return result;
>    }
> };

You're calling functions.  You cannot do what flowofs do with
functors.  They can take the blocks shown in my posts, which
contain un-mated { and } portions of flow control logic, and
handle them.

In addition, because it's C/C++, everything has to be defined
BEFORE it is used, which means now I'm on a hunt-for-the-actual-
source-code mission to try to find where the logic that actually
uses the five_count() function is.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74716

On Monday, November 2, 2015 at 5:33:36 PM UTC-5, Rick C. Hodgin wrote:
> On Monday, November 2, 2015 at 5:20:57 PM UTC-5, Ian Collins wrote:
> > Bartc wrote:
> > > On 02/11/2015 21:31, Ian Collins wrote:
> > >> Bartc wrote:
> > >>> On 02/11/2015 21:13, Ian Collins wrote:
> > >>>> Bartc wrote:
> > >
> > >>>>> This is one of your ideas that I like, and have implemented my own
> > >>>>> version.
> > >>>>
> > >>>> It is also one which (as discussed last year) already available in
> > >>>> C++ :)
> > >>>
> > >>> I don't remember the C++ version. What's the feature called there?
> > >>
> > >> A function object (functor).
> > >
> > > OK. My initial reading suggests that the concept is rather more
> > > elaborate and general purpose than what is being discussed here, which
> > > is a way of getting from X in a function to Y in the same function, then
> > > returning to just after X. I believe that what I've implemented is very
> > > easy to understand.
> > >
> > > (I've looked at the link to last year's thread, I couldn't see any
> > > examples of functors there. What would my version of Rick's example look
> > > like using functors? (The fact that I have to ask doesn't bode well!). A
> > > link to one of last year's posts will do.)
> > 
> > One form would be:
> > 
> > struct my_function
> > {
> >    int result;
> >    int count;
> >    int value;
> > 
> >    void five_count()
> >    {
> >      result = 5*value;
> >    }
> > 
> >    void ten_count()
> >    {
> >      result = 10*value;
> >    }
> > 
> >    void greater_than_ten_count()
> >    {
> >      result = 42*value;
> >    }
> > 
> >    int operator()( int c, int v )
> >    {
> >      count = c;
> >      value = v;
> > 
> >      if (count < 5)         five_count();
> >      else if (count < 10)   ten_count();
> >      else                   greater_than_ten_count();
> > 
> >      return result;
> >    }
> > };

Edited to have it make more sense:

    You're calling functions.  You cannot do what flowofs do with
    functors.  Flowofs can take the blocks shown in my posts, which
    contain un-mated { and } portions of flow control logic, and
    handle them.
  
    In addition, because it's C/C++, everything in a functor has to be
    defined BEFORE it's used, which means now I'm on a hunt-for-the-
    actual-source-code mission to try to find where the logic that
    actually uses the five_count() function is as it appears last.
    With flow { } blocks, and flowofs, they appear later in the
    program, letting you see them if you need to, but bypassing the
    details if you don't need to.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74717

Rick C. Hodgin wrote:
> On Monday, November 2, 2015 at 5:20:57 PM UTC-5, Ian Collins wrote:
>> Bartc wrote:
>>> On 02/11/2015 21:31, Ian Collins wrote:
>>>> Bartc wrote:
>>>>> On 02/11/2015 21:13, Ian Collins wrote:
>>>>>> Bartc wrote:
>>>
>>>>>>> This is one of your ideas that I like, and have implemented my own
>>>>>>> version.
>>>>>>
>>>>>> It is also one which (as discussed last year) already available in
>>>>>> C++ :)
>>>>>
>>>>> I don't remember the C++ version. What's the feature called there?
>>>>
>>>> A function object (functor).
>>>
>>> OK. My initial reading suggests that the concept is rather more
>>> elaborate and general purpose than what is being discussed here, which
>>> is a way of getting from X in a function to Y in the same function, then
>>> returning to just after X. I believe that what I've implemented is very
>>> easy to understand.
>>>
>>> (I've looked at the link to last year's thread, I couldn't see any
>>> examples of functors there. What would my version of Rick's example look
>>> like using functors? (The fact that I have to ask doesn't bode well!). A
>>> link to one of last year's posts will do.)
>>
>> One form would be:
>>
>> struct my_function
>> {
>>     int result;
>>     int count;
>>     int value;
>>
>>     void five_count()
>>     {
>>       result = 5*value;
>>     }
>>
>>     void ten_count()
>>     {
>>       result = 10*value;
>>     }
>>
>>     void greater_than_ten_count()
>>     {
>>       result = 42*value;
>>     }
>>
>>     int operator()( int c, int v )
>>     {
>>       count = c;
>>       value = v;
>>
>>       if (count < 5)         five_count();
>>       else if (count < 10)   ten_count();
>>       else                   greater_than_ten_count();
>>
>>       return result;
>>     }
>> };
>
> You're calling functions.  You cannot do what flowofs do with
> functors.  They can take the blocks shown in my posts, which
> contain un-mated { and } portions of flow control logic, and
> handle them.

They were on a different sub-thread I hadn't read.  I was referring to 
the original post.

The structure above is essentially the same as your original example.  I 
find the unmated { and } portions of flow control logic horrid and hard 
to read.  Programmers are used to reading syntactically correct blocks 
of code.

> In addition, because it's C/C++, everything has to be defined
> BEFORE it is used, which means now I'm on a hunt-for-the-actual-
> source-code mission to try to find where the logic that actually
> uses the five_count() function is.

Rather than having to search for five_count from where it is called? 
Anyway, my C++ aware GUI editor can find it for me :)

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#74720

On Monday, November 2, 2015 at 6:05:20 PM UTC-5, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Monday, November 2, 2015 at 5:20:57 PM UTC-5, Ian Collins wrote:
> >> Bartc wrote:
> >>> On 02/11/2015 21:31, Ian Collins wrote:
> >>>> Bartc wrote:
> >>>>> On 02/11/2015 21:13, Ian Collins wrote:
> >>>>>> Bartc wrote:
> >>>
> >>>>>>> This is one of your ideas that I like, and have implemented my own
> >>>>>>> version.
> >>>>>>
> >>>>>> It is also one which (as discussed last year) already available in
> >>>>>> C++ :)
> >>>>>
> >>>>> I don't remember the C++ version. What's the feature called there?
> >>>>
> >>>> A function object (functor).
> >>>
> >>> OK. My initial reading suggests that the concept is rather more
> >>> elaborate and general purpose than what is being discussed here, which
> >>> is a way of getting from X in a function to Y in the same function, then
> >>> returning to just after X. I believe that what I've implemented is very
> >>> easy to understand.
> >>>
> >>> (I've looked at the link to last year's thread, I couldn't see any
> >>> examples of functors there. What would my version of Rick's example look
> >>> like using functors? (The fact that I have to ask doesn't bode well!). A
> >>> link to one of last year's posts will do.)
> >>
> >> One form would be:
> >>
> >> struct my_function
> >> {
> >>     int result;
> >>     int count;
> >>     int value;
> >>
> >>     void five_count()
> >>     {
> >>       result = 5*value;
> >>     }
> >>
> >>     void ten_count()
> >>     {
> >>       result = 10*value;
> >>     }
> >>
> >>     void greater_than_ten_count()
> >>     {
> >>       result = 42*value;
> >>     }
> >>
> >>     int operator()( int c, int v )
> >>     {
> >>       count = c;
> >>       value = v;
> >>
> >>       if (count < 5)         five_count();
> >>       else if (count < 10)   ten_count();
> >>       else                   greater_than_ten_count();
> >>
> >>       return result;
> >>     }
> >> };
> >
> > You're calling functions.  You cannot do what flowofs do with
> > functors.  They can take the blocks shown in my posts, which
> > contain un-mated { and } portions of flow control logic, and
> > handle them.
> 
> They were on a different sub-thread I hadn't read.  I was referring to 
> the original post.
> 
> The structure above is essentially the same as your original example.  I 
> find the unmated { and } portions of flow control logic horrid and hard 
> to read.  Programmers are used to reading syntactically correct blocks 
> of code.

Had you read what I wrote, you'd read that the GUI editor has the
ability to bring flow { } blocks and flowof code BACK INTO the
original function so it's all edited inline when needed.

CAlive is purposefully and tightly integrated with the GUI editor.  This
is by design as our computer systems are not becoming more and more bash
terminal-like, but are becoming more and more 3D movie-like.

> > In addition, because it's C/C++, everything has to be defined
> > BEFORE it is used, which means now I'm on a hunt-for-the-actual-
> > source-code mission to try to find where the logic that actually
> > uses the five_count() function is.
> 
> Rather than having to search for five_count from where it is called? 
> Anyway, my C++ aware GUI editor can find it for me :)

In the GUI editor, you highlight the flowof you're on by putting your
flashing caret on it, and then it pops up in the SourceLight window.
If you want to go to it, you press Alt+G and it goes there.  And if
the token name is overloaded, then it will ask you which one you want
to go to.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74724

On Monday, November 2, 2015 at 5:09:06 PM UTC-6, Rick C. Hodgin wrote:
> In the GUI editor, you highlight the flowof you're on by putting your
> flashing caret on it, and then it pops up in the SourceLight window.
> If you want to go to it, you press Alt+G and it goes there.  And if
> the token name is overloaded, then it will ask you which one you want
> to go to.

What do you see as the advantages of that versus telescoping sections like
those in Visual Studio, and supported 25+ years ago by some of the INMOS
Transputer development software?

[toc] | [prev] | [next] | [standalone]

#74726

On Monday, November 2, 2015 at 7:44:36 PM UTC-5, supe...@casperkitty.com wrote:
> On Monday, November 2, 2015 at 5:09:06 PM UTC-6, Rick C. Hodgin wrote:
> > In the GUI editor, you highlight the flowof you're on by putting your
> > flashing caret on it, and then it pops up in the SourceLight window.
> > If you want to go to it, you press Alt+G and it goes there.  And if
> > the token name is overloaded, then it will ask you which one you want
> > to go to.
> 
> What do you see as the advantages of that versus telescoping sections like
> those in Visual Studio, and supported 25+ years ago by some of the INMOS
> Transputer development software?

I don't know what the term "telscoping sections" mean.  Are you talking
about code folding / collapse abilities?

Since CAlive is a LiveCode compiler (which means it is continuously
compiling all of your code changes), things are known about the source
code which are known only to the compiler.  As such, refactoring by
symbol scope (and not just by name) becomes possible (not a new thing,
but one which exists in a CAlive GUI editor).  And I also plan on
introducing horizontal coding, rather than vertical coding, which
will allow blocks of code to be grouped, and then moved horizontally
so that code doesn't just go down, but across, and not just by the
details of the mechanics of the physical source code instructions,
but by their group names, allowing for a type of spatial flow of
source code, which is something I ultimately want to hook up to a
full 3D node editor like the one seen today in Blender, and the one
I'm working on for my Logician circuit layout software.

Lots of plans.  Lots of vision.  I just need time and help.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web