experchange > cpp

Rick C. Hodgin (12-29-18, 05:42 PM)
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.
David Brown (12-29-18, 06:26 PM)
On 29/12/2018 16:42, Rick C. Hodgin wrote:
[..]
> 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.
Mr Flibble (12-29-18, 06:32 PM)
On 29/12/2018 16:26, David Brown wrote:
> On 29/12/2018 16:42, Rick C. Hodgin wrote:
> 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
fir (12-29-18, 06:48 PM)
W dniu sobota, 29 grudnia 2018 17:32:18 UTC+1 użytkownik Mr Flibble napisał:
> On 29/12/2018 16:26, David Brown wrote:
> 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 dik is rather clasic case of idiot posessed by devil


devil must dont like usenet if sents posessed idiots to fight with usenet here (ramine..hodgin.. )
Bart (12-29-18, 06:56 PM)
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.
Rick C. Hodgin (12-29-18, 07:34 PM)
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.
rbowman (12-29-18, 10:57 PM)
On 12/29/2018 08:42 AM, Rick C. Hodgin wrote:
> I've had the idea for an "if cargo" block.


As my father used to say 'If it ain't broke, don't f*ck with it.'

You do realize your ideas are confusing semantic sugar for operations
that can be done much more transparently?
Rick C. Hodgin (12-29-18, 11:03 PM)
On 12/29/2018 3:57 PM, rbowman wrote:
> On 12/29/2018 08:42 AM, Rick C. Hodgin wrote:
>> I've had the idea for an "if cargo" block.

> As my father used to say 'If it ain't broke, don't .. with it.'
> You do realize your ideas are confusing semantic sugar for operations that
> can be done much more transparently?


Do you realize you're harming yourself and many people with the words
you use in your writing?

I disagree with this type of feature being semantic sugar. I think
there is value in encapsulation and in relating code. It extends to
a larger vision I have for how code should be written, but this is a
part and parcel of that larger vision.

I offer it for scrutiny by others in C/C++ groups so that those who
write compilers could consider the idea, and then reject it, alter it
and use it, or accept as is.

It's everyone's choice. I offer these ideas to spark thought, engage
conversation and discussion, etc.
Mr Flibble (12-29-18, 11:32 PM)
On 29/12/2018 21:03, Rick C. Hodgin wrote:
> It's everyone's choice.  I offer these ideas to spark thought, engage
> conversation and discussion, etc.


Bullshit; you offer these "ideas" for no other reason than to satisfy a
self indulgent attention seeking need.

/Flibble
Chris M. Thomasson (12-29-18, 11:36 PM)
On 12/29/2018 12:57 PM, rbowman wrote:
> On 12/29/2018 08:42 AM, Rick C. Hodgin wrote:
>> I've had the idea for an "if cargo" block.

> As my father used to say 'If it ain't broke, don't f*ck with it.'


:^D
rbowman (12-30-18, 01:06 AM)
On 12/29/2018 02:03 PM, Rick C. Hodgin wrote:
> On 12/29/2018 3:57 PM, rbowman wrote:
> Do you realize you're harming yourself and many people with the words
> you use in your writing?


Ask me if I give a ... Well, you get the idea. I'm old, grumpy, and I
don't suffer fools gladly.
Rick C. Hodgin (12-30-18, 01:15 AM)
On 12/29/2018 6:06 PM, rbowman wrote:
> On 12/29/2018 02:03 PM, Rick C. Hodgin wrote:
> Ask me if I give a ...  Well, you get the idea. I'm old, grumpy, and I don't
> suffer fools gladly.


People don't have to remain that way (grumpy). There is a way to be
as new again ... one filled with love, hope, peace, and overflowing
joy. It's the one I teach you about, the one you call me a fool for.
Bart (12-30-18, 01:49 AM)
On 29/12/2018 17:34, Rick C. Hodgin wrote:
[..]
> 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:;
Rick C. Hodgin (12-30-18, 01:52 AM)
On 12/29/2018 6:49 PM, Bart wrote:
> On 29/12/2018 17:34, Rick C. Hodgin wrote:
> 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.
Mr Flibble (12-30-18, 02:12 AM)
On 29/12/2018 23:52, Rick C. Hodgin wrote:
> On 12/29/2018 6:49 PM, Bart 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.


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

/Flibble

Similar Threads