- Add integer value 38 operator ~..~ - 3 Updates
- if cargo blocks - 20 Updates
- Multi-channel rand() - 2 Updates
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 29 03:48PM -0800 On 12/28/2018 8:35 AM, Mr Flibble wrote: > I propose the addition of the following operator to C++ (and also for my > own amazing C/C++-like language I am working on due to mental illness): > Add integer value 38 operator: ~..~ Amazing! > (~..~-(~..~/~..~))n; // 37 + n > With the help of the one true god (The Flying Spaghetti Monster) I hope > this important proposal is ratified by the C++ ISO committee. Does ((~..~/~..~)*80 - ~..~) = 42? ;^) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 30 06:00PM On Fri, 2018-12-28, Mr Flibble wrote: > I propose the addition of the following operator to C++ (and also for my > own amazing C/C++-like language I am working on due to mental illness): > Add integer value 38 operator: ~..~ [snip] That was funny, but I liked part of your .sig better: > "You won't burn in hell. But be nice anyway." Ricky Gervais /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 30 06:34PM -0500 On 12/30/2018 6:21 PM, Chris M. Thomasson wrote: > Wow. Really? Just, wow. > What a nice message. Wow. You think these things because you don't know scripture. You don't know what's coming. You don't have a clue who God is. You don't have a clue what your sin has cost you. You don't have a clue about anything related to the spirit. All you know is the flesh, Chris. The flesh is corrupt in sin, totally deceived by the enemy. THE ONLY WAY OUT is to seek the truth, which is to say seek Jesus Christ (because He is truth -- John 14:6). I've said before I wish I could shake you and wake you up out of this slumber you're in, this nonchalance about life. I don't want to do any physical harm, but I want to wake you up so you realize what it is you're just glossing over so mistakenly carelessly today. Breaks my heart to see it ... such flippance. It's going to cost you your eternal soul unless you wake up. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 29 10:42AM -0500 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 |
| David Brown <david.brown@hesbynett.no>: Dec 29 05:26PM +0100 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 <flibbleREMOVETHISBIT@i42.co.uk>: Dec 29 04:32PM On 29/12/2018 16:26, David Brown wrote: > 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." |
| Bart <bc@freeuk.com>: Dec 29 04:56PM 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. > 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. > 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 |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 29 12:34PM -0500 On 12/29/2018 11:56 AM, Bart wrote: >> 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 |
| rbowman <bowman@montana.com>: Dec 29 01:57PM -0700 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" <rick.c.hodgin@gmail.com>: Dec 29 04:03PM -0500 On 12/29/2018 3:57 PM, rbowman wrote: > 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. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 29 09:32PM 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 -- "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." |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 29 01:36PM -0800 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 <bowman@montana.com>: Dec 29 04:06PM -0700 On 12/29/2018 02:03 PM, Rick C. Hodgin wrote: >> 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? 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" <rick.c.hodgin@gmail.com>: Dec 29 06:15PM -0500 On 12/29/2018 6:06 PM, rbowman wrote: >> 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. 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. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 29 06:52PM -0500 On 12/29/2018 6:49 PM, Bart wrote: >> 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 |
| Bart <bc@freeuk.com>: Dec 29 11:49PM 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:; |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 30 12:12AM On 29/12/2018 23:52, Rick C. Hodgin wrote: > 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." |
| rbowman <bowman@montana.com>: Dec 29 07:04PM -0700 On 12/29/2018 04:52 PM, Rick C. Hodgin wrote: > 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. |
| Bart <bc@freeuk.com>: Dec 30 02:07AM On 29/12/2018 23:52, Rick C. Hodgin wrote: > 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. 'gotest' is not a kind of goto? Without goto, then with the form of if-else chain above, exactly one branch is expected to be executed each time you enter the first 'if'. And it will continue execution (subject to break, continue, return, exit() or longjmp()) following the final }. As for the execution path of your example, it's anyone's guess. After 'if' is entered, more than one block could be executed, and a block could be executed multiple times. Structured programming it isn't. -- bart |
| Ralf Goertz <me@myprovider.invalid>: Dec 30 06:12AM +0100 Am Sat, 29 Dec 2018 19:04:28 -0700 > 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… |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 30 04:12PM -0500 On 12/30/2018 4:00 PM, Siri Cruise wrote: > })) { > ... > } So the general concept of encapsulation of this code is not such a bad idea ... GNU added similar features. Good to know. -- Rick C. Hodgin |
| Siri Cruise <chine.bleu@yahoo.com>: Dec 30 01:31PM -0800 In article <q0bc9c$qln$1@dont-email.me>, > > } > So the general concept of encapsulation of this code is not such a bad > idea ... GNU added similar features. Good to know. In 1968 you could've done if setup_for_test1; bool test = some_test1; if test then related_code_if_block_entered1 fi; cleanup_for_test1; test then ... fi -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| Bart <bc@freeuk.com>: Dec 30 10:17PM On 30/12/2018 21:45, Rick C. Hodgin wrote: > them in certain cases ... they'll be there. I probably won't use > many of the new features I'm adding most of the time, but I will > probably use most of them some of the time. The reference is to Algol68 where there is no distinction between statements and expressions, which could be used interchangeably. This is what I meant the other day about adding fewer, more general, broader features rather than dozens of very specific ones. Actually, my language until about six or so years ago worked exactly the same way. My newer one doesn't - it is more conservative and limited by design. Because (1) I hardly ever used those features; (2) avoiding them leads to easier-to-understand code IMO; (3) it makes code and algorithms more portable; (4) it makes the language easier to implement; (5) it makes it easier to trap a range of errors that otherwise have to be let through. -- bart |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 30 08:10PM On Thu, 2018-12-27, Keith Thompson wrote: > POSIX.1-2001, POSIX.1-2008, 4.3BS > It's defined by POSIX, but not by ISO C (which is what Bart > presumably meant by "standard library"). Also, the "multi-channel" aspect is a bit inconvenient: it's still global state, but you can switch it. Not good for e.g. threaded use, or for people like me who like objects. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 30 04:10PM -0500 On 12/30/18 15:10, Jorgen Grahn wrote: > On Thu, 2018-12-27, Keith Thompson wrote: ... > global state, but you can switch it. Not good for e.g. threaded > use, or for people like me who like objects. > /Jorgen The page in the POSIX specification for random() says "Threaded applications should use erand48(), nrand48(), or jrand48() instead of random() when an independent random number sequence in multiple threads is required." |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment