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 2 of 2 — ← Prev page 1 [2]

#74729

Rick C. Hodgin wrote:
> 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).

I though most modern IDE based editors perform background compilation 
which enables them, amongst other things, to highlight syntax errors on 
the fly and highlight the correct bits of conditionally compiled code.

-- 
Ian Collins

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

#74731

On Monday, November 2, 2015 at 11:07:13 PM UTC-5, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > 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).
> 
> I though most modern IDE based editors perform background compilation 
> which enables them, amongst other things, to highlight syntax errors on 
> the fly and highlight the correct bits of conditionally compiled code.

It's not always full compilation, but parsing.  But yes, most of them
provide something.

With the LiveCode ABI, the code is literally compiled continuously
whether it compiles properly or not.  If it does not compile properly
(due to errors in the source code), the compiler will simply wrap the
line in an inquiry, which will signal to the OS and trap to the
debugger during development so the error condition can be fixed.

In this way, programs which are not yet completed, and even have
errors in them still, can be coded, compiled, and run.  Everything
that works properly will run like it should, and when it reaches
something that's missing, it will signal an inquiry and wait for the
developer to step in and correct the error, allowing it to continue.

Best regards,
Rick C. Hodgin

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

#74750

On 02/11/2015 22:20, Ian Collins wrote:
> Bartc wrote:

>> (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;
>    }
> };
>

That didn't look too bad at first: a function containing local 
functions, not quite what the thread** is about, but it will do the job.

Until I looked closer and realised this wasn't a function, but a struct, 
and what looks like the function body is an operator overload for (). 
Now, I have to think very hard about what it means, how it would be 
used, and why you would do it this way.

But getting back to the local functions which I can understand, there is 
a difference between those and what I implement as callable blocks(**). 
For example the code inside a local function can be written inline in 
the normal manner, but marked so that the same code can be executed from 
elsewhere in the block:

void func(void) {

   puts("Before:");
   for (i=0; i<N; ++i)
      for (j=0; j<M; ++j)
         printf(......)
      puts("");

   processdata(data,...)

   puts("After:");
   for (i=0; i<N; ++i)
      for (j=0; j<M; ++j)
         printf(......)
      puts("");
}

void func(void) {

    puts("Before:");
    {printdata::
       for (i=0; i<N; ++i)
          for (j=0; j<M; ++j)
             printf(......)
          puts("");
    }
    processdata(data,...)

    puts("After:");
    @printdata;
}

The syntax is experimental, but that gives the idea. And the concept is 
obvious I think.

(** I now realise this is little to do with Rick's family of 'flow' 
features, from reading follow-up posts and threads. I don't understand 
those either.)

-- 
Bartc

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

#74752

On 03/11/15 13:43, Bartc wrote:
> On 02/11/2015 22:20, Ian Collins wrote:
>> Bartc wrote:
> 
>>> (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;
>>    }
>> };
>>
> 
> That didn't look too bad at first: a function containing local
> functions, not quite what the thread** is about, but it will do the job.
> 
> Until I looked closer and realised this wasn't a function, but a struct,
> and what looks like the function body is an operator overload for ().
> Now, I have to think very hard about what it means, how it would be
> used, and why you would do it this way.

The point was not to show that this is a way that you /should/ or
/would/ code, but it is a way that you /could/ code to get much of the
effects of a "flowof" using existing C++.  (You can't get unbalanced
brackets this way - but like Ian I would say that is too horrible an
idea to consider.  And you can't put the local functions after their
usage, unless you use forward declarations.  So it is not a perfect
replication of "flowof" - but it certainly covers much of it.)

So the question of whether or not it is a good thing to write code in
the style allowed by "flowof" is a different issue, and has not been
answered (except by Rick, who clearly thinks it can be a good structure).


Overloading the () operator may take some time to get used to, but it
has its uses.  It lets you write code where you create something that
looks like and works like a function, but is created at runtime.  This
is common in functional-style coding.  It also lets you have an object
that looks and acts like a function, but that can hold a local state -
think of it like having "static" local variables in the function, except
that you can have multiple different sets of these local statics.
Another simple way to view the () operator is as a "default" method in a
class.


> 
> But getting back to the local functions which I can understand, there is
> a difference between those and what I implement as callable blocks(**).
> For example the code inside a local function can be written inline in
> the normal manner, but marked so that the same code can be executed from
> elsewhere in the block:
> 
> void func(void) {
> 
>   puts("Before:");
>   for (i=0; i<N; ++i)
>      for (j=0; j<M; ++j)
>         printf(......)
>      puts("");
> 
>   processdata(data,...)
> 
>   puts("After:");
>   for (i=0; i<N; ++i)
>      for (j=0; j<M; ++j)
>         printf(......)
>      puts("");
> }
> 
> void func(void) {
> 
>    puts("Before:");
>    {printdata::
>       for (i=0; i<N; ++i)
>          for (j=0; j<M; ++j)
>             printf(......)
>          puts("");
>    }
>    processdata(data,...)
> 
>    puts("After:");
>    @printdata;
> }
> 
> The syntax is experimental, but that gives the idea. And the concept is
> obvious I think.
> 
> (** I now realise this is little to do with Rick's family of 'flow'
> features, from reading follow-up posts and threads. I don't understand
> those either.)
> 

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

#74775

Bartc wrote:
> On 02/11/2015 22:20, Ian Collins wrote:
>>
>> 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;
>>     }
>> };
>>
>
> That didn't look too bad at first: a function containing local
> functions, not quite what the thread** is about, but it will do the job.
>
> Until I looked closer and realised this wasn't a function, but a struct,
> and what looks like the function body is an operator overload for ().
> Now, I have to think very hard about what it means, how it would be
> used, and why you would do it this way.

It is idiomatic C++, so anyone familiar with the language would know the 
pattern.  As to why, the most common use case is where you want to pass 
something that acts like a function but requires local state.  A simple 
case might be finding all items with a given name in a collection.

-- 
Ian Collins

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

#74712

On Monday, November 2, 2015 at 4:13:23 PM UTC-5, 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.
>
> > 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++ :)

Once again you are wrong, Ian!

Part of what flowofs offer is available in C++, but, as is proving to
be your usual mechanism, your cursory read of the things I post didn't
dig deep enough to gain a proper understanding, and therefore you post
a comment that is demeaning to my work, and inappropriately so.

-----
Flowofs allow for standalone-syntactically-correct-or-incorrect
blocks of code to be included -- a literal extraction from the
original function.

They also are not functions in any regard, but rather follow a
protocol which allow some function-like aspects to exist syntactically,
but they are wholly "removed blocks of code" which are literally
inserted back into place where their marker is in the original
function (or other flowof) during compilation, giving them full
context, and migrating any passed parameters or return values to
their fully non-passed context.

-----
In addition, the flowof is ONE PART of the new two-part CAlive flow
control ability.  The other part is the flow { } block itself, which
allows for the same abilities as the flowof, but to be included in
the original function, including an "always before" and "always after"
block, which will be called before the block is entered, and after
the block exits.

Again, they do not have to be syntactically correct in standalone
form, but only when they are re-assembled into their normal form.

You can read about it in my book near the last page if you choose
to do so.

-----
If you care at all about speaking properly on things, then please
take an extra moment or two to read the words which go along with
my posts.  It might give you understanding to prevent you from
posting incorrectly.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web