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

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

if cargo blocks

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

Contents

  if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 10:42 -0500
    Re: if cargo blocks David Brown <david.brown@hesbynett.no> - 2018-12-29 17:26 +0100
      Re: if cargo blocks Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-29 16:32 +0000
    Re: if cargo blocks Bart <bc@freeuk.com> - 2018-12-29 16:56 +0000
      Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 12:34 -0500
        Re: if cargo blocks Bart <bc@freeuk.com> - 2018-12-29 23:49 +0000
          Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 18:52 -0500
            Re: if cargo blocks Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-30 00:12 +0000
            Re: if cargo blocks rbowman <bowman@montana.com> - 2018-12-29 19:04 -0700
              Re: if cargo blocks Ralf Goertz <me@myprovider.invalid> - 2018-12-30 06:12 +0100
                Re: if cargo blocks David Brown <david.brown@hesbynett.no> - 2018-12-30 15:23 +0100
                  Language (Was: if cargo blocks) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-30 15:39 +0000
                    Re: Language (Was: if cargo blocks) rbowman <bowman@montana.com> - 2018-12-30 11:23 -0700
                  Re: if cargo blocks Ralf Goertz <me@myprovider.invalid> - 2018-12-31 05:21 +0100
                    Re: if cargo blocks David Brown <david.brown@hesbynett.no> - 2018-12-31 18:09 +0100
                      Re: if cargo blocks rbowman <bowman@montana.com> - 2018-12-31 12:22 -0700
                      Re: if cargo blocks Ralf Goertz <me@myprovider.invalid> - 2019-01-01 12:04 +0100
                    Re: if cargo blocks rbowman <bowman@montana.com> - 2018-12-31 11:50 -0700
                      Re: if cargo blocks Ralf Goertz <me@myprovider.invalid> - 2019-01-01 11:43 +0100
                        Re: if cargo blocks Ralf Goertz <me@myprovider.invalid> - 2019-01-01 14:27 +0100
                          German grammar (Was: if cargo blocks) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-01 14:17 +0000
                          Re: if cargo blocks rbowman <bowman@montana.com> - 2019-01-01 11:04 -0700
                            Re: if cargo blocks fir <profesor.fir@gmail.com> - 2019-01-01 10:38 -0800
                        Re: if cargo blocks rbowman <bowman@montana.com> - 2019-01-01 10:57 -0700
                          DDR Ralf Goertz <me@myprovider.invalid> - 2019-01-01 21:18 +0100
                            Re: DDR rbowman <bowman@montana.com> - 2019-01-01 16:18 -0700
                  Re: if cargo blocks Siri Cruise <chine.bleu@yahoo.com> - 2019-01-01 16:30 -0800
                Re: if cargo blocks rbowman <bowman@montana.com> - 2018-12-30 11:09 -0700
                  Re: if cargo blocks Ralf Goertz <me@myprovider.invalid> - 2018-12-31 05:43 +0100
                    Re: if cargo blocks rbowman <bowman@montana.com> - 2018-12-31 12:06 -0700
                Linguistics. Re: if cargo blocks Siri Cruise <chine.bleu@yahoo.com> - 2019-01-01 16:27 -0800
                  Re: Linguistics. Re: if cargo blocks rbowman <bowman@montana.com> - 2019-01-01 22:30 -0700
                    Re: Linguistics. Re: if cargo blocks Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2019-01-02 04:18 -0700
            Re: if cargo blocks Bart <bc@freeuk.com> - 2018-12-30 02:07 +0000
              Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 21:59 -0500
    Re: if cargo blocks rbowman <bowman@montana.com> - 2018-12-29 13:57 -0700
      Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 16:03 -0500
        Re: if cargo blocks Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-29 21:32 +0000
        Re: if cargo blocks rbowman <bowman@montana.com> - 2018-12-29 16:06 -0700
          Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 18:15 -0500
            Re: if cargo blocks fir <profesor.fir@gmail.com> - 2018-12-29 15:32 -0800
              Re: if cargo blocks fir <profesor.fir@gmail.com> - 2018-12-29 15:34 -0800
                Re: if cargo blocks fir <profesor.fir@gmail.com> - 2018-12-29 15:38 -0800
                Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 15:40 -0800
                  Re: if cargo blocks fir <profesor.fir@gmail.com> - 2018-12-29 15:45 -0800
              Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 18:36 -0500
                Re: if cargo blocks fir <profesor.fir@gmail.com> - 2018-12-29 15:42 -0800
                  Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 15:45 -0800
                    Re: if cargo blocks fir <profesor.fir@gmail.com> - 2018-12-29 15:54 -0800
                      Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 18:58 -0500
                        Re: if cargo blocks fir <profesor.fir@gmail.com> - 2018-12-29 16:01 -0800
      Re: if cargo blocks "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-29 13:36 -0800
    Re: if cargo blocks "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2018-12-29 13:16 -0800
      Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-29 16:32 -0500
    Re: if cargo blocks Siri Cruise <chine.bleu@yahoo.com> - 2018-12-30 13:00 -0800
      Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-30 16:12 -0500
        Re: if cargo blocks Siri Cruise <chine.bleu@yahoo.com> - 2018-12-30 13:31 -0800
          Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-30 16:45 -0500
            Re: if cargo blocks Bart <bc@freeuk.com> - 2018-12-30 22:17 +0000
              Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-30 17:22 -0500
                Re: if cargo blocks "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-30 20:25 -0800
    Re: if cargo blocks Ian Collins <ian-news@hotmail.com> - 2019-01-03 09:50 +1300
      Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-01-02 15:54 -0500
        Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-01-02 16:29 -0500
          Re: if cargo blocks mark.bluemel@gmail.com - 2019-01-03 00:44 -0800
            Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-01-03 08:17 -0500
              Re: if cargo blocks mark.bluemel@gmail.com - 2019-01-03 05:40 -0800
                Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-01-03 09:15 -0500
              You are so full of shit (Was: if cargo blocks) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-03 13:42 +0000
              Re: if cargo blocks fir <profesor.fir@gmail.com> - 2019-01-03 12:27 -0800
          Re: if cargo blocks Ian Collins <ian-news@hotmail.com> - 2019-01-04 11:11 +1300
            Re: if cargo blocks "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2019-01-03 14:37 -0800
            Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-01-03 17:48 -0500
            Re: if cargo blocks fir <profesor.fir@gmail.com> - 2019-01-03 14:59 -0800
        Re: if cargo blocks mark.bluemel@gmail.com - 2019-01-03 00:44 -0800
          Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-01-03 08:19 -0500
            Re: if cargo blocks mark.bluemel@gmail.com - 2019-01-03 05:43 -0800
              Re: if cargo blocks "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-01-03 05:51 -0800
            Re: if cargo blocks "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2019-01-03 13:22 -0800
        Re: if cargo blocks Ian Collins <ian-news@hotmail.com> - 2019-01-04 11:10 +1300

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

#139208 — if cargo blocks

I've had the idea for an "if cargo" block.  It is a standard if {}
block, but one containing additional cargo prefixed by in, out, and
enter keywords, to be contained within each if clause to run before,
after, and when entering the if statement.

The enter clause is given specifically to relate to something that
should be done, possibly to undo something done in the in clause,
including possibly calling the out clause to undo that setup, and
prepare it for whatever other code is needed within the block.

The cargo portion allows a sequence of conditions to be established
sequentially, in a traditional if{} block, with the ability to inject
new code at each stage to augment the environment, to then live-test
the condition.

     if (some_test1)
         in    { setup_for_test1 }
         out   { cleanup_for_test1 }
         enter { related_code_if_block_entered1 }
     {
         // Code1 here for this test passing

     } else if (some_test2)
         in    { setup_for_test2 }
         out   { cleanup_for_test2 }
         enter { related_code_if_block_entered2 }
     {
         // Code2 here for this test passing
     }

-----
The above would work out to this logic:

     setup_for_test1;
     if (some_test1)
     {
         related_code_if_block_is_entered1;
         // Code1 here for this test passing
         goto all_done;

     } else {
         cleanup_for_test1;
     }

     setup_for_test2;
     if (some_test2)
     {
         related_code_if_block_is_entered2;
         // Code2 here for this test passing

     } else {
         cleanup_for_test2;
     }
all_done:

-----
It allows code for setup_for_test, cleanup_for_test, and
related_code_if_block_entered to be encapsulated into its
intended meaning by placing it where it's used, related
to how it's being used, being easily understood as to what
it's really doing.

It also implicitly documents the purpose of that code nearby,
as being part of each if{} statement's prepare, test, cleanup
code.

-- 
Rick C. Hodgin

[toc] | [next] | [standalone]

#139209

On 29/12/2018 16:42, Rick C. Hodgin wrote:
> I've had the idea for an "if cargo" block.  It is a standard if {}
> block, but one containing additional cargo prefixed by in, out, and
> enter keywords, to be contained within each if clause to run before,
> after, and when entering the if statement.
> 
> The enter clause is given specifically to relate to something that
> should be done, possibly to undo something done in the in clause,
> including possibly calling the out clause to undo that setup, and
> prepare it for whatever other code is needed within the block.
> 
> The cargo portion allows a sequence of conditions to be established
> sequentially, in a traditional if{} block, with the ability to inject
> new code at each stage to augment the environment, to then live-test
> the condition.
> 
>      if (some_test1)
>          in    { setup_for_test1 }
>          out   { cleanup_for_test1 }
>          enter { related_code_if_block_entered1 }
>      {
>          // Code1 here for this test passing
> 
>      } else if (some_test2)
>          in    { setup_for_test2 }
>          out   { cleanup_for_test2 }
>          enter { related_code_if_block_entered2 }
>      {
>          // Code2 here for this test passing
>      }
> 
> -----
> The above would work out to this logic:
> 
>      setup_for_test1;
>      if (some_test1)
>      {
>          related_code_if_block_is_entered1;
>          // Code1 here for this test passing
>          goto all_done;
> 
>      } else {
>          cleanup_for_test1;
>      }
> 
>      setup_for_test2;
>      if (some_test2)
>      {
>          related_code_if_block_is_entered2;
>          // Code2 here for this test passing
> 
>      } else {
>          cleanup_for_test2;
>      }
> all_done:
> 
> -----
> It allows code for setup_for_test, cleanup_for_test, and
> related_code_if_block_entered to be encapsulated into its
> intended meaning by placing it where it's used, related
> to how it's being used, being easily understood as to what
> it's really doing.
> 
> It also implicitly documents the purpose of that code nearby,
> as being part of each if{} statement's prepare, test, cleanup
> code.
> 

If your suggestion works out to that code, why not just write that code? 
  It is simpler and clearer, and would make it obvious that the 
"cleanup" code is not called if the branch is taken.  And the "goto" can 
be avoided by using nested "if", or early returns, if that is what 
bothers you.

I am at a loss to understand why you want so many new syntaxes for 
different ways of writing the same code in different non-sequential orders.

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

#139210

On 29/12/2018 16:26, David Brown wrote:
> On 29/12/2018 16:42, Rick C. Hodgin wrote:
>> I've had the idea for an "if cargo" block.  It is a standard if {}
>> block, but one containing additional cargo prefixed by in, out, and
>> enter keywords, to be contained within each if clause to run before,
>> after, and when entering the if statement.
>>
>> The enter clause is given specifically to relate to something that
>> should be done, possibly to undo something done in the in clause,
>> including possibly calling the out clause to undo that setup, and
>> prepare it for whatever other code is needed within the block.
>>
>> The cargo portion allows a sequence of conditions to be established
>> sequentially, in a traditional if{} block, with the ability to inject
>> new code at each stage to augment the environment, to then live-test
>> the condition.
>>
>>      if (some_test1)
>>          in    { setup_for_test1 }
>>          out   { cleanup_for_test1 }
>>          enter { related_code_if_block_entered1 }
>>      {
>>          // Code1 here for this test passing
>>
>>      } else if (some_test2)
>>          in    { setup_for_test2 }
>>          out   { cleanup_for_test2 }
>>          enter { related_code_if_block_entered2 }
>>      {
>>          // Code2 here for this test passing
>>      }
>>
>> -----
>> The above would work out to this logic:
>>
>>      setup_for_test1;
>>      if (some_test1)
>>      {
>>          related_code_if_block_is_entered1;
>>          // Code1 here for this test passing
>>          goto all_done;
>>
>>      } else {
>>          cleanup_for_test1;
>>      }
>>
>>      setup_for_test2;
>>      if (some_test2)
>>      {
>>          related_code_if_block_is_entered2;
>>          // Code2 here for this test passing
>>
>>      } else {
>>          cleanup_for_test2;
>>      }
>> all_done:
>>
>> -----
>> It allows code for setup_for_test, cleanup_for_test, and
>> related_code_if_block_entered to be encapsulated into its
>> intended meaning by placing it where it's used, related
>> to how it's being used, being easily understood as to what
>> it's really doing.
>>
>> It also implicitly documents the purpose of that code nearby,
>> as being part of each if{} statement's prepare, test, cleanup
>> code.
>>
> 
> If your suggestion works out to that code, why not just write that code? 
>   It is simpler and clearer, and would make it obvious that the "cleanup" 
> code is not called if the branch is taken.  And the "goto" can be avoided 
> by using nested "if", or early returns, if that is what bothers you.
> 
> I am at a loss to understand why you want so many new syntaxes for 
> different ways of writing the same code in different non-sequential orders.

The problem is Rick doesn't understand how to use modern C++ properly.  He 
appears to be unaware of the RAII idiom and how it relates to scope bound 
resource management for example.  Rick is a classic case of DOING IT WRONG 
due to ignorance.

Rick is attempting to wallpaper over the gaps in his knowledge with his 
klunky "language extensions".

/Flibble

-- 
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who 
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – 
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are 
confronted by God," Bryne asked on his show The Meaning of Life. "What 
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery 
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a 
world that is so full of injustice and pain. That's what I would say."

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

#139211

On 29/12/2018 15:42, Rick C. Hodgin wrote:
> I've had the idea for an "if cargo" block.  It is a standard if {}
> block,

Which is easy to explain, easy to understand, and supported in pretty 
much every language.

  but one containing additional cargo prefixed by in, out, and
> enter keywords, to be contained within each if clause to run before,
> after, and when entering the if statement.

Which isn't.


>      if (some_test1)
>          in    { setup_for_test1 }
>          out   { cleanup_for_test1 }
>          enter { related_code_if_block_entered1 }

Wouldn't these be better as in, enter, out?

> The above would work out to this logic:

So, given:

        if (A) in {B} out {C} enter {D} {E}
   else if (F) in {G} out {H} enter {I} {J}

this is equivalent to:

        if (B; A) {D; E; C}
   else if (G; F) {I; J; H}   ?

(Standard C can't have statements inside a condition expression; gcc can.)

Notice how the equivalent code is shorter and easier to understand by 
anyone even if they have no idea cargo-if is.

My suggestion is, rather than invent many dozens of whacky features 
(largely incompatible with each other) is to either add more fundamental 
ones, such as being able to write 'if (B; A)', or to have one generic 
feature that allows things such as the above to be added (language 
building).

The latter has the advantage that the core language - apart from this 
feature - is smaller and simpler, and is faster and more practical to 
implement.



> -----
> It allows code for setup_for_test, cleanup_for_test, and
> related_code_if_block_entered to be encapsulated into its
> intended meaning by placing it where it's used, related
> to how it's being used, being easily understood as to what
> it's really doing.

You can already encapsulate any code inside {...}. You do need to have 
it in the right order, but it is an advantage if {A} {B} and {C} are 
executed in the order A, B and C.

-- 
bart

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

#139214

On 12/29/2018 11:56 AM, Bart wrote:
> On 29/12/2018 15:42, Rick C. Hodgin wrote:
>>      if (some_test1)
>>          in    { setup_for_test1 }
>>          out   { cleanup_for_test1 }
>>          enter { related_code_if_block_entered1 }
> 
> Wouldn't these be better as in, enter, out?

They're labeled.  They go in the correct flow order no matter what order
they appear in source code.

Another option that should be added for if cargo blocks is the ability
to continue testing at the next else-if/else condition.  I think it
should be "prevtest;" and "nexttest;" and "gotest label;" where label
by the name given to a block.  Also, the "out;" keyword which operates
like break; for a loop, except it works within the if blocks:

     if (x)
     {
         nexttest;       // Continues with the "else if (y)" test
         gotest zlabel;  // Go to the "else if (z)" test

     } else if (y) {
         // Code here
         prevtest;       // Retest "else if (y)" block
         gotest last;    // Go to the else block

     } else if (z) zlabel {
         if (whatever)
             out;        // Leave the if-block

     } else last {
         // Code here
     }

Note the above are all unconditional branches and will perform
their action when encountered, so in this example "gotest zlabel"
and "gotest last" would never be executed.  They are just examples
showing how branching could work from one place to another.

-- 
Rick C. Hodgin

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

#139234

On 29/12/2018 17:34, Rick C. Hodgin wrote:
> On 12/29/2018 11:56 AM, Bart wrote:
>> On 29/12/2018 15:42, Rick C. Hodgin wrote:
>>>      if (some_test1)
>>>          in    { setup_for_test1 }
>>>          out   { cleanup_for_test1 }
>>>          enter { related_code_if_block_entered1 }
>>
>> Wouldn't these be better as in, enter, out?
> 
> They're labeled.  They go in the correct flow order no matter what order
> they appear in source code.
> 
> Another option that should be added for if cargo blocks is the ability
> to continue testing at the next else-if/else condition.  I think it
> should be "prevtest;" and "nexttest;" and "gotest label;" where label
> by the name given to a block.  Also, the "out;" keyword which operates
> like break; for a loop, except it works within the if blocks:
> 
>      if (x)
>      {
>          nexttest;       // Continues with the "else if (y)" test
>          gotest zlabel;  // Go to the "else if (z)" test
> 
>      } else if (y) {
>          // Code here
>          prevtest;       // Retest "else if (y)" block
>          gotest last;    // Go to the else block
> 
>      } else if (z) zlabel {
>          if (whatever)
>              out;        // Leave the if-block
> 
>      } else last {
>          // Code here
>      }
> 
> Note the above are all unconditional branches and will perform
> their action when encountered, so in this example "gotest zlabel"
> and "gotest last" would never be executed.  They are just examples
> showing how branching could work from one place to another.

You've just reinvented spaghetti code I think. And loops.

But you don't need new features for that. I assume 'nexttest' and 
'prevtest' and 'gotest' are special kinds of gotos? How does it work 
with nested if/else statements?

Never mind; this is too much of a crazy idea to pursue further.

BTW here's how you can express your example in current C:

       if (x)
       {
           goto ylabel;    // Continues with the "else if (y)" test
           goto zlabel;    // Go to the "else if (z)" test

       } else ylabel: if (y) {
           // Code here
           goto ylabel;    // Retest "else if (y)" block
           goto last;      // Go to the else block

       } else zlabel: if (z) {
           if (whatever)
               goto out;   // Leave the if-block

       } else last: {
           // Code here
       }
out:;

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

#139235

On 12/29/2018 6:49 PM, Bart wrote:
> On 29/12/2018 17:34, Rick C. Hodgin wrote:
>> On 12/29/2018 11:56 AM, Bart wrote:
>>> On 29/12/2018 15:42, Rick C. Hodgin wrote:
>>>>      if (some_test1)
>>>>          in    { setup_for_test1 }
>>>>          out   { cleanup_for_test1 }
>>>>          enter { related_code_if_block_entered1 }
>>>
>>> Wouldn't these be better as in, enter, out?
>>
>> They're labeled.  They go in the correct flow order no matter what order
>> they appear in source code.
>>
>> Another option that should be added for if cargo blocks is the ability
>> to continue testing at the next else-if/else condition.  I think it
>> should be "prevtest;" and "nexttest;" and "gotest label;" where label
>> by the name given to a block.  Also, the "out;" keyword which operates
>> like break; for a loop, except it works within the if blocks:
>>
>>      if (x)
>>      {
>>          nexttest;       // Continues with the "else if (y)" test
>>          gotest zlabel;  // Go to the "else if (z)" test
>>
>>      } else if (y) {
>>          // Code here
>>          prevtest;       // Retest "else if (y)" block
>>          gotest last;    // Go to the else block
>>
>>      } else if (z) zlabel {
>>          if (whatever)
>>              out;        // Leave the if-block
>>
>>      } else last {
>>          // Code here
>>      }
>>
>> Note the above are all unconditional branches and will perform
>> their action when encountered, so in this example "gotest zlabel"
>> and "gotest last" would never be executed.  They are just examples
>> showing how branching could work from one place to another.
> 
> You've just reinvented spaghetti code I think. And loops.

The spaghetti code exists when you don't have in, out, and enter.  The
features I've added to CAlive, including flow {..} blocks, and now the
cargo blocks, remove spaghetti code, and place a direct type of flow
control to one's code without using gotos, without using anything other
than structured programming.

-- 
Rick C. Hodgin

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

#139239

On 29/12/2018 23:52, Rick C. Hodgin wrote:
> On 12/29/2018 6:49 PM, Bart wrote:
>> On 29/12/2018 17:34, Rick C. Hodgin wrote:
>>> On 12/29/2018 11:56 AM, Bart wrote:
>>>> On 29/12/2018 15:42, Rick C. Hodgin wrote:
>>>>>      if (some_test1)
>>>>>          in    { setup_for_test1 }
>>>>>          out   { cleanup_for_test1 }
>>>>>          enter { related_code_if_block_entered1 }
>>>>
>>>> Wouldn't these be better as in, enter, out?
>>>
>>> They're labeled.  They go in the correct flow order no matter what order
>>> they appear in source code.
>>>
>>> Another option that should be added for if cargo blocks is the ability
>>> to continue testing at the next else-if/else condition.  I think it
>>> should be "prevtest;" and "nexttest;" and "gotest label;" where label
>>> by the name given to a block.  Also, the "out;" keyword which operates
>>> like break; for a loop, except it works within the if blocks:
>>>
>>>      if (x)
>>>      {
>>>          nexttest;       // Continues with the "else if (y)" test
>>>          gotest zlabel;  // Go to the "else if (z)" test
>>>
>>>      } else if (y) {
>>>          // Code here
>>>          prevtest;       // Retest "else if (y)" block
>>>          gotest last;    // Go to the else block
>>>
>>>      } else if (z) zlabel {
>>>          if (whatever)
>>>              out;        // Leave the if-block
>>>
>>>      } else last {
>>>          // Code here
>>>      }
>>>
>>> Note the above are all unconditional branches and will perform
>>> their action when encountered, so in this example "gotest zlabel"
>>> and "gotest last" would never be executed.  They are just examples
>>> showing how branching could work from one place to another.
>>
>> You've just reinvented spaghetti code I think. And loops.
> 
> The spaghetti code exists when you don't have in, out, and enter.  The
> features I've added to CAlive, including flow {..} blocks, and now the
> cargo blocks, remove spaghetti code, and place a direct type of flow
> control to one's code without using gotos, without using anything other
> than structured programming.

Structured programming? Structured obfuscation more like. Again a totally 
batshit crazy idea that serves no useful purpose whatsoever.

/Flibble


-- 
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who 
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – 
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are 
confronted by God," Bryne asked on his show The Meaning of Life. "What 
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery 
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a 
world that is so full of injustice and pain. That's what I would say."

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

#139241

On 12/29/2018 04:52 PM, Rick C. Hodgin wrote:
> The spaghetti code exists when you don't have in, out, and enter.  The
> features I've added to CAlive, including flow {..} blocks, and now the
> cargo blocks, remove spaghetti code, and place a direct type of flow
> control to one's code without using gotos, without using anything other
> than structured programming.
>

I lived through the era when you had to place your hand over your heart 
and swear eternal allegiance to top down structured programming and 
promise to never use the evil GOTO.

Rather like the grammarian’s damnation of ending a sentence with a 
preposition it resulted in some of the most convoluted messes I've ever 
seen. The programming example is a bit more hypocritical since in most 
cases you want the compiler to do the dirty work.

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

#139244

Am Sat, 29 Dec 2018 19:04:28 -0700
schrieb rbowman <bowman@montana.com>:

> Rather like the grammarian’s damnation of ending a sentence with a
> preposition it resulted in some of the most convoluted messes I've
> ever seen. 

Although I have been communicating in English for quite a while now, I
heard about that damnation only rather recently. Does that mean you are
not supposed to say "What are you looking for?" but should say "For what
are you looking?" instead? The former /feels/ correct because I hear it
very often, I guess more often than the latter. But then I also very
often hear "What do you got?" in American TV shows which feels like a
horrible abuse of language…

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

#139245

On 30/12/2018 06:12, Ralf Goertz wrote:
> Am Sat, 29 Dec 2018 19:04:28 -0700
> schrieb rbowman <bowman@montana.com>:
> 
>> Rather like the grammarian’s damnation of ending a sentence with a
>> preposition it resulted in some of the most convoluted messes I've
>> ever seen.
> 
> Although I have been communicating in English for quite a while now, I
> heard about that damnation only rather recently. Does that mean you are
> not supposed to say "What are you looking for?" but should say "For what
> are you looking?" instead?

Yes, that is correct.

> The former /feels/ correct because I hear it
> very often, I guess more often than the latter. But then I also very
> often hear "What do you got?" in American TV shows which feels like a
> horrible abuse of language…
> 

It is a matter of philosophical debate whether the kind of grammatical 
abuse found on American TV shows is ignorance, laziness, or the 
evolution of language.

"To boldly go where no man has gone before" - is it bad grammar, or has 
it changed the language?

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

#139246 — Language (Was: if cargo blocks)

In article <q0akdp$74k$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
...
>It is a matter of philosophical debate whether the kind of grammatical 
>abuse found on American TV shows is ignorance, laziness, or the 
>evolution of language.

All of the above.

It's a race to the bottom.

>"To boldly go where no man has gone before" - is it bad grammar, or has 
>it changed the language?

Both.  All of the above.

-- 
If it seems like I'm not responding to some moronic criticism that you've
posted in response to one of my posts, be aware that I do not debate with idiots.

It doesn't mean you've won anything...

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

#139249 — Re: Language (Was: if cargo blocks)

On 12/30/2018 08:39 AM, Kenny McCormack wrote:
> In article <q0akdp$74k$1@dont-email.me>,
> David Brown  <david.brown@hesbynett.no> wrote:
> ...
>> It is a matter of philosophical debate whether the kind of grammatical
>> abuse found on American TV shows is ignorance, laziness, or the
>> evolution of language.
> All of the above.

I doubt if it is limited to American TV. Besides, most of our actors are 
Brits or Aussies :)

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

