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

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

Winding and unwinding

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

Contents

  Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 11:46 -0800
    Re: Winding and unwinding Anton Shepelev <anton.txt@gmail.com> - 2016-12-12 23:15 +0300
      Re: Winding and unwinding Anton Shepelev <anton.txt@gmail.com> - 2016-12-12 23:21 +0300
      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 13:29 -0800
        Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 14:07 -0800
          Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-15 08:54 -0800
            Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-15 09:04 -0800
              Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-15 09:15 -0800
    Re: Winding and unwinding supercat@casperkitty.com - 2016-12-12 12:21 -0800
    Re: Winding and unwinding BartC <bc@freeuk.com> - 2016-12-12 20:48 +0000
      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 13:28 -0800
    Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 13:14 -0800
      Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 14:26 -0800
        Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 16:13 -0800
          Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 16:33 -0800
            Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 16:48 -0800
              Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 17:05 -0800
                Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 17:22 -0800
                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 17:33 -0800
                    Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 17:55 -0800
                      Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 03:11 -0800
                        Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 03:39 -0800
                          Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 03:59 -0800
                            Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 04:57 -0800
                              Re: Winding and unwinding BartC <bc@freeuk.com> - 2016-12-13 13:24 +0000
                                Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:34 -0800
                                Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:34 -0800
                                Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:01 -0800
                                Re: Winding and unwinding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 15:10 +0000
                              Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:30 -0800
                                Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:45 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:58 -0800
                                  Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:04 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 10:24 -0800
                                    Re: Winding and unwinding Chad <cdalten@gmail.com> - 2016-12-13 21:44 -0800
                                      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 02:13 -0800
                                    Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-14 11:45 -0800
                                      Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 12:09 -0800
                                        Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-14 12:50 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-17 05:28 -0800
                                Re: Winding and unwinding BartC <bc@freeuk.com> - 2016-12-13 14:54 +0000
                                  Re: Winding and unwinding "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 07:03 -0800
                                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 07:09 -0800
                  Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-13 05:27 -0800
        Re: Winding and unwinding fir <profesor.fir@gmail.com> - 2016-12-12 17:13 -0800
    Re: Winding and unwinding Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 16:28 -0800

Page 1 of 3  [1] 2 3  Next page →

#99120 — Winding and unwinding

This is a message primarily for input from Supercat and Bart, but I
post it publicly to give everyone an opportunity for input.

Suppose I have a process which must operate on these two files which
are known to be less than a few hundred KB each, on a machine which
has Gigabytes of memory:

    1)  Open file1 and file2
    2)  Get both file's sizes
    3)  Note if file1 and file2 sizes are equal
    4)  Read both file's contents into memory
    5)  Compare content byte-by-byte, see if they contain any binary
        characters (non-A_Z,a_z,0_9, plus standard symbols, CR, LF,
        and a few others), and if they're exactly equal/identical
    6)  Return the results

In the process of doing this, there will be places where the process
could fail.  File2 may be exclusively used by another process, and
cannot be opened.  This may have been discovered after file1 had
already been opened, for example, and must be closed.  But, file2
hasn't yet been opened.  Nor has any memory been allocated, etc.

-----
I'm trying to come up with a good way to handle the associated unwind
syntax without having complex nested statements.

In CAlive I already have defined a convention like this:

    void function_name(void)
    {
        // Function code goes here

        // Also self-contained flow blocks:
        flow {
            flowout;  // A structured way to handle potentially
                      // deeply nested control flow
        }

    } tag() {
        // Some code can be referenced here by the tag name,
        // indicating it's related to the thing it's attached
        // to (in this case, "function_name()").
    };

-----
I'm thinking it might be desirable to add an unwind keyword, and to
create wind {..} and unwind {..} blocks, so they are self-documenting,
and located in the file near where the wind occurs, with the compiler
taking the necessary steps to setup conditions to politely unwind
when indicated:

    int function_name(char* file1name, char* file2name)
    {
        int result, f1handle, f2handle, f1size, f2size;

        // Enter a flow block to politely exit out of if
        // there's an error
        flow {

            // Define wind and unwind operations on file1
            wind {
                f1handle = open(file1name...);
                if (f1handle <= 0)
                {
                    // Failed to open
                    result = -1;
                    flowout;  // Flows out of the flow {..} block
                }

            } unwind {
                // Code to unwind goes here
                if (f1handle > 0)
                    close(f1handle);
            }

            // Define wind and unwind operations on file2
            wind {
                f2handle = open(file1name...);
                if (f2handle <= 0)
                {
                    // Failed to open
                    result = -2;
                    flowout;  // Flows out of the flow {..} block
                }

            } unwind {
                // Code to unwind goes here
                if (f2handle > 0)
                    close(f2handle);
            }

            // Get file sizes
            f1size = filesize(f1handle);
            f2size = filesize(f2handle);

            // And each of the following would have similar wind
            // and unwind blocks:

            // Allocate memory to load files
            // Read files
            // Compare files
            // Close files

        }

        // Perform all unwind operations in one fell swoop
        unwind;

        // Indicate our final result
        return result;
    }

