00:16:56 <esowiki> [[Human Resource Code]] M https://esolangs.org/w/index.php?diff=73408&oldid=68416 * PythonshellDebugwindow * (+97)
00:34:39 -!- adu has quit (Quit: adu).
00:35:08 -!- imode has joined.
00:36:16 -!- adu has joined.
01:02:04 -!- adu has quit (Ping timeout: 258 seconds).
01:07:37 <esowiki> [[Special:Log/newusers]] create * Bigyihsuan * New user account
01:10:16 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=73409&oldid=73356 * Bigyihsuan * (+313) introduce bigyihsuan
01:17:00 -!- adu has joined.
01:48:04 -!- sprocklem has quit (Quit: brb).
01:48:38 -!- sprocklem has joined.
02:05:17 -!- sprocklem has quit (Quit: brb).
02:05:43 -!- sprocklem has joined.
03:38:10 <Sgeo> Reading http://exple.tive.org/blarg/2013/10/22/citation-needed/
03:38:24 <Sgeo> (About why most languages start indexing at 0)
03:45:21 <Sgeo> https://python-history.blogspot.com/2013/10/why-python-uses-0-based-indexing.html
03:46:40 <zzo38> I think zero based indexing has many advantages, although sometimes it is useful to specify a range that starts at whatever number you want (which is possible in BASIC, and I think also in Pascal).
03:52:56 <zzo38> (BASIC does allow negative numbers in the range too, which is also useful, I think. But I think that you do not need fractions in array indices.)
03:53:41 <shachaf> zzo38: Do you like Macintosh Pascal?
03:55:06 <zzo38> I don't know; I didn't use Macintosh Pascal; I only used the Pascal on DOS (and even then, only on a computer with Linux, not DOS).
03:56:19 <shachaf> Someone mentioned that it has a feature where nested functions can return out of their enclosing functions.
03:57:17 <zzo38> Yes, that makes sense (if it can be suitably implemented).
04:09:42 -!- craigo has joined.
04:14:56 -!- MDead has joined.
04:17:17 -!- rain1 has joined.
04:17:54 -!- MDude has quit (Ping timeout: 256 seconds).
04:18:01 -!- MDead has changed nick to MDude.
04:34:23 <esowiki> [[Heebolang]] https://esolangs.org/w/index.php?diff=73410&oldid=73407 * Polybagel * (+1191)
04:35:36 <esowiki> [[Heebolang]] https://esolangs.org/w/index.php?diff=73411&oldid=73410 * Polybagel * (+17)
04:40:41 <esowiki> [[Heebolang]] M https://esolangs.org/w/index.php?diff=73412&oldid=73411 * Polybagel * (+2)
04:43:21 <esowiki> [[Heebolang]] https://esolangs.org/w/index.php?diff=73413&oldid=73412 * Polybagel * (+251)
04:58:47 <zzo38> Some things are missing from the Computer Modern fonts, such as thorn letter, blackboard bold, and a few others
05:37:49 -!- CylonT800 has joined.
06:10:46 -!- adu has quit (Quit: adu).
06:30:49 -!- imode has quit (Ping timeout: 264 seconds).
06:34:13 -!- CylonT800 has quit (Quit: Leaving.).
06:47:21 <zzo38> METAFONT has the feature that you can put if blocks and for loops anywhere, including inside of expressions, such as: (1 for n=1 upto y: *x endfor)
07:08:28 <rain1> nice feature, scheme has that too
07:41:41 -!- TheLie has joined.
08:03:23 <esowiki> [[Fading Rainbow]] https://esolangs.org/w/index.php?diff=73414&oldid=73370 * Ais523 * (+384) this is TC (via compiling 01-2C into it)
08:15:59 -!- cpressey has joined.
08:22:50 -!- TheLie has quit (Remote host closed the connection).
08:25:31 -!- LKoen has joined.
08:33:21 -!- Phantom_Hoover has joined.
08:41:12 <fizzie> Well, you know, some dialects of C do too.
08:41:14 <fizzie> `cc #include <stdio.h> \n int main(void) { printf("%d", ({ int s = 0; for (int i = 1; i <= 5; i++) s += i; s; })); }
08:50:27 <myname> so for _IS_ an expression but cannot work with statements in its condition?
08:51:35 <fizzie> If you mean the C example, that's just a GCC extension. It works anywhere an expression does.
08:54:13 <fizzie> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html for the record.
09:19:50 -!- Sgeo has quit (Read error: Connection reset by peer).
10:38:13 -!- cpressey has quit (Ping timeout: 246 seconds).
10:39:19 -!- cpressey has joined.
11:11:11 -!- sftp has quit (Ping timeout: 260 seconds).
11:11:40 -!- sftp has joined.
11:12:00 -!- Lord_of_Life_ has joined.
11:15:13 -!- Lord_of_Life has quit (Ping timeout: 264 seconds).
11:15:14 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
11:16:06 <int-e> So what's this really... a basic block whose final statement is an expression is an expression itself...
11:16:56 <int-e> (will check the link for proper terminology)
11:40:32 -!- TheLie has joined.
11:41:48 <rain1> https://store.steampowered.com/app/917900/Monster_Logic/
11:41:57 <rain1> Based on esoteric languages Befunge and Trefunge
11:42:06 -!- APic has quit (Ping timeout: 256 seconds).
11:44:27 -!- APic has joined.
11:44:32 -!- Lord_of_Life has quit (Remote host closed the connection).
11:45:56 -!- Lord_of_Life has joined.
11:55:56 -!- arseniiv_ has joined.
11:57:28 -!- cpressey has quit (Quit: WeeChat 1.9.1).
12:10:27 <b_jonas> int-e: no, you have to parenthisize it and then it's an exception, but only in gcc
12:19:38 <int-e> b_jonas: ({ triggers my brain differently actually. ({ 1,2,3 }) constructs a 3 element array in LPC (and presumably Pike).
12:23:53 -!- adu has joined.
12:29:52 <esowiki> [[BrainSoothe]] N https://esolangs.org/w/index.php?oldid=73415 * Arseniiv * (+1776) this is bs
12:31:12 -!- arseniiv_ has changed nick to arseniiv.
12:32:52 <int-e> arseniiv: BFF = brainfuck forever
12:32:57 <arseniiv> at last I’m enacted my revenge and in a not-so-unclassy way. Though I’m not sure at all that is TC
12:41:32 -!- TheLie has quit (Remote host closed the connection).
12:52:00 -!- izabera has quit (Killed (Sigyn (Stay safe off irc))).
12:57:32 <b_jonas> int-e: in C the syntax for that is (sometype){constructor elements}
12:57:51 <b_jonas> you can't parenthisize the braces (except in C++, but even then you need a type before it)
12:58:10 -!- izabera has joined.
13:01:17 <esowiki> [[BrainSoothe]] M https://esolangs.org/w/index.php?diff=73416&oldid=73415 * Int-e * (+3) why did I read this
13:02:18 <esowiki> [[Carriage/Carriage.hs]] M https://esolangs.org/w/index.php?diff=73417&oldid=34757 * PythonshellDebugwindow * (+29) clearer linkback
13:02:32 <esowiki> [[Carriage/Carriage.hs]] M https://esolangs.org/w/index.php?diff=73418&oldid=73417 * PythonshellDebugwindow * (+0)
13:02:57 <esowiki> [[Carriage/Carriage.hs]] M https://esolangs.org/w/index.php?diff=73419&oldid=73418 * PythonshellDebugwindow * (+0)
13:04:55 <esowiki> [[BrainSoothe]] https://esolangs.org/w/index.php?diff=73420&oldid=73416 * Arseniiv * (+830)
13:05:33 <arseniiv> int-e: thanks though the merge conflict made me re-copy some things but that’s okay
13:08:19 -!- cpressey has joined.
13:08:49 <arseniiv> oh wait I was to edit “Define x mod 0 := x” to “… = …” to not resemble an assignment but I edited something else it seems
13:08:49 <esowiki> [[Carriage/carriage.ml]] M https://esolangs.org/w/index.php?diff=73421&oldid=34759 * PythonshellDebugwindow * (+52)
13:09:19 <esowiki> [[Carriage/carriage.ml]] M https://esolangs.org/w/index.php?diff=73422&oldid=73421 * PythonshellDebugwindow * (-11)
13:11:00 <esowiki> [[Carriage/Carriage.hs]] M https://esolangs.org/w/index.php?diff=73423&oldid=73419 * PythonshellDebugwindow * (+56) see also
13:11:49 <esowiki> [[BrainSoothe]] M https://esolangs.org/w/index.php?diff=73424&oldid=73420 * Arseniiv * (+8) no more no more sweet music
13:15:46 <arseniiv> ah, now I see why my changes except pseudocode insertion didn’t apply: I used the wrong tab
13:16:56 <esowiki> [[BrainSoothe]] M https://esolangs.org/w/index.php?diff=73425&oldid=73424 * PythonshellDebugwindow * (+13) /* Pseudocode */ typing
13:21:32 <arseniiv> hey what do you think you are doing
13:23:38 <int-e> what's with the changed return statement
13:24:04 <int-e> The rest looks like it might actually make the code work? I don't know.
13:30:12 <arseniiv> yes though Sequence was there for a reason
13:30:35 <arseniiv> also I found out I ended up with a language which outputs always 0
13:35:34 <catern> shachaf: I guess that neato is in regard to that link I sent you?
13:37:37 <esowiki> [[BrainSoothe]] https://esolangs.org/w/index.php?diff=73426&oldid=73425 * Arseniiv * (+56) I used `Sequence` for a reason, and the output should be, well, outputted
13:46:54 <cpressey> "There should be no literals at different positions which denote the same number." -- does that mean 'assert len(instructions) == len(set(instructions))' ?
13:54:13 <int-e> arseniiv: yeah that's not TC
13:54:42 <cpressey> (I'm pretty sure it does, I'm mainly wondering if that line should be in the program to emphasise that part of the definition formally)
13:56:16 <int-e> arseniiv: At least as far as I can see. The (mod 0) instruction is just a nop, and we can always reduce x modulo all the lcm of all the other numbers.
13:58:13 <arseniiv> cpressey: yeah it would be good. At first I added assertions about the length and nonnegativity but then scraped it because I forgot one can assert uniqueness as simple as you shown
13:58:16 <esowiki> [[BrainSoothe]] M https://esolangs.org/w/index.php?diff=73427&oldid=73426 * PythonshellDebugwindow * (+34) /* Pseudocode */ Sequence is an import
13:59:16 <arseniiv> I don’t even want to see what they’ve done this time
13:59:40 <arseniiv> I should’ve made that page my user’s subpage
14:00:19 <esowiki> [[? $51=]] M https://esolangs.org/w/index.php?diff=73428&oldid=65097 * PythonshellDebugwindow * (-144) rm Example rows
14:01:10 <arseniiv> int-e: seems so. For some reason I haven’t thought a simple lcm would kill it all :D
14:03:22 <esowiki> [[Emoji-gramming]] M https://esolangs.org/w/index.php?diff=73429&oldid=55194 * PythonshellDebugwindow * (+6) bold title
14:04:31 <esowiki> [[~English]] M https://esolangs.org/w/index.php?diff=73430&oldid=65546 * PythonshellDebugwindow * (+7)
14:04:34 <int-e> arseniiv: Now if (mod 0) actually resulted in an observable test for 0...
14:04:46 <esowiki> [[~English]] M https://esolangs.org/w/index.php?diff=73431&oldid=73430 * PythonshellDebugwindow * (+27) /* External resources */ cat
14:05:01 <int-e> then I don't really know what would happen.
14:05:37 <int-e> Probably still just a single counter Minsky machine.
14:09:52 <arseniiv> yeah I didn’t thought that (mod 0) would end up a complete noop
14:11:57 <int-e> arseniiv: you can still pull a George Lucas and replace the language by something different, I mean better :P
14:11:57 <esowiki> [[Human's mind have sex with someone]] M https://esolangs.org/w/index.php?diff=73432&oldid=66508 * PythonshellDebugwindow * (+190)
14:12:55 <arseniiv> though I’d wanted it to be of a similar simplicity
14:14:51 <b_jonas> int-e: single-counter Minsky machine? aren't those basically just finite state machines?
14:17:42 <esowiki> [[BrainSoothe]] M https://esolangs.org/w/index.php?diff=73433&oldid=73427 * Arseniiv * (+117) suggestions from cpressey and int-e and a *critical* edit
14:18:10 <esowiki> [[User talk:PythonshellDebugwindow]] https://esolangs.org/w/index.php?diff=73434&oldid=73107 * Arseniiv * (+596) /* On additions to BrainSoothe */ new section
14:48:40 <zzo38> I know that in GNU C you can use statements inside of expressions, although in METAFONT it is more like you can even put a for loop where a macro is expected, but unlike C macros you can use values of variables and that stuff.
14:49:54 <zzo38> See the example I had given; something like that (which will result in something like "1*x*x*x*x", and computes x to the power of y) won't work in C.
14:58:23 <esowiki> [[BrainSoothe]] M https://esolangs.org/w/index.php?diff=73435&oldid=73433 * PythonshellDebugwindow * (+48) /* Commentary */ cats
15:12:30 <esowiki> [[Dilemma]] M https://esolangs.org/w/index.php?diff=73436&oldid=68266 * PythonshellDebugwindow * (+114) cats
15:13:25 <cpressey> arseniiv: Regarding my silly "16 quantifiers" idea, handling empty sets sensibly is the strongest reason (for me) for having only two quantifiers. It's intuitive to me that forall over an empty set is trivially true and exists over an empty set is trivially false, regardless of the predicate.
15:15:22 <cpressey> You could, for other quantifiers, stipulate the sets must not be empty, but then it's probably simpler to just rephrase those in terms of forall or exists, instead of pretending they're quantifiers themselves.
15:15:29 <arseniiv> cpressey: yeah, an operation should have a neutral element, that time I added it in the requirements too. But XOR has it, so it’s not trivially excluded…
15:22:28 <arseniiv> though one person said to me that ∀ and ∃ are left and right (or right and left?..) adjoin to substitution or something like that, so they should be special
15:23:48 <esowiki> [[User talk:PythonshellDebugwindow]] https://esolangs.org/w/index.php?diff=73437&oldid=73434 * OsmineYT * (+157) /* Hello (idk why) */ new section
15:24:32 <arseniiv> (hm hopefully that means endofunctors which decorate a formula with ∀x or ∃x, and map morphisms in some way. I don’t even remember what morphisms there should be between formulas, implications?..)
15:24:46 <b_jonas> cpressey: oh, as for that, the main problem is not empty sets (you can just choose the result for that), it's that (1) most binary operations aren't associative, some don't make sense when you try to fold an infinite sequence of inputs, most either don't make sense or are trivial when you try to fold more than countable infinite sequence of inputs, and most aren't commutative.
15:25:09 <b_jonas> cpressey: so if you want a binary output, basically all you get are the foreach, exists, and the two constant operations
15:28:22 <b_jonas> in general you can generalize a maximum fold to infinitely large inputs as the supremum, or you can take the sum of countably infinite inputs in two ways (limit of sum of prefixes for ordered sequences; the special case sum of absolute convergent unordered sequences, where it's good to know that if every element is nonegative then your sequence is guaranteed to be absolute convergent),
15:29:33 <b_jonas> but then if you try to take the sum of more than countably infinite nonnegative real numbers, you just find that it is always infinite unless all but countably infinite of the terms are zero, so you can't get too much of a meaningful generalization over countable set of inputs.
15:30:01 <arseniiv> <b_jonas> some don't make sense when you try to fold an infinite sequence of inputs => oh, right, I think we both there forgot about infinite domains
15:31:04 <b_jonas> back to boolean functions, you also get four more as folds, unlike what I said, namely foreach on an ordered sequence that negates the first input, and exists on an ordered sequence that negates the last input, plus two just return the first input or its negation
15:31:22 <b_jonas> arseniiv: I don't think cpressey did, the few days ago when he mentioned this
15:33:16 <b_jonas> cpressey: xor and xnor are associative, but they don't work for an infinite set of inputs, except you can take the xor of infinitely many inputs if all but finitely many of them are zero,
15:33:35 -!- cpressey has quit (Quit: WeeChat 1.9.1).
15:34:12 <b_jonas> but then, if you are interested only in sequences with all but finitely many elements zero, that's fine, filter out the zeros and you can do a lot of things with it
15:34:32 <b_jonas> similarly xnor with all but finitely many elements nonzero
15:35:01 <b_jonas> (obviously all of this is with the modern convention that zero means false)
15:36:01 <arseniiv> . o O ( all but finitely many elements nonfalse :)
15:41:49 <b_jonas> arseniiv: well, there are two problems here. either 0=false or 0=true would make sense as a representation, perhaps neiter is better than the other, so we had to pick one, and eventually 0=false became standard, except in the posix shell for historical reasons.
15:43:02 <arseniiv> hm hm but were’n there a couple of mathematical reasons to treat 0 = false?
15:43:23 <b_jonas> the other problem is that once you pick 0=false, you can pick different representations for true, and which one is convenient can differ on what you're doing, so you can even use more than one representation in your program: 1, -1, min of your signed type, any nonzero value, or even the version where any nonnegative is positive and any negative is true
15:44:00 <b_jonas> plus you can choose different sizes of course, like 1 bit (in which case all of these are the same), 8 bit, 16 bit, 32 bit, 64 bit, any other size you normally use for integers or whatever
15:44:36 <b_jonas> but the problem is that 1=true vs -1=true can be confusing, because suddenly min isn't always false and max isn't always true
15:45:25 <b_jonas> so whenever you want to use a numeric value, outside of a specific language or library that has a convention (like C or BASIC or fortran), you just have to explicitly say if it matters
15:46:48 -!- Sgeo has joined.
15:52:48 <b_jonas> also the defaults can differ between representation and notation. in C these are the same, because the built-in comparison operators just return 0 or 1, that's all. but C++, in one of its more stupid non-C-compatible changes, changes that so that the comparison operators return bool true or false,
15:53:17 <b_jonas> which behave in high level language as 1 and 0 (that's how they cast to any type of integer or float), but can be represented in any way.
15:54:02 <b_jonas> in the x86 abis, they're represented as 8-byte integers with value 0=false 1=true, probably because of the annoying old 386 SETcc instructions that chose that representations and that we're now stuck with,
15:55:12 <b_jonas> but I sort of think that ideally, if you're not restricted to x86 or MMIX or any current architecture, 0=false -1=true would be the best representation, because that's easier with bitwise operations; but 0=false 1=true would be the best high level meaning (in the C++ sense), because that causes less confusion with signed and unsigned integer types
15:56:56 <b_jonas> and all the SSE and later x86 instructions know this, so the comparisons represent true as -1, and the instructions that takes boolean input from bytes (or longer words) check the sign bit only
15:59:37 <zzo38> Some programming languages don't have boolean values as separate values at all
16:00:51 <b_jonas> zzo38: yes, specifically C. modern C has a _Bool type, but as it's added later, all the comparison operators still return int, AS THEY SHOULD, DARN YOU STROTROUP
16:04:33 <b_jonas> but there's also the opposite, languages where neither booleans convert implicitly to integers nor any integers convert implicitly to booleans
16:05:01 <b_jonas> oh yeah, modern perl has yet another representation: the empty string as false and 1 as true
16:05:46 <b_jonas> except it's not really the empty string, it's a dual scalar that is the empty string as a string and 0 without warning as a number
16:06:17 <zzo38> I mean something a bit different though; for example, in many assembly language where you will have "jump if positive", "jump if nonzero", etc.
16:55:48 <esowiki> [[Modulo]] M https://esolangs.org/w/index.php?diff=73438&oldid=71351 * PythonshellDebugwindow * (+94) cats
16:58:15 <esowiki> [[Swearjure]] M https://esolangs.org/w/index.php?diff=73439&oldid=43254 * PythonshellDebugwindow * (-46) /* Examples */ format
17:00:36 <esowiki> [[Poison]] M https://esolangs.org/w/index.php?diff=73440&oldid=62058 * PythonshellDebugwindow * (+0) /* Help */
17:07:36 <arseniiv> <b_jonas> except it's not really the empty string, it's a dual scalar that is the empty string as a string and 0 without warning as a number => some strange entities do they have, eh
17:08:28 <esowiki> [[Furcode]] M https://esolangs.org/w/index.php?diff=73441&oldid=69425 * PythonshellDebugwindow * (+6)
17:08:55 <esowiki> [[Furcode]] M https://esolangs.org/w/index.php?diff=73442&oldid=73441 * PythonshellDebugwindow * (-11) unpipe user link
17:10:52 <b_jonas> arseniiv: nah, they have arbitrary dual scalars that contain a string and a number (the number can be any of a floating-point, an integer, or an unsigned integer),
17:11:58 <arseniiv> b_jonas: oh now I need to see how do they initialize them
17:12:03 <esowiki> [[Brace For Impact]] M https://esolangs.org/w/index.php?diff=73443&oldid=64965 * PythonshellDebugwindow * (+3) /* Turing complete Proof */ fix redirect
17:12:05 <b_jonas> it's just that *most* such dual scalars that are ever created are either implicitly upgraded from a scalar that has only a string that you use a number so perl caches the number, or from a scalar that stores a number but gets implicitly upgraded to contain a string too by converting the number, or from a boolean false.
17:12:38 <b_jonas> but you *can* create arbitrary dual string/number scalars, there's a convenient function for it too: Scalar::Util::dualvar
17:13:02 <b_jonas> (all this applies to perl 5.10 or later, I don't want to keep track of history before that)
17:13:33 <b_jonas> there are, of course, also scalars that are not numbers or strings or combinations of them
17:14:02 <arseniiv> premature optimization bears weird things
17:14:06 <b_jonas> most of them still implicitly convert to a number and to a string, but they don't upgrade to store that sort of thing
17:14:22 <b_jonas> arseniiv: it made sense back in ye old days when perl was first created. perhaps not so much now.
17:15:21 <arseniiv> there should be an esolang which has many strange things due to carefully crafted “historical” reasons
17:16:35 <b_jonas> arseniiv: sure, you can add fake history. that sort of thing can be interesting even if it's only very modern history.
17:16:38 <esowiki> [[SMETANA To Infinity!/brainfuck]] M https://esolangs.org/w/index.php?diff=73444&oldid=49754 * PythonshellDebugwindow * (+31) i should really make this a template
17:17:24 <b_jonas> it's the sort of thing that's mostly done by conscripters, who create esoteric (in our sense) natural languages, due to Tolkien's tradition, but it's still possible with esoteric programming langugaes
17:17:28 <arseniiv> like, once I thought about a stack language which had a queue “stack” among others. Also there was a duplicating stack and a dropping stack (push a value, then pop two copies of it from the first and no copies at all from the second; almost all the commands moved from one or several stacks to another)
17:18:29 <arseniiv> conlanging/conworlding is interesting, yeah, though I have too few head resources to craft these things in detail I’d like
17:18:43 <esowiki> [[Pure BF/Implementation in Ocaml]] M https://esolangs.org/w/index.php?diff=73445&oldid=34859 * PythonshellDebugwindow * (+13)
17:18:52 <esowiki> [[Pure BF/Implementation in Ocaml]] M https://esolangs.org/w/index.php?diff=73446&oldid=73445 * PythonshellDebugwindow * (+1)
17:19:08 <b_jonas> yes, sorry, conlangers and conscripters
17:19:25 <esowiki> [[Pure BF/Implementation in Ocaml]] M https://esolangs.org/w/index.php?diff=73447&oldid=73446 * PythonshellDebugwindow * (+0)
17:20:00 <b_jonas> arseniiv: does it count as a fake history when a language is designed as if its purpose was to implement in hardware, but you only ever plan to implement it in software? MIX and MMIX are such cases
17:20:16 <arseniiv> b_jonas: I think no conlang is good enough without considering its writing system in some detail, even if it’s an auxlang with latin alphabet
17:20:29 <esowiki> [[Turth-machine]] M https://esolangs.org/w/index.php?diff=73448&oldid=66236 * PythonshellDebugwindow * (+21)
17:20:49 <arseniiv> and no writing system is good without considering who would use it for what
17:21:41 <arseniiv> <b_jonas> arseniiv: does it count as a fake history when a language is designed as if its purpose was to implement in hardware, but you only ever plan to implement it in software? MIX and MMIX are such cases => this seems a boundary case but why not indeed
17:23:18 <b_jonas> arseniiv: I don't see why that would be the case, for two reasons. (1) there are and especially were a lot of natural languages that were used extensively and were certainly useful, but either were never written or were rarely contemporarily written so much that the writing clearly isn't what adds value. why would the writing be necessary for a conlang? this is opposed to a programming language, where I
17:23:24 <b_jonas> see why writing is generally the best form.
17:24:56 <b_jonas> (2) there are ancient languages where most people don't bother much with the original writing system, we just transcribe the relatively few artifacts we have and work with the transcriptions, because that's easier for us. ancient egyptian and akkadian would be examples for that. and even for languages where we still sort of use the same script, the writing has evolved a lot:
17:26:26 <b_jonas> consider latin, which has been a dead language for a pretty long time, but preserved due to the role of christianty. these days we write it in fancy Times roman and italic style lower case letters, with spaces and sometimes punctuation, that weren't used five hundred years ago and may have taken weeks for a scholar back then to adapt to.
17:27:15 <b_jonas> you could say it's sort of the same writing system, but a lot has changed. can you even read the Fraktur and Blackletter scripts that were used on some ceremonial official documents like university diplomas thirty years ago, and heavily actively used like 120 years ago?
17:27:37 <b_jonas> yes, some people can read them, in as much as some people can read Chinese too
17:28:48 <b_jonas> admittedly the writing system changes often more superficially than the spoken language, so deciphering the writing system style within the same script (latin in this example) and adapting to read it is much easier than deciphering and learning the language
17:30:05 <b_jonas> the cases I mentioned only work because the languages were dead and either preserved on written artifacts (stone, clay, vellum, papyrus etc), or because the language was half-dead and so its form was preserved by organized religion for a long time (latin and church slavonic)
17:32:35 <arseniiv> b_jonas: yeah I forgot about unwritten languages, sorry
17:35:55 <zzo38> You might use METAFONT if you want to invent your own writing too, rather than using existing kind of writing, I think.
17:37:37 <b_jonas> arseniiv: in fact, writing second and oral form first is the standard for natural languages, and the only languages that exist primarily as writing are the dead ones preserved by religion or artifacts that I mentioned
17:38:19 <zzo38> Yes, I think that is why Latin words are pronounced differently sometimes
17:40:08 <arseniiv> yeah, and also in languages with heavy literary norms the writing slightly leaks into oral language but usually this leak is equated zero
17:41:20 <zzo38> I had some ideas about conlang, one idea is about involving different physiology
17:42:09 <b_jonas> arseniiv: sure, that always happens, in English and a lot of other languages
18:02:45 <zzo38> Some kind of writing, such as Germanic rune writing, they don't use much, now using Latin writing instead.
18:06:47 <b_jonas> oh yeah, futhark runes, as well as Tolkien's conscripts (tengwar and certh) are also examples where they survived in artifacts that we have transliterated and are only studying in transliterations now and use modern scripts to write the ancient languages, in addition to egyptian and akkadian
18:12:35 -!- Phantom_Hoover has quit (Ping timeout: 260 seconds).
18:18:47 -!- craigo has quit (Quit: Leaving).
18:25:45 -!- bigyihsuan has joined.
18:38:26 <esowiki> [[Special:Log/newusers]] create * CodeLongAndProsper90 * New user account
18:40:36 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=73449&oldid=73409 * CodeLongAndProsper90 * (+114)
18:40:55 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=73450&oldid=73449 * CodeLongAndProsper90 * (+4)
19:03:16 <esowiki> [[ABCDE]] N https://esolangs.org/w/index.php?oldid=73451 * CodeLongAndProsper90 * (+1061) Created page with "[[Category:2020]] [[Category:Turing complete]] ABCDE is an Turing complete extension to [[ABCD]] make by [[User:CodeLongAndProsper90]] ==Extra commands== {| class="wikitabl..."
19:03:51 <esowiki> [[Language list]] https://esolangs.org/w/index.php?diff=73452&oldid=73381 * CodeLongAndProsper90 * (+12) /* A */
19:04:23 <esowiki> [[ABCDE]] https://esolangs.org/w/index.php?diff=73453&oldid=73451 * CodeLongAndProsper90 * (+0)
19:04:43 -!- bigyihsuan has quit (Remote host closed the connection).
19:13:47 <esowiki> [[ABCDE]] M https://esolangs.org/w/index.php?diff=73454&oldid=73453 * PythonshellDebugwindow * (+30) move cats + bold title
19:18:28 -!- lifthrasiir has quit (Remote host closed the connection).
19:19:42 -!- lifthrasiir has joined.
19:21:12 <catern> shachaf: is that the kind of thing you were thinking of in your tweet?
19:21:59 <esowiki> [[Rfghjy]] N https://esolangs.org/w/index.php?oldid=73455 * Sugarfi * (+1138) Created page with "== Rfghy == Rfghy is a simple esolang based around the idea of self-modifying code. There are two registers: `!` and `@`. Each "cycle" of the Rfghy interpreter, `!` is execut..."
19:22:01 <shachaf> It's the same family of thing, I guess?
19:22:08 <catern> both of them seemed like fairly "direct-style" (here labeled "immediate-mode") argument parsing
19:22:39 <shachaf> Do you know the human who made that other library?
19:22:51 <esowiki> [[Rfghjy]] https://esolangs.org/w/index.php?diff=73456&oldid=73455 * Sugarfi * (-22) /* Rfghy */
19:23:10 <catern> yes, I used to work with him
19:23:13 <esowiki> [[Rfghjy]] https://esolangs.org/w/index.php?diff=73457&oldid=73456 * Sugarfi * (-12) /* Rfghy */
19:23:52 <shachaf> My friend was talking about them independently in some other context recently.
19:25:35 <catern> you two should discuss argument parsing - although maybe it's my myopia that makes me think your two schemes look very similar
19:26:49 <shachaf> I mean, argument parsing doesn't matter that much, I'm sure both are fine.
19:27:16 <shachaf> The thing where it parses everything upfront, and gives you the number of times each flag appears etc., is kind of different.
19:29:03 <esowiki> [[International Phonetic Esoteric Language]] N https://esolangs.org/w/index.php?oldid=73458 * Bigyihsuan * (+316) Created page with "The '''International Phonetic Esoteric Language''', abbreviated to '''IPEL''', is a stack-based [[esoteric programming language]] by [[User:Bigyihsuan]] based on the idea of u..."
19:29:31 <catern> well, yes, argument parsing isn't that fundamental, and especially not in C; better to use a better language for the command-line-UI and just call into C from there
19:30:17 <esowiki> [[User:Bigyihsuan]] N https://esolangs.org/w/index.php?oldid=73459 * Bigyihsuan * (+86) Created page with "This is my page! '''Languages created:''' * International Phonetic Esoteric Language"
19:30:24 <esowiki> [[User:Bigyihsuan]] https://esolangs.org/w/index.php?diff=73460&oldid=73459 * Bigyihsuan * (+4)
19:30:40 <catern> (on the other hand, in some ways, getopt-style CLI arguments are the only standard serialization form for data on Unix, so that could make it important... but probably not)
19:32:05 <shachaf> Why better to use two languages instead of one?
19:34:10 <catern> 'cause I don't want to do fancy UIs in C
19:35:06 <catern> but I presume C is important for some mysterious reason otherwise everyone wouldn't be writing all these argument parsing libraries for C
19:35:59 <catern> also, IPC is a hassle - my program should be available as a library anyway, and my program just a fancy UI over that library. well, that's my cached thought on the topic, maybe it's not right
19:36:27 <shachaf> I think something like that is right. Command line programs make for pretty bad libraries.
19:40:03 <catern> and if I'm writing in C, it's easy to write a library that's usable from many languages - so if I should be writing a library anyway, it's convenient and easy to write my UI in whatever language is best for writing in UIs
19:40:11 <shachaf> Mixing APIs and UIs has struck me as a bad idea for a long time.
19:40:42 <shachaf> I agree with that, but then what language should I write the UI in?
19:41:17 <zzo38> I think you could use C for both, if wanted
19:41:27 <catern> that's too concrete of a question for me, I only deal in vagueries
19:41:40 <catern> (in practice I use Python)
19:42:19 <shachaf> time: real 0.532s (user 0.488s, sys 0.044s; 99.96% cpu)
19:42:44 <zzo38> Some programming languages don't have the best way to access C libraries though; for example, PostScript doesn't have a good way to do it (mostly what I do then is using printobject and/or writeobject). Also, you can know how the Glk dispatch API works; it is a design that works better when used from multiple programming languages, than what C does.
19:42:45 <shachaf> Probably this program is an outlier, but over 500ms for printing the help screen isn't encouraging.
19:43:17 <catern> scheme? typescript? haskell?
19:43:34 <catern> surely there has to be some language that is good....!
19:43:52 <shachaf> If only there was. Then I could use it instead of C for the library as well.
19:44:27 <zzo38> Well, there are some, which as assembly language, but assembly language isn't so portable.
19:45:14 <catern> shachaf: going back a bit, do you not buy into the, "APIs are UIs" idea? (and symmetrically, UIs are APIs)
19:45:32 <catern> personally, I think merging UI and API closer together is a really interesting area for research
19:45:45 <shachaf> Well, at least in their current state.
19:45:59 <shachaf> I agree that merging them could be interesting.
19:46:40 <zzo38> I think that sometimes APIs can be good as UIs, and sometimes not so much. (Other way around also)
19:46:45 <shachaf> There are many ways that Unix command line programs are designed to be UIs -- for human use on specific things -- rather than APIs.
19:47:22 <shachaf> Say you have `rm a b c`, and you want to parameterize that on a list of items. In bash you could write something like `rm ${list[@]}`
19:47:30 <shachaf> What can go wrong just from doing that?
19:47:52 <catern> many things, but that's partially bash's fault though
19:47:55 <shachaf> arr might be empty; an element of arr might start with -; an element of arr might contain whitespace; ...
19:48:06 <zzo38> I usually write "echo" first to check that it is correct
19:48:23 <esowiki> [[Strvar]] M https://esolangs.org/w/index.php?diff=73461&oldid=71226 * PythonshellDebugwindow * (+0) /* Interpreter test cases */
19:48:35 <zzo38> In shell scripts I might add -- before the other arguments
19:48:39 <catern> I would prefer rm to have a typed interface though, for sure
19:48:40 <shachaf> Some of these are just problems with the Unix command line norms, sure.
19:48:51 <shachaf> zzo38: But that still doesn't handle the empty list case.
19:49:04 <catern> e.g (filepath list) -> IO ()
19:49:08 <shachaf> Oh, also some items of arr -- which I called list above -- might contain whitespace.
19:49:48 <zzo38> Yes, but the empty list case is I think a problem with rm itself; rm should successfully do nothing if there are no arguments, I think.
19:50:13 <shachaf> A UI is intended to be discoverable as you use it, whereas an API has to be discoverable up-front, I suppose.
19:50:30 <catern> (for example, some complicated UI systems have macro systems which you can perform actions using the rich UI capabilities to, in effect, specify a program. and the most powerful IDEs can make it easy to quickly program against APIs through autocomplete and various things. could the two be merged closer together?)
19:51:33 <zzo38> I don't know, but I think that Unix command line is good for a lot of stuff, although for writing full programs, C and other programming languages are better
19:51:35 <catern> anyway, if they could be brought closer together, it would be interesting to, instead of the Unix interface which just passes a list of strings to rm, have a nicely typed interface for rm, and many other utilities like it
19:52:08 <shachaf> Yes, maybe a better shell UI would look a bit more like that, such that you pass structured data to "commands" (which might just be library calls), and it helps you put them together easily.
19:52:39 <shachaf> I've thought about things like that before. There are many other interface improvements you can make to terminals and shells.
19:54:50 <zzo38> One thing I thought is in Plan10 to have "chain segments", and environment variables and command-line arguments are implemented using chain segments, but then you could define other interfaces too.
19:55:30 <catern> I have a vague suspicion that too many people have tried to make shells better or smarter in various ways - it might be a dead end - maybe it would be more productive to go the other direction, and use your fancy Emacs Agda IDE to manipulate files instead of snippets of code
19:56:27 <shachaf> I am not too much into turbo-fancy IDEs.
19:58:04 <int-e> . o O ( 100% CPU for a blinking cursor. )
19:59:21 <zzo38> If a program calls another program using exec(), and the new program and old program have any chain segments with the same name, then that memory is retained rather than being reset.
19:59:26 <catern> well, turbo-fancy IDEs are hard to manipulate and program right now, so it's quite reasonable. but maybe they can be made more programmable (in a way that your knowledge of the UI directly allow programmability)
19:59:46 -!- xelxebar has quit (Remote host closed the connection).
19:59:50 <catern> zzo38: what about passing file descriptors or other non-memory resources?
20:00:04 <catern> (such as stdin/stdout/stderr)
20:00:18 -!- xelxebar has joined.
20:00:37 <zzo38> catern: You can already do that in the normal way.
20:01:07 <catern> zzo38: so then why not pass a chain segment as a normal resource rather than by name?
20:02:45 <catern> shachaf: like, one reason I don't like turbo-fancy IDEs is that clicking a button doesn't correlate with knowing the name of the function that that button invokes. which makes it harder to write program involving those functions. but the underlying issue there is that you need to identify the function by some name - why can't you identify it by clicking the button?
20:02:54 <catern> or something like that
20:05:40 <zzo38> catern: I am not sure if I understand your question fully.
20:08:47 <catern> zzo38: it sounds like you're proposing that processes have a table of chain segments which they can look up by a string name, and which contain data, is that right? but resources like file descriptors also can contain data. why not unify the two, and instead of having a table of chain segments, just have a table of file descriptors? you can preserve the lookup-by-string-name thing if you want
20:12:37 <zzo38> Well, it is a bit different. I was thinking of chain segments like other (unnamed) segments declared in the ELF file would be loaded in memory; chain segments are the same but they have a name, and if it has a name then the operating system can retain whatever data is there rather than reset it, if both programs have the same name of chain segment. If the previous program doesn't have such a segment, then it is loaded like any other se
20:13:34 <zzo38> (So, it is otherwise like PT_LOAD, but it does not necessarily load the contents of the executable file.)
20:15:13 <zzo38> (Chain segments could be used for other purposes too, such as to implement overlays in a way that is sometimes done in DOS programs.)
20:32:51 -!- TheLie has joined.
20:46:42 <esowiki> [[International Phonetic Esoteric Language]] M https://esolangs.org/w/index.php?diff=73462&oldid=73458 * PythonshellDebugwindow * (+47)
20:49:10 <esowiki> [[MindReadingFuck]] M https://esolangs.org/w/index.php?diff=73463&oldid=67577 * PythonshellDebugwindow * (+22) /* Solve the halting problem */
20:49:47 <b_jonas> shachaf: "`rm ${list[@]}` [...] What can go wrong just from doing that?" => some things that you can fix by writing (rm -- "${list[@]}") instead, and apart from that, errors that you get when you expand a shell parameter or make variable that you thought would be defined but actually isn't and get an empty string, in which case you get serious bugs like that recent uninstaller that tried to rm -rf --
20:49:53 <b_jonas> "/usr/${SOMEVARIABLE}" and in fact deleted the /usr of anyone who tried to uninstall their program
20:50:35 <shachaf> The point is that hardly anyone writes that unless they're writing a script.
20:50:40 <esowiki> [[NARchy]] M https://esolangs.org/w/index.php?diff=73464&oldid=58278 * PythonshellDebugwindow * (-29)
20:50:52 <shachaf> So it highlights how different the UI vs. API thing even in the same program.
20:51:05 <shachaf> And of course this still doesn't solve every problem.
20:51:16 <int-e> Ah the abuses of @let.
20:51:29 <shachaf> For example if the list is empty this will still be an error.
20:51:33 <b_jonas> shachaf: as for "array may be empty" => yes, that can also cause serious bugs with some shell commands, though in the case of rm it's not generally a problem, unless it's a REALLY weird extglob nullglob problem where you accidentally remove a file named "!(*.jpg)"
20:51:57 <shachaf> It's a problem because rm will exit with 1 instead of 0.
20:52:14 <lambdabot> Variable not in scope: isEsoteric :: Char -> t
20:52:24 <int-e> @let isEsoteric _ = True
20:52:32 <b_jonas> "<catern> I would prefer rm to have a typed interface though, for sure" => you're in luck then, we have a remove C function for that, and various apis (mostly in high level languages) for recursive rm
20:52:44 <arseniiv> hm I think you retroactively defined it for that earlier case, then
20:53:17 <b_jonas> "<shachaf> zzo38: But that still doesn't handle the empty list case." => it does if you have a -f option. (rm -f --) successfully does nothing and returns true
20:53:33 <shachaf> Yes, but then it does -f on everything else.
20:53:54 <b_jonas> "<zzo38> Yes, but the empty list case is I think a problem with rm itself" => no, rm handles it well, it's more of a problem with programs that interpret an empty argument list as acting on stdin
20:56:22 <b_jonas> zzo38: re chain segments, instead on unix we have three different shared memory APIs in kernel+libc: mmap, sysv ipc, posix ipc. plus some higher level wrappers, such as one in boost whose purpose is to give a portable wrapper to unix vs windows.
20:57:16 -!- rain1 has quit (Quit: leaving).
20:57:48 <shachaf> Even if rm did work perfectly here, it wouldn't help you that much because that'd be a big outlier in terms of unixular utilities.
20:58:56 <b_jonas> that said, something like "chain segment" made sense in high level languages like BASIC on old machines that had very limited RAM, where you would often want to load another BASIC program in such a way as to replace most of your program, but you asked BASIC to chain some of your variables and/or some of your programs.
20:59:29 <esowiki> [[Emoji]] M https://esolangs.org/w/index.php?diff=73465&oldid=65580 * PythonshellDebugwindow * (+8) /* Interpreters */
20:59:55 <zzo38> Yes, using the CHAIN command, I think.
21:01:11 <esowiki> [[Brainfuck Contest 1]] M https://esolangs.org/w/index.php?diff=73466&oldid=70716 * PythonshellDebugwindow * (+1) /* Code that actually works as required */
21:02:25 <b_jonas> shachaf: you usually want -f when you invoke rm from a script. Even without -f, (rm --) does nothing, it just gives you an error, which is sometimes acceptible, the rest of the time you indeed may need a workaround
21:02:47 <b_jonas> but yes, empty list of files is a much bigger problem for other commands
21:03:39 <b_jonas> zzo38: but also the MERGE command, which is sort of the same but keeps all variables and most of the code, so it's more useful to load and unload overload code segments
21:04:22 <arseniiv> @let passwordOfTheMonth = "@let passwordOfTheMonth = \"" ++ take passwordOfTheMonth 27 ++ "\" -- is not quine"
21:04:23 <lambdabot> • Couldn't match expected type ‘Int’ with actual type ‘[Char]’
21:04:36 <arseniiv> @let passwordOfTheMonth = "@let passwordOfTheMonth = \"" ++ take 27 passwordOfTheMonth ++ "\" -- is not quine"
21:04:47 <lambdabot> "@let passwordOfTheMonth = \"@let passwordOfTheMonth = \"\" -- is not quine"
21:05:13 <esowiki> [[PythonshellDebugwindow/Rewriting Language]] N https://esolangs.org/w/index.php?oldid=73467 * PythonshellDebugwindow * (+191) Created page with "An esolang based on [[string]] [[rewriting]]. Out of bounds indexing -> 0. ==Examples== ===[[Cat]] program=== 0..*=0..*H ===Reverse [[cat]]=== 0..*=*..0H ===Truth-machin..."
21:05:15 <arseniiv> oh it’s way clumsier than intended
21:05:56 <esowiki> [[PythonshellDebugwindow/Rewriting Language]] M https://esolangs.org/w/index.php?diff=73468&oldid=73467 * PythonshellDebugwindow * (-191) delete!
21:06:01 <b_jonas> these days that sort of chaining is rarely relevant, because virtual memory helps you both ways: it lets you swap out parts of your program that are not needed right now, so you can just have one big program, and it lets you cache the contents of regular files that you use to pass data from one program to the next one, such as object files between a compiler and linker
21:06:06 <esowiki> [[User:PythonshellDebugwindow/Rewriting Language]] N https://esolangs.org/w/index.php?oldid=73469 * PythonshellDebugwindow * (+191) Created page with "An esolang based on [[string]] [[rewriting]]. Out of bounds indexing -> 0. ==Examples== ===[[Cat]] program=== 0..*=0..*H ===Reverse [[cat]]=== 0..*=*..0H ===Truth-machin..."
21:09:36 <esowiki> [[Heebolang]] https://esolangs.org/w/index.php?diff=73470&oldid=73413 * Polybagel * (+755)
21:10:11 <esowiki> [[Heebolang]] https://esolangs.org/w/index.php?diff=73471&oldid=73470 * Polybagel * (+1)
21:10:40 <esowiki> [[Heebolang]] M https://esolangs.org/w/index.php?diff=73472&oldid=73471 * Polybagel * (+1)
21:11:00 <esowiki> [[International Phonetic Esoteric Language]] https://esolangs.org/w/index.php?diff=73473&oldid=73462 * Bigyihsuan * (+3568)
21:12:03 <esowiki> [[International Phonetic Esoteric Language]] https://esolangs.org/w/index.php?diff=73474&oldid=73473 * Bigyihsuan * (+107)
21:12:12 <zzo38> Why does Glulx require the number of arguments to be specified for Glk API calls, even though that can be determined automatically from the type (which the interpreter needs to know anyways, in order to parse the arguments properly)?
21:23:22 <spruit11> To make it easy to walk or dump the stack?
21:24:53 <esowiki> [[Swapper]] https://esolangs.org/w/index.php?diff=73475&oldid=52869 * Voltage2007 * (-399) bit big of an edit
21:25:21 <esowiki> [[International Phonetic Esoteric Language]] https://esolangs.org/w/index.php?diff=73476&oldid=73474 * Bigyihsuan * (+286)
21:28:06 -!- Phantom_Hoover has joined.
21:37:22 <b_jonas> zzo38: perhaps as a form of redundancy against programming errors?
22:18:41 -!- adu has quit (Quit: adu).
22:19:21 <b_jonas> zzo38: can it be an artifact from a rarely used vararg function API, possibly one that's not even supported anymore, but whose existence has side effects to non-vararg functions? because that sort of happened to C varargs, which even on x86_64 have an effect on the ABI of a few non-vararg function calls, because we can't distinguish the ABI of vararg function calls from non-vararg calls, because that
22:19:27 <b_jonas> could break old C programs with no ANSI style prototypes for a function,
22:20:29 <b_jonas> even though nobody in the x86_64 era writes any new C programs that require that you can call a vararg function without a prototype, except when omitting #include <stdio.h> for golf purposes.
22:20:57 <fizzie> It would be perfectly legal to break those programs; it's not possible to call a vararg function without a prototype.
22:22:11 <fizzie> "If the expression that denotes the called function has a type that does not include a prototype -- [and if] the function is defined with a type that includes a prototype, and -- the prototype ends with an ellipsis --, the behavior is undefined."
22:22:24 <b_jonas> fizzie: not according to the current C standards (or even C89 I think), but in old compilers it was perfectly possible to call printf or open without a prototype, and as a result people wrote programs that did that and got away with it
22:22:49 <fizzie> Right, that sort of compatibility thing.
22:22:57 <b_jonas> fizzie: sure, the C standard says that exactly because we don't want to support that sort of nonsense forever into the future
22:23:08 <b_jonas> but for now we still have some ancient C programs without prototypes so we can't do it yet
22:23:21 <b_jonas> or we couldn't do it yet when x86_64 came out
22:23:22 <fizzie> Is that really true though? The x86-64 varargs ABI *is* different -- will compilers use it "just in case" if there's no prototype?
22:23:50 <zzo38> I don't think so, because Glk doesn't use varargs, and anyways it is Glulx, not C. (There is a C API for Glk too, although the Glk dispatch layer deals with the types of the functions and calls them (and also exposes the types in a portable format for all programming languages), so the Glulx interpreter will already know the type and number of arguments, even in case of extensions to Glk.)
22:24:06 <b_jonas> fizzie: I think so for at least one of the two x86_64 abis, but I'll have to look that up, and it impacts only a few function calls (depending on the type of arguments)
22:24:15 <fizzie> Apparently they do. Huh.
22:24:17 <zzo38> (And I have made some extensions to Glk. Making these extensions does not require changing the Glulx interpreter in any way.)
22:24:23 <fizzie> Well, it's not a huge hassle, addmittedly.
22:25:13 <fizzie> I would imagine for the SysV ABI it would affect all prototype-less calls, because you have to clear rax (or rather, set al to the "proper" value), which you otherwise wouldn't.
22:25:39 <b_jonas> fizzie: but you can see that the ABI is designed such that the called function can access the first argument without knowing what the type of the rest of the arguments are, which probably doesn't cause any performance problems, but even so it is a decision prompted by the vararg history
22:26:37 <b_jonas> I'll have to look up the details about the x86_64 ABIs in the Agner document later to tell what the AL thing was about, the one that can impact performance. I simply don't remember.,
22:27:26 <fizzie> You must set AL to the number of SIMD registers used for passing floating-point arguments if you're calling a varargs function.
22:27:43 <fizzie> http://ix.io/2oM5 does it for the call to f_noproto, and doesn't for the call to f_withproto.
22:28:13 <fizzie> I imagine it would by definition "affect" performance insofar that it's an extra instruction.
22:28:46 <b_jonas> fizzie: but in that case doesn't it impacts only functions that have arguments with floating point in them?
22:28:56 <fizzie> No, because you have to set it to 0 if they don't.
22:29:09 <b_jonas> fizzie: even if you have a prototype and so know that the function isn't vararg?
22:29:17 <b_jonas> which is the majority of function calls
22:30:01 <fizzie> The point I was trying to make is that the fact that it's "forced" to assume prototype-less functions might be varargs is affecting all calls to prototype-less functions.
22:31:23 <b_jonas> and we'll get rid of non-prototyped function calls way before we get rid of varargs in C, because *printf, *scanf and open are here to stay.
22:31:53 <b_jonas> (I know some other vararg C functions that are probably here to stay, but they're used less than those)
22:33:47 -!- zzo38 has quit (Quit: zzo38).
22:34:41 -!- zzo38 has joined.
22:35:04 <spruit11> The fact that you can walk the C stack probably made C++ exceptions possible..
22:36:22 <b_jonas> spruit11: that might be true historically (I don't know), but these days you can't walk the C stack
22:36:42 <b_jonas> and by "these days" that was already true 20 years ago
22:36:42 <fizzie> I've been browsing the c2x draft (there's one from Feb this year), and it's got a few headline-grabbing features. Like, `strdup` is finally in, and the [[foo]] attribute syntax has been ported back from C++ (though only for [[nodiscard]], [[maybe_unused]], [[deprecated]] and [[fallthrough]], all of which are merely for better diagnostics).
22:38:00 <fizzie> Oh, and old-style function definitions are out, which is almost relevant to the earlier discussion.
22:38:37 <b_jonas> fizzie: is there any feature that they could consider standardizing in the form of an attribute and isn't merely for diagnostics? hmm yes, there is, [[no_unique_address]], but that's so new it just didn't have a chance to get into C standard proposals yet
22:38:51 <zzo38> OK, strdup is in, now, but is memdup in yet?
22:39:03 <fizzie> (Sort-of unfortunately prototype-free declarations aren't out.)
22:39:21 <HackEso> memdup`? No such file or directory
22:39:35 <fizzie> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf
22:40:33 <fizzie> There are also a bunch of more recent documents at http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm but no newer full working draft.
22:40:35 <b_jonas> fizzie: there's no point to remove prototype-free declarations from the standard, we'll not remove them from real life because they'll still in use (for compatibility only, with default warning, not for new code), so removing it from the standard would be ... oh I see. yes, ignoring the real world and depreciating something that is in use would be exactly the sort of thing that those standard committees
22:40:47 -!- imode has joined.
22:40:59 <fizzie> Well, they removed `gets`.
22:41:10 <fizzie> I suspect it's still in use.
22:41:26 -!- adu has joined.
22:41:28 <b_jonas> spruit11: you can probably find it from http://www.open-std.org/JTC1/SC22/WG14/
22:42:38 <b_jonas> fizzie: did they remove asctime or ctime?
22:43:10 <spruit11> Hmm. I guess unwinding is done by just tracing links.
22:43:11 <fizzie> No, but they added asctime_r and ctime_r.
22:43:16 <fizzie> So maybe that's a step?
22:43:31 <zzo38> Well, gets is the function they should remove.
23:02:11 -!- Phantom_Hoover has quit (Ping timeout: 272 seconds).
23:13:17 -!- Lord_of_Life_ has joined.
23:15:27 -!- Lord_of_Life has quit (Ping timeout: 260 seconds).
23:16:08 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
23:17:23 -!- TheLie has quit (Remote host closed the connection).
23:24:21 -!- tromp has quit (Ping timeout: 272 seconds).
23:50:37 -!- arseniiv has quit (Ping timeout: 246 seconds).