#139272

Am Sun, 30 Dec 2018 15:23:53 +0100
schrieb David Brown <david.brown@hesbynett.no>:

> On 30/12/2018 06:12, Ralf Goertz wrote:
> > Am Sat, 29 Dec 2018 19:04:28 -0700
> > schrieb rbowman <bowman@montana.com>:
> >   
> >> Rather like the grammarian’s damnation of ending a sentence with a
> >> preposition it resulted in some of the most convoluted messes I've
> >> ever seen.  
> > 
> > Although I have been communicating in English for quite a while
> > now, I heard about that damnation only rather recently. Does that
> > mean you are not supposed to say "What are you looking for?" but
> > should say "For what are you looking?" instead?  
> 
> Yes, that is correct.

Hm, grammar girl seems to have a different opinion: https://www.quickanddirtytips.com/education/grammar/ending-a-sentence-with-a-preposition

BTW (to answer Stefan's SCNR), this is exactly the reason why I asked my
question here in a programming newsgroup. Here, there are many
intelligent native speakers whose focus is probably not grammar. Their
gut feeling about their language is quite a valuable input for me to
develop my own gut feeling. Although I must admit that I will never have
as strong a gut feeling for English as I have for my own language.
 
> > The former /feels/ correct because I hear it
> > very often, I guess more often than the latter. But then I also very
> > often hear "What do you got?" in American TV shows which feels like
> > a horrible abuse of language…
> >   
> 
> It is a matter of philosophical debate whether the kind of
> grammatical abuse found on American TV shows is ignorance, laziness,
> or the evolution of language.
> 
> "To boldly go where no man has gone before" - is it bad grammar, or
> has it changed the language?

It took my quite a while to figure out what could be objectionable in
that sentence. It seems to be the rule not to split an infinitive, a
rule about which I had no idea two days ago. (Apart from "Manner, space,
time makes your English fine" I don't remember being taught any style
rule at school.) Interestingly, for me both ending with a preposition
and splitting an infinitive feel very "English" probably because there
is no way you could use either construct in a German sentence.

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

#139284

On 31/12/2018 05:21, Ralf Goertz wrote:
> Am Sun, 30 Dec 2018 15:23:53 +0100
> schrieb David Brown <david.brown@hesbynett.no>:
> 
>> On 30/12/2018 06:12, Ralf Goertz wrote:
>>> Am Sat, 29 Dec 2018 19:04:28 -0700
>>> schrieb rbowman <bowman@montana.com>:
>>>    
>>>> Rather like the grammarian’s damnation of ending a sentence with a
>>>> preposition it resulted in some of the most convoluted messes I've
>>>> ever seen.
>>>
>>> Although I have been communicating in English for quite a while
>>> now, I heard about that damnation only rather recently. Does that
>>> mean you are not supposed to say "What are you looking for?" but
>>> should say "For what are you looking?" instead?
>>
>> Yes, that is correct.
> 
> Hm, grammar girl seems to have a different opinion: https://www.quickanddirtytips.com/education/grammar/ending-a-sentence-with-a-preposition
> 

That article seems to be saying two things - both of which are 
reasonable, IMHO.  One is that it is common usage - and therefore part 
of the language - to end a sentence in a preposition when the 
alternative is particularly awkward.  The other is that in some cases, 
the preposition is part of a phrase, rather than joining two things.

What you really should avoid is prepositions that are either 
superfluous, or leave information unsaid.  For example, "I hadn't read 
about that before".  The "before" means nothing here - before what?  The 
sentence would make more sense as simply "I hadn't read about that", or 
alternatively with more information, such as "I hadn't read about that 
before yesterday".


> BTW (to answer Stefan's SCNR), this is exactly the reason why I asked my
> question here in a programming newsgroup. Here, there are many
> intelligent native speakers whose focus is probably not grammar. Their
> gut feeling about their language is quite a valuable input for me to
> develop my own gut feeling. Although I must admit that I will never have
> as strong a gut feeling for English as I have for my own language.
>   
>>> The former /feels/ correct because I hear it
>>> very often, I guess more often than the latter. But then I also very
>>> often hear "What do you got?" in American TV shows which feels like
>>> a horrible abuse of language…
>>>    
>>
>> It is a matter of philosophical debate whether the kind of
>> grammatical abuse found on American TV shows is ignorance, laziness,
>> or the evolution of language.
>>
>> "To boldly go where no man has gone before" - is it bad grammar, or
>> has it changed the language?
> 
> It took my quite a while to figure out what could be objectionable in
> that sentence. It seems to be the rule not to split an infinitive, a
> rule about which I had no idea two days ago. (Apart from "Manner, space,
> time makes your English fine" I don't remember being taught any style
> rule at school.) Interestingly, for me both ending with a preposition
> and splitting an infinitive feel very "English" probably because there
> is no way you could use either construct in a German sentence.
> 

English grammar is based on a mix of Germanic and Latin grammar, with 
some of its own variations.  In both German and Latin (AFAIK) 
infinitives are formed by verb endings - there is no way to "split" 
them.  This may be the origin of the rule in English.

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

#139294

On 12/31/2018 10:09 AM, David Brown wrote:
> English grammar is based on a mix of Germanic and Latin grammar, with
> some of its own variations.  In both German and Latin (AFAIK)
> infinitives are formed by verb endings - there is no way to "split"
> them.  This may be the origin of the rule in English.

Not necessarily infinitives but German makes an art form of verb 
splitting. In a complex sentence the main bodies of the verbs pile up at 
the end, with the tense signifier as a place holder in the sentence.

In programming speak you push a bunch of qualifiers on the stack and 
then pop them off at the end to figure out who was doing what when.

It's been a long time but iirc Latin has a complex system for forming 
infinitives depending on the tense and voice.

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

#139320

Am Mon, 31 Dec 2018 18:09:51 +0100
schrieb David Brown <david.brown@hesbynett.no>:

> On 31/12/2018 05:21, Ralf Goertz wrote:
>> Am Sun, 30 Dec 2018 15:23:53 +0100 schrieb David Brown
>> <david.brown@hesbynett.no>:

>>> "To boldly go where no man has gone before" - is it bad grammar, or
>>> has it changed the language?  
>> 
>> It took my quite a while to figure out what could be objectionable in
>> that sentence. It seems to be the rule not to split an infinitive, a
>> rule about which I had no idea two days ago. (Apart from "Manner,
>> space, time makes your English fine" I don't remember being taught
>> any style rule at school.) Interestingly, for me both ending with a
>> preposition and splitting an infinitive feel very "English" probably
>> because there is no way you could use either construct in a German
>> sentence. 
> 
> English grammar is based on a mix of Germanic and Latin grammar, with 
> some of its own variations.  In both German and Latin (AFAIK) 
> infinitives are formed by verb endings - there is no way to "split" 
> them.  This may be the origin of the rule in English.

Correct, German infinitives always end in -en with the (only?) exception
of "sein" ("to be") and usually differ frome their inflections. But
there is a language construct called (extended) infinitive with
"zu" ("to"). With that the famous Star Strek slogan could be translated
"(Sie zogen aus, um) mutig dahin /zu gehen/, wohin niemand jemals
gegangen ist." The "zu" in that case is mandatory and there is no way
you could ever put anything between "zu" and "gehen" let alone "mutig".
On the other hand I would have considered "to boldly go" very good
English a few days ago…

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

#139292

On 12/30/2018 09:21 PM, Ralf Goertz wrote:
> Interestingly, for me both ending with a preposition
> and splitting an infinitive feel very "English" probably because there
> is no way you could use either construct in a German sentence.

Is 'Wo gehen Sie hin?' or splitting 'davon' acceptable? I have the 
opposite problem to you. When I read Schwedenkrimi I'm not sure if it is 
acceptable current usage or just crime novel slang. ( Scandinavian crime 
novels usually are translated to German before English, if they ever do 
get translated.)

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

#139319

Am Mon, 31 Dec 2018 11:50:39 -0700
schrieb rbowman <bowman@montana.com>:

> On 12/30/2018 09:21 PM, Ralf Goertz wrote:
> > Interestingly, for me both ending with a preposition
> > and splitting an infinitive feel very "English" probably because
> > there is no way you could use either construct in a German
> > sentence.  
> 
> Is 'Wo gehen Sie hin?' or splitting 'davon' acceptable?

Okay, I didn't think about that (spitting). "Wo gehen Sie hin" is
acceptable but "Wohin gehen Sie?" is slightly better imho. "Davon" like
"dafür" should not be splitted I think. "Da habe ich genug von" is
awkward. The only exception would be the very colloquial "Da nich(t)
für" meaning "Don't mention it" as a reply after being thanked for
something. But that deliberately plays with the awkwardness of the word
order/splitting which is why one would also normally omit the t.

> I have the opposite problem to you. When I read Schwedenkrimi I'm not
> sure if it is acceptable current usage or just crime novel slang.
> (Scandinavian crime novels usually are translated to German before
> English, if they ever do get translated.)

I'm not familiar with that particular genre but the word itself is just
used to stress the fact that Swedish crime novels are often dark or deep
and sometimes brutal. I think it's mainly used in marketing as some kind
of seal of quality.

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

#139322

Am Tue, 1 Jan 2019 11:43:51 +0100
schrieb Ralf Goertz <me@myprovider.invalid>:

> Am Mon, 31 Dec 2018 11:50:39 -0700
> schrieb rbowman <bowman@montana.com>:
> 
> > On 12/30/2018 09:21 PM, Ralf Goertz wrote:  
> > > Interestingly, for me both ending with a preposition
> > > and splitting an infinitive feel very "English" probably because
> > > there is no way you could use either construct in a German
> > > sentence.    
> > 
> > Is 'Wo gehen Sie hin?' or splitting 'davon' acceptable?  
> 
> Okay, I didn't think about that (spitting). "Wo gehen Sie hin" is
> acceptable but "Wohin gehen Sie?" is slightly better imho.

On second thought I doubt that this really is an example of splitting
"wohin" but of "hingehen". It is not so obvious here because of the
ambiguity. But when you say "Gehen Sie hin!" and the similar "Sie sollen
hingehen!" there is no "wo" the "hin" could have been cut from (from
which the "hin" could have been cut ;-)). Furthermore, according to the
Duden neither "hin" nor "davon" are prepositions but adverbs. So I guess
my initial assumption of no preposition in the end of a German sentence
still holds.

PS: I probably misread your entire post. Now I think you asked when (or
whether at all) it is acceptable to split verbs in German. Short answer:
as with the piling up of verbs in the end of a subordinate sentence or
one that is in present or past perfect it is more common to have to
split composite verbs. But not always. You say "Er /trennt/ die
Briefmarke (vom Brief) /ab/" but "Er /durchtrennt/ die Stromleitungen"…

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

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

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

csiph-web