Through normal flow control, processing would enter the wind {..}
blocks.  If there was an error and it encountered flowout, it would
then hit the unwind instruction, which tells it to call all of the
unwind {..} blocks that were traversed at runtime through entry in
to the wind {..} blocks.

If you have any comments or other ideas / suggestions, please feel
free to share them.

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#99122

Rick C. Hodgin:

> Suppose  I  have  a  process which must operate on
> these two files which are known to be less than  a
> few  hundred KB each, on a machine which has Giga-
> bytes of memory:
>
>   1.  Open file1 and file2
>   2.  Get both file's sizes
>   3.  Note if file1 and file2 sizes are equal
>   4.  Read both file's contents into memory
>   5.  Compare content byte-by-byte,  see  if  they
>       contain any binary
>   6.  characters  (non-A_Z,a_z,0_9,  plus standard
>       symbols, CR, LF,
>   7.  and a few others), and  if  they're  exactly
>       equal/identical
>   8.  Return the results
>
> In the process of doing this, there will be places
> where the process could fail.  File2 may be exclu-
> sively  used  by  another  process,  and cannot be
> opened.  This may have been discovered after file1
> had  already been opened, for example, and must be
> closed.  But, file2 hasn't yet been  opened.   Nor
> has any memory been allocated, etc.

If  you  will pardon my impudence in offering an an-
swer, I  usually  solve  such  problems  using  goto
statements, e.g:

    int result = ERROR;

    f1_handle = open( file_name_1 );
    if( f1_nandle == NULL )
    {  goto ERROR;  }

    f1_handle = open( file_name_2 );
    if( f1_nandle == NULL )
    {  goto ERROR_1;  }

    if( do_stuff( f1_handle, f2_handle ) != 0 )
    {  goto ERROR_21;  }

    result = SUCCESS;

    ERROR_21:
       close( f2_handle );
    ERROR_1:
       close( f1_handle );
    ERROR:
       return result;

Yes,  I do agree with Knuth that goto can be used in
a structured way.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#99124

I misquoted Rick C. Hodgin:

> Suppose  I  have  a  process which must operate on
> these two files which are known to be less than  a
> few  hundred KB each, on a machine which has Giga-
> bytes of memory:
>
>   1.  Open file1 and file2
>   2.  Get both file's sizes
>   3.  Note if file1 and file2 sizes are equal
>   4.  Read both file's contents into memory
>   5.  Compare content byte-by-byte,  see  if  they
>       contain any binary
>   6.  characters  (non-A_Z,a_z,0_9,  plus standard
>       symbols, CR, LF,
>   7.  and a few others), and  if  they're  exactly
>       equal/identical
>   8.  Return the results
> [...]

I  beg your pardon for munging your list.  It should
be:

  1.  Open file1 and file2
  2.  Get both file's sizes
  3.  Note if file1 and file2 sizes are equal
  4.  Read both file's contents into memory
  5.  Compare content byte-by-byte, see if they con-
      tain  any  binary characters (non-A_Z,a_z,0_9,
      plus standard symbols, CR, LF, and a few  oth-
      ers), and if they're exactly equal/identical
  6.  Return the results

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#99137

On Monday, December 12, 2016 at 3:15:39 PM UTC-5, Anton Shepelev wrote:
> Yes,  I do agree with Knuth that goto can be used in
> a structured way.

I created flow {..} blocks so that goto commands would not have to be
used any longer, and the operations are well-defined in a structured
format that is self-documenting.

flow {..} blocks give structure to unstructured code, and allow for
things to be done with code which greatly simplifies its understanding
while maintaining its form and function.

Best regards,
Rick C. Hodgin

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

#99140

as to blocks one could consider general support for blocks  
(more genereal and besides not related to wind/unwind  inner mechanic, (except block mentioning and calling with block name here above) ( it was also recently a bit talked in a thread on entry points though from different aspect/angle) (used this place as a pretext to talk on blocks)

for example

void main()
{
do {}
re {}
mi {}
fa {}
sol {}
la {}
si {}
do2 {]

do; re; mi; fa; soll; la; si; do2;
}

here block definition is strightforward, block 
calling is 'almost strightforward' (one should 
maybe consider if not use () at call like do(); re();
but ommiting it seem interesting option)

here topics are 
1) if block should be just called when going thru text definition
2) or maybe it should be treated as a virtual definition only (called only on label call)
3) if block should 'pass' to another one block at its end "}" or just return to the place after the call 

(and obviously what more could be done to that)

as to those 3 topics i would answer except that for 
now it maybe seems that all options should be used 
maybe with additional keywords

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

#99524

W dniu poniedziałek, 12 grudnia 2016 23:08:10 UTC+1 użytkownik fir napisał:
> as to blocks one could consider general support for blocks  
> (more genereal and besides not related to wind/unwind  inner mechanic, (except block mentioning and calling with block name here above) ( it was also recently a bit talked in a thread on entry points though from different aspect/angle) (used this place as a pretext to talk on blocks)
> 
> for example
> 
> void main()
> {
> do {}
> re {}
> mi {}
> fa {}
> sol {}
> la {}
> si {}
> do2 {]
> 
> do; re; mi; fa; soll; la; si; do2;
> }
> 
> here block definition is strightforward, block 
> calling is 'almost strightforward' (one should 
> maybe consider if not use () at call like do(); re();
> but ommiting it seem interesting option)
> 
> here topics are 
> 1) if block should be just called when going thru text definition
> 2) or maybe it should be treated as a virtual definition only (called only on label call)
> 3) if block should 'pass' to another one block at its end "}" or just return to the place after the call 
> 
> (and obviously what more could be done to that)
> 
> as to those 3 topics i would answer except that for 
> now it maybe seems that all options should be used 
> maybe with additional keywords

as to this all posibilities the most easy and usefull seem to me this one when blocks are just used to denote
blocks of code //sorta like commentary

void foo()
{
  setup { 
  //code
  }
  
  something {
  //code

  }

  cleanuo {
  //code

  }

}

this seems good idea, esp as it also can be used to 
denote if and for blocks

 if(a<2) bounce { /**/ } else forward { /**/ }

 for() clear_array {}

what more can be done with such thing (like controll passing or what0 could be also considered

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

#99527

On Thursday, December 15, 2016 at 11:54:12 AM UTC-5, fir wrote:
> W dniu poniedziałek, 12 grudnia 2016 23:08:10 UTC+1 użytkownik fir napisał:
> > as to blocks one could consider general support for blocks  
> > (more genereal and besides not related to wind/unwind  inner mechanic, (except block mentioning and calling with block name here above) ( it was also recently a bit talked in a thread on entry points though from different aspect/angle) (used this place as a pretext to talk on blocks)
> > 
> > for example
> > 
> > void main()
> > {
> > do {}
> > re {}
> > mi {}
> > fa {}
> > sol {}
> > la {}
> > si {}
> > do2 {]
> > 
> > do; re; mi; fa; soll; la; si; do2;
> > }
> > 
> > here block definition is strightforward, block 
> > calling is 'almost strightforward' (one should 
> > maybe consider if not use () at call like do(); re();
> > but ommiting it seem interesting option)
> > 
> > here topics are 
> > 1) if block should be just called when going thru text definition
> > 2) or maybe it should be treated as a virtual definition only (called only on label call)
> > 3) if block should 'pass' to another one block at its end "}" or just return to the place after the call 
> > 
> > (and obviously what more could be done to that)
> > 
> > as to those 3 topics i would answer except that for 
> > now it maybe seems that all options should be used 
> > maybe with additional keywords
> 
> as to this all posibilities the most easy and usefull seem to me this one when blocks are just used to denote
> blocks of code //sorta like commentary
> 
> void foo()
> {
>   setup { 
>   //code
>   }
>   
>   something {
>   //code
> 
>   }
> 
>   cleanuo {
>   //code
> 
>   }
> 
> }
> 
> this seems good idea, esp as it also can be used to 
> denote if and for blocks

The setup and cleanup components are defined far away from each
other, which is one of the things I was trying to address with the
wind {..} and unwind {..} blocks.  They are not contextual to the
winding and unwinding involved, but exist as a massive series of
steps which may be unrelated to each other, but then must appear
next to each other in code.  They are a single bulk quantity of
code which conducts the work, rather than being components affixed
to their instantiation location, which would then only conduct the
unwind work only if they were first wound up/into.

>  if(a<2) bounce { /**/ } else forward { /**/ }
> 
>  for() clear_array {}
> 
> what more can be done with such thing (like controll passing or what0 could be also considered

Lots of ways to accomplish things.  I'm looking at ways which are
always a little more self-documenting in the code, because it is a
big expense to go in later and perform maintenance.  The mindset of
how the thing was created is diminished / vanished, and it requires
some re-learining to continue.  By placing things closer to each
other, or in more human readable words, while still maintaining the
underlying abilities present in C, the better tool yields a better
working environment for the developer(s).

Best regards,
Rick C. Hodgn

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

#99529

W dniu czwartek, 15 grudnia 2016 18:05:07 UTC+1 użytkownik Rick C. Hodgin napisał:
> On Thursday, December 15, 2016 at 11:54:12 AM UTC-5, fir wrote:
> > W dniu poniedziałek, 12 grudnia 2016 23:08:10 UTC+1 użytkownik fir napisał:
> > > as to blocks one could consider general support for blocks  
> > > (more genereal and besides not related to wind/unwind  inner mechanic, (except block mentioning and calling with block name here above) ( it was also recently a bit talked in a thread on entry points though from different aspect/angle) (used this place as a pretext to talk on blocks)
> > > 
> > > for example
> > > 
> > > void main()
> > > {
> > > do {}
> > > re {}
> > > mi {}
> > > fa {}
> > > sol {}
> > > la {}
> > > si {}
> > > do2 {]
> > > 
> > > do; re; mi; fa; soll; la; si; do2;
> > > }
> > > 
> > > here block definition is strightforward, block 
> > > calling is 'almost strightforward' (one should 
> > > maybe consider if not use () at call like do(); re();
> > > but ommiting it seem interesting option)
> > > 
> > > here topics are 
> > > 1) if block should be just called when going thru text definition
> > > 2) or maybe it should be treated as a virtual definition only (called only on label call)
> > > 3) if block should 'pass' to another one block at its end "}" or just return to the place after the call 
> > > 
> > > (and obviously what more could be done to that)
> > > 
> > > as to those 3 topics i would answer except that for 
> > > now it maybe seems that all options should be used 
> > > maybe with additional keywords
> > 
> > as to this all posibilities the most easy and usefull seem to me this one when blocks are just used to denote
> > blocks of code //sorta like commentary
> > 
> > void foo()
> > {
> >   setup { 
> >   //code
> >   }
> >   
> >   something {
> >   //code
> > 
> >   }
> > 
> >   cleanuo {
> >   //code
> > 
> >   }
> > 
> > }
> > 
> > this seems good idea, esp as it also can be used to 
> > denote if and for blocks
> 
> The setup and cleanup components are defined far away from each
> other, which is one of the things I was trying to address with the


here it was an abstract example one could use blocks 
naming for probably more sane purposes (but i dont wanted to devote time for finding it on real examples)

> wind {..} and unwind {..} blocks.  They are not contextual to the
> winding and unwinding involved, but exist as a massive series of
> steps which may be unrelated to each other, but then must appear
> next to each other in code.  They are a single bulk quantity of
> code which conducts the work, rather than being components affixed
> to their instantiation location, which would then only conduct the
> unwind work only if they were first wound up/into.
> 
> >  if(a<2) bounce { /**/ } else forward { /**/ }
> > 
> >  for() clear_array {}
> > 
> > what more can be done with such thing (like controll passing or what0 could be also considered
> 
> Lots of ways to accomplish things.  I'm looking at ways which are
> always a little more self-documenting in the code, because it is a
> big expense to go in later and perform maintenance.  The mindset of
> how the thing was created is diminished / vanished, and it requires
> some re-learining to continue.  By placing things closer to each
> other, or in more human readable words, while still maintaining the
> underlying abilities present in C, the better tool yields a better
> working environment for the developer(s).
> 
> Best regards,
> Rick C. Hodgn

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

#99123

On Monday, December 12, 2016 at 1:46:30 PM UTC-6, Rick C. Hodgin wrote:
> In the process of doing this, there will be places where the process
> could fail.  File2 may be exclusively used by another process, and
> cannot be opened.  This may have been discovered after file1 had
> already been opened, for example, and must be closed.  But, file2
> hasn't yet been opened.  Nor has any memory been allocated, etc.
>
> I'm trying to come up with a good way to handle the associated unwind
> syntax without having complex nested statements.

The approach I'd suggest would be to use a per-thread error flag (which
could, at an implementation's leisure, be aliased to "errno" but need
not be) whose semantics would be defined in certain places where the
semantics of "errno" are not, and vice versa.  Include both a function
which will definitively report whether the error flag is pending, and
one which may, but need not, return true if the flag is pending, with
a presumption that a compiler should try to strike a balance between the
cost of checks and the frequency thereof.  In many cases it won't matter
much exactly what the balance is, provided that a compiler tries to strike
one.  If a loop runs 2,000,000,000 times, the performance impact of
checking once every 1,000 iterations versus once every 500,000,000 would
probably not be significant, but the difference in time to recognize an
early-exit failure would be.  On the other hand, the performance impact
of testing on every iteration might be severe (especially if each test
would preclude consolidating operations on either side of it).  In many
cases, the optimal testing frequency would probably coincide with the amount
by which the compiler unrolls loops (e.g. if a compiler unrolls a loop 4x,
checking for an early exit once every unrolled loop would often be a good
balance).

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

#99128

On 12/12/2016 19:46, Rick C. Hodgin wrote:
> This is a message primarily for input from Supercat and Bart, but I
> post it publicly to give everyone an opportunity for input.
>
> Suppose I have a process which must operate on these two files which
> are known to be less than a few hundred KB each, on a machine which
> has Gigabytes of memory:
>
>     1)  Open file1 and file2
>     2)  Get both file's sizes
>     3)  Note if file1 and file2 sizes are equal

Then what, continue only if they're both the same, or bail out at this 
point?

>     4)  Read both file's contents into memory
>     5)  Compare content byte-by-byte, see if they contain any binary
>         characters (non-A_Z,a_z,0_9, plus standard symbols, CR, LF,
>         and a few others), and if they're exactly equal/identical
>     6)  Return the results

Is this a real task or just a set-up to demonstrate the new UnWind 
feature? Because I found that hard to follow.

If writing this in a dynamic language, I might just read both files into 
memory anyway:

   f = readfile("one")    # say each is a string descriptor
   g = readfile("two")

   if f.error or g.error: # or f/g are null on error
     freestring(f)        # trust it not to free if not allocated
     freestring(g)

Otherwise, at this point you now have effectively two strings that you 
do what you like with without still worrying about file errors.

If this is for a new language, I'd advise you to look at exceptions 
(/but keep it simple/), and automatic freeing of selected variables as 
they pass out of scope. But again, without it getting so out of hand 
that you end up with a poor C++ imitation.

-- 
Bartc

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

#99136

On Monday, December 12, 2016 at 3:48:45 PM UTC-5, Bart wrote:
> On 12/12/2016 19:46, Rick C. Hodgin wrote:
> >     3)  Note if file1 and file2 sizes are equal
> Then what, continue only if they're both the same, or bail out at this 
> point?

Continue.  It's just a note if the file sizes are different.

> Is this a real task or just a set-up to demonstrate the new UnWind 
> feature? Because I found that hard to follow.

I had to write code similar to this today for a compare utility.

Best regards,
Rick C. Hodgin

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

#99134

from my understanding of c you should probably do 
no any error handling in c


(this is becouse program if not for code error 
states imo but normal expectable states which 
should probably be not treated as errors but as 
states to code (this may leads to some ideas)
yet some advantage of this view relate to the 
thing that error handling code looks usueally 
terribly ugly for my eyes, what advantage if you 
will not have it at all...)

(some other related idea is to build 'demanding' 
controll mechanism (demanding reaction on all
states function may bring - right now it is 
just easy to write code that ignores a lot), 
its maybe worth rethinking what can be done here)

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

#99144

W dniu poniedziałek, 12 grudnia 2016 22:15:00 UTC+1 użytkownik fir napisał:
> (some other related idea is to build 'demanding' 
> controll mechanism (demanding reaction on all
> states function may bring - right now it is 
> just easy to write code that ignores a lot), 
> its maybe worth rethinking what can be done here)

that would need come consideration but some initial
thought it could look like based on switch (as maybe
those states can be enumerated like in switch)

foo("lala.txt")  {  case NO_FILE: ;  case INTERNAL_INCONSISTENCY: ; case UNDEFINED_SOMETHING: ;    }

looks not much good but maybe worth rethinking (other option is to register global handlers and demand each one for a communicate, or something mixed and improved)

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

#99154

fir, your posts had me wondering:  Have you ever used gravy.h?  It
works seamlessly with biscuits.h to enhance breakfast.c.

You might like it.

Best regards,
Rick C. Hodgin

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

#99159

W dniu wtorek, 13 grudnia 2016 01:13:14 UTC+1 użytkownik Rick C. Hodgin napisał:
> fir, your posts had me wondering:  Have you ever used gravy.h?  It
> works seamlessly with biscuits.h to enhance breakfast.c.
> 
> You might like it.
> 
i dont totally know what you mean, explain maybe

i got over 10 years of somewhat disciplined thinking 
on c subject and this allows me to state various points

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

#99162

On Monday, December 12, 2016 at 7:34:01 PM UTC-5, fir wrote:
> W dniu wtorek, 13 grudnia 2016 01:13:14 UTC+1 użytkownik Rick C. Hodgin napisał:
> > fir, your posts had me wondering:  Have you ever used gravy.h?  It
> > works seamlessly with biscuits.h to enhance breakfast.c.
> > 
> > You might like it.
>
> i dont totally know what you mean, explain maybe

I was trying for humor.  But, like most of my attempts, came up short.

> i got over 10 years of somewhat disciplined thinking 
> on c subject and this allows me to state various points

Best regards,
Rick C. Hodgin

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

#99164

W dniu wtorek, 13 grudnia 2016 01:49:04 UTC+1 użytkownik Rick C. Hodgin napisał:
> On Monday, December 12, 2016 at 7:34:01 PM UTC-5, fir wrote:
> > W dniu wtorek, 13 grudnia 2016 01:13:14 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > fir, your posts had me wondering:  Have you ever used gravy.h?  It
> > > works seamlessly with biscuits.h to enhance breakfast.c.
> > > 
> > > You might like it.
> >
> > i dont totally know what you mean, explain maybe
> 
> I was trying for humor.  But, like most of my attempts, came up short.
> 
still dont know what you mean.. maybe it was about concistency of syntax or what - it is good to have 
syntax concise though c spirit seem to be more behind 
that (for me its maybe like bigger jumps of ideas with
some non obvious side precedences (seeing it vaguelly) - buts its hard topic) all those 3 topics i said in this thread are not finished 

> > i got over 10 years of somewhat disciplined thinking 
> > on c subject and this allows me to state various points
> 
> Best regards,
> Rick C. Hodgin

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

#99169

On Monday, December 12, 2016 at 8:05:56 PM UTC-5, fir wrote:
> W dniu wtorek, 13 grudnia 2016 01:49:04 UTC+1 użytkownik Rick C. Hodgin napisał:
> > On Monday, December 12, 2016 at 7:34:01 PM UTC-5, fir wrote:
> > > W dniu wtorek, 13 grudnia 2016 01:13:14 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > > fir, your posts had me wondering:  Have you ever used gravy.h?  It
> > > > works seamlessly with biscuits.h to enhance breakfast.c.
> > > > 
> > > > You might like it.
> > >
> > > i dont totally know what you mean, explain maybe
> > 
> > I was trying for humor.  But, like most of my attempts, came up short.
> > 
> still dont know what you mean..

Biscuits and gravy are a breakfast meal.  It's not eaten too often
because it's rather rich, but many people like it:

    http://s3.amazonaws.com/oratv/assets/prod/asset/231630-biscuits-0.jpg

I was just being silly saying that gravy.h goes seamlessly with
biscuits.c to improve breakfast.c ... meaning "biscuits and gravy
make breakfast taste better."  It was an unrelated silly response
to your posts.

I apologize for the confusion.

> maybe it was about concistency of syntax or what - it is good to have 
> syntax concise though c spirit seem to be more behind 
> that (for me its maybe like bigger jumps of ideas with
> some non obvious side precedences (seeing it vaguelly) - buts its
> hard topic) all those 3 topics i said in this thread are not finished

The wind {..} and unwind {..} blocks are not just for error recovery,
but for unwinding operations created in a function, and without having
to use unstructured code.  It also helps document the unwind operation
so that it's defined near where it was created within the function.

When extended to error recovery it allows two other features of CAlive
which are "unwindto name" and "marker name" where you can create
markers in code which can be unwound to directly if there is an error.

In those cases, by traversing up the stack to the function which
contains the marker, each function can be unwound appropriately using
the wind {..} unwind {..} blocks.

> > > i got over 10 years of somewhat disciplined thinking 
> > > on c subject and this allows me to state various points

Best regards,
Rick C. Hodgin

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

#99170

W dniu wtorek, 13 grudnia 2016 02:22:14 UTC+1 użytkownik Rick C. Hodgin napisał:
> On Monday, December 12, 2016 at 8:05:56 PM UTC-5, fir wrote:
> > W dniu wtorek, 13 grudnia 2016 01:49:04 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > On Monday, December 12, 2016 at 7:34:01 PM UTC-5, fir wrote:
> > > > W dniu wtorek, 13 grudnia 2016 01:13:14 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > > > fir, your posts had me wondering:  Have you ever used gravy.h?  It
> > > > > works seamlessly with biscuits.h to enhance breakfast.c.
> > > > > 
> > > > > You might like it.
> > > >
> > > > i dont totally know what you mean, explain maybe
> > > 
> > > I was trying for humor.  But, like most of my attempts, came up short.
> > > 
> > still dont know what you mean..
> 
> Biscuits and gravy are a breakfast meal.  It's not eaten too often
> because it's rather rich, but many people like it:
> 
>     http://s3.amazonaws.com/oratv/assets/prod/asset/231630-biscuits-0.jpg
> 
> I was just being silly saying that gravy.h goes seamlessly with
> biscuits.c to improve breakfast.c ... meaning "biscuits and gravy
> make breakfast taste better."  It was an unrelated silly response
> to your posts.
> 
> I apologize for the confusion.
> 
> > maybe it was about concistency of syntax or what - it is good to have 
> > syntax concise though c spirit seem to be more behind 
> > that (for me its maybe like bigger jumps of ideas with
> > some non obvious side precedences (seeing it vaguelly) - buts its
> > hard topic) all those 3 topics i said in this thread are not finished
> 
> The wind {..} and unwind {..} blocks are not just for error recovery,
> but for unwinding operations created in a function, and without having
> to use unstructured code.  It also helps document the unwind operation
> so that it's defined near where it was created within the function.
> 
> When extended to error recovery it allows two other features of CAlive
> which are "unwindto name" and "marker name" where you can create
> markers in code which can be unwound to directly if there is an error.
> 
> In those cases, by traversing up the stack to the function which
> contains the marker, each function can be unwound appropriately using
> the wind {..} unwind {..} blocks.
> 
> > > > i got over 10 years of somewhat disciplined thinking 
> > > > on c subject and this allows me to state various points
> 
> Best regards,
> Rick C. Hodgin

i was not talking about this wind-unwind i dont belive in this 2 much, one line in your example that was somewhat interesting 2 me was

          flowout;  // Flows out of the flow {..} block 

as this resembles block calling or new keyword for
control structures (gives ma a bit to think on such topics)
 
imo your semantic ideas are not much good imo 
 but sometimes you can vrite a piece of invented syntax that can get a bit of attention (i remember once ago you
gave a link to some "internal function namespaces"
9functions defined in functions) and there was also some
somewhat interesting pieces of syntax there)

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

#99171

On Monday, December 12, 2016 at 8:33:46 PM UTC-5, fir wrote:
> i was not talking about this wind-unwind i dont belive in this 2
> much, one line in your example that was somewhat interesting 2 me
> was
> 
>           flowout;  // Flows out of the flow {..} block 
> 
> as this resembles block calling or new keyword for
> control structures (gives ma a bit to think on such topics)
>  
> imo your semantic ideas are not much good imo 
>  but sometimes you can vrite a piece of invented syntax that can get
> a bit of attention (i remember once ago you
> gave a link to some "internal function namespaces"
> 9functions defined in functions) and there was also some
> somewhat interesting pieces of syntax there)

All of my published ideas are here:

    https://groups.google.com/forum/#!forum/caliveprogramminglanguage

Best regards,
Rick C. Hodgin

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web