00:00:21 <b_jonas> that said, I do think that C or C++ shouldn't be extended to accept spaces inside numbers
00:01:01 <zzo38> I think you are right; I would prefer to use underscores inside numbers
00:01:32 <b_jonas> zzo38: it's too late for the underscores, they'd conflict with some user-defined literals in C++ now
00:01:44 <ais523> there are also lots of languages which ignore the first line if it starts with #, but otherwise handle # differnetly
00:02:46 <b_jonas> zzo38: as in, 0x0000_A000 is parsed a user-defined literal that calls a function named operator ""_A000
00:05:51 <b_jonas> zzo38: that said, I do wish C++ allowed not only apostrophe but multiple adjacent apostrophes as digit separator
00:06:31 <b_jonas> so that you can balance your apostrophes to avoid confusing partial tokenizing tools that don't know the new rules
00:06:50 <b_jonas> (yes, there are other ways to balance them, with extra numbers or comments or whatnot, but still)
00:08:09 <ais523> I have at least one, and probably more, Perl file with comments containing punctuation marks at the end of lines that syntax-highlight incorrectly
00:08:47 <ais523> part of the reason I installed Kate was to have an editor that was good at syntax-highlighting Perl in complicated cases, it handles it better than the other editors I tried
00:09:21 -!- Lord_of_Life_ has joined.
00:10:23 -!- Lord_of_Life has quit (Ping timeout: 264 seconds).
00:10:37 <b_jonas> I don't like syntax highlighting to be clear, but still I'd prefer if multiple apostrophes were accepted
00:10:39 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
00:11:26 <b_jonas> (I mean for ordinary program; if you are trying to understand or build obfuscated programs or esoteric languages and a syntax highlighting helps with the crazy language rules then I'm fine with it.)
00:23:06 <ais523> what's your opinion on automated bracket-matchers? (either that color all the brackets, or that color the matching bracket when you cursor/hover over a bracket)?
00:26:08 <b_jonas> ais523: I'm fine with thos and I do use those commands
00:26:59 <ais523> over my time programming, I've got a lot of use out of auto-indent to catch typos
00:27:15 <ais523> (if I mismatch brackets the next line will be indented incorrectly, then I look back to see what caused the auto-indent to break)
00:27:27 <ais523> syntax highlighting is sort-of useful in the same way, but mostly only for catching mismatched quotes
00:27:53 <b_jonas> ais523: sure, and these days we can also have a compiler/interpreter warn you about indents that don't seem to match your braces
00:28:57 <ais523> this is one reason I dislike Python – it doesn't have that redundant information, so if you misindent a line, the resulting program will often be meaningful but not what you want, and the compiler has no way to catch it
00:29:15 <b_jonas> ais523: that's only part of the problem
00:30:08 <ais523> oh, syntax highlighting also catches misspelled keywords, that's also useful on occasion
00:30:50 <ais523> I wonder when the consensus in language design moved towards "keywords and identifiers are written the same way as each other, and keywords aren't valid as identifiers" – early language design seemed to avoid that
00:31:15 <ais523> even in Perl, the syntax is designed so that new keywords can be added without conflicts, because variables have sigils on them
00:31:39 <b_jonas> the other part is that sometimes you forget a closing parenthesis and python thinks that the next line is a continuation, unless you're methodical and put a semicolon at the end of every simple statement. but on the plus side, the interpreter has been improved in the last few years and it now usually points you at the right location when it finally discovers the error, whereas it used to give a
00:32:17 <ais523> older whitespace-sensitive languages normally had an explicit line continuation marker (like the backslash-at-end-of-line in C)
00:32:39 <b_jonas> ais523: python has that too, a backslash at the end of the line for continuation
00:32:40 <ais523> e.g. in Visual Basic (which uses newline as a semicolon substitute), you end a line with an underscore to continue it onto the next line
00:32:56 <b_jonas> but when a parenthesis or bracket or brace is open then the continuation mark is optional
00:33:23 <b_jonas> (ruby is or used to be even more lax in this I think, allows implicit continuation in even more cases)
00:34:11 <ais523> I didn't realise Ruby was whitespace-sensitive
00:34:32 <b_jonas> ais523: but on the plus side, python's syntax could be extended in a reasonable way to add a braced syntax, sort of like how haskell has one, and I'm sort of thinking of implementing this as a long term project,
00:34:43 <b_jonas> the hard part isn't the implementation of course but the marketing
00:34:50 <ais523> from __future__ import braces
00:35:32 <b_jonas> because it's compatible, doesn't break any existing program, nor will interpret any likely mistake as a valid program
00:35:40 <b_jonas> and you can use it in just parts of your code, which makes it easier to sell
00:35:54 <ais523> fwiw, I've been thinking a bit about basic loop syntax recently
00:35:55 <b_jonas> because I can say as one of the arguments, sure, write most of your code in the normal whitespace-sensitive style,
00:36:11 <ais523> and came up with "while condition do { commands }" which I don't think any major language uses at the moment?
00:36:34 <b_jonas> but in that one place where you have a twenty line thing for what should be two very simple lines handling some unimportant cases so that your function does error handling properly, that's where you use this
00:36:49 <b_jonas> the other case is of course when you write snippets on IRC or inline in paragraphs of text
00:36:55 <ais523> b_jonas: that's pretty much how Haskell is written at the moment, I think
00:36:56 <b_jonas> that's when you write your whole program with braces
00:37:07 <ais523> Haskell does whitespace-sensitivity pretty well (apart from the offside rule being hard to understand)
00:37:28 <b_jonas> I might as well explain the syntax because this one isn't a secret
00:39:08 <int-e> ais523: what do you need the "do" for?
00:39:23 <ais523> the advantages of "while condition do { commands }" are a) it's easy to read even if the condition somehow ends up spanning several lines, b) you can easily extend it to add modifiers between the while and the do
00:39:49 <b_jonas> so currently in python, you have compound statements starting with a keyword (class, def, if, else, while, for, with, try, except, finally, match, case), then possibly some condition or whatnot, then a colon, then either one (logical) line right after the colon, or a line break after the colon and an indented block of lines.
00:39:52 <int-e> Without it you'll have Rust.
00:39:54 <ais523> my Rust sometimes ends up in the form "while { complicated condition spanning several lines } { loop body }" which is a pain to find a readable indentation for
00:40:11 <ais523> that's what inspired me to think that a keyword between condition and body was needed
00:40:22 <b_jonas> I'd add a third possibility, which is that instead of the colon you have an opening brace immediately followed by a semicolon followed by python code in braced syntax followed by a matching closing brace
00:40:47 <ais523> the semicolon after the brace is to avoid it parsing as a dictionary literal?
00:41:08 <int-e> ais523: I see. So you don't like having } { on a line by itself
00:41:22 <ais523> int-e: right, it's hard to immediately mentally parse what it means
00:41:38 <b_jonas> in python code in brace syntax, newlines aren't special, they just work as spaces, so indentation doesn't matter either, and after a compound statement you can never use a colon, only a braced block of python code in braced syntax, except that time the semicolon is optional
00:41:49 <b_jonas> and also in python code in brace syntax, the semicolon has a different meaning from normal:
00:42:02 <b_jonas> it separates lines from each other, just like newlines do in normal python code
00:42:29 <int-e> ais523: tbh I'd probably blame the existence of block expressions for this conundrum :-P
00:42:29 <b_jonas> so you'd write if A {; if B { C; D } else { E; F } G }
00:43:01 <b_jonas> you can add extra semicolons almost anywhere inside that block of braced syntax pythohn, like before braces, after braces
00:43:27 <ais523> OCaml ifs are nice, they're "if expression then expression end expression" and you can put newlines before the then and the else
00:43:42 <ais523> or turn any of them into blocks (but OCaml doesn't use {} for blocks)
00:43:44 <b_jonas> these are the important rules but there are a few auxiliary ones:
00:43:54 <ais523> I like the three-way symmetry
00:44:36 <b_jonas> namely a decorator can be closed with a semicolon (definitely in braced syntax but ideally also outside for simplicity, those are two different kinds of semicolons but still);
00:46:45 <b_jonas> there's a new compound command whose heading is empty so you can just write a colon followed by a newline followed by an indented block -- you'd usually use this to write your whole code in indented syntax, like you'd do in IRC or inline in a paragraph of text or on the shell command-line like python3 -e'{; import secrets; for _x in range(10) { print(secrets.randbelow(100) } }'
00:48:13 <b_jonas> and, perhaps delayed to the next proposal, there's a way to configure an interactive python session to parse braced python syntax at the top level instead of normal indented syntax, for that's another one of those places where the newlines and indents are very inconvenient,
00:48:29 <b_jonas> and to support this the compile function and some C APIs gain new flags to support this
00:49:29 <ais523> wait, interactive python interpreters are written using the C API? I kind-of assumed they'd be written in Python
00:49:29 <b_jonas> also we'd probably want to modify that python pretty-formatter tool so it can convert a program source code with possibly braced syntax inside it to a program that doesn't use braced syntax anywhere, which is pretty easy actually once you can tokenize python
00:50:32 <b_jonas> ais523: I don't know how the interactive interpreter is written, but that's irrelevant, you want to modify the C API anyway for when you embed python into a non-python program (think of vim) as a macro language and you want to input a line of braced python from the user and run it
00:51:22 <b_jonas> or if you prefer, think of those games that have an in-game debug console that can take lua commands and imagine that in python
00:51:29 <b_jonas> you can usually input just one line conveniently
00:52:11 <b_jonas> (there's a good reason why they use lua rather than python, but still)
00:52:35 <ais523> I learned Python using EsoBot's predecessor
00:52:58 <ais523> using one-liners consisting of exec("…") with \n for newline followed by spaces for indentation
00:53:49 <b_jonas> sure, there are workarounds like that
00:54:00 <b_jonas> and that is another thing we can use in the marketing:
00:54:15 <b_jonas> point out how many stupid workarounds people already use to be able to write one-line python
00:54:19 <b_jonas> not just the exec but others
00:54:29 <b_jonas> and say that those hurt more than just allowing the braced extension
00:54:40 <b_jonas> (I was thinking about this quite a bit as you can tell)
00:55:41 <b_jonas> I will probably have to start by implementing it and putting an interpreter into HackEso of course, to get experience using it
00:59:43 <ais523> Python is intentionally LL(1), isn't it? (assuming that indentation is handled by the lexer)
00:59:53 <ais523> I think this wouldn't break that, but am not immediately sure
01:01:21 <b_jonas> ais523: indentation is handled by the lexer, and after that the grammar is reasonably simple, except some of the fixups after parsing that are in line with what you'd see in normal languages. I don't know if it's LL(1) off the top of my head right now, but possibly.
01:03:06 <ais523> it's notable because sticking to LL(1) is weird, most languages are happy with LR(1) or even with needing a few special cases
01:03:37 <ais523> although, subtraction is hard to do sensibly in LL(1)
01:04:18 -!- joast has quit (Quit: Leaving.).
01:04:20 <ais523> `! ipython3 -c "print(1 - 2 - 3 - 4)"
01:04:22 <HackEso> /hackenv/bin/!: line 4: /hackenv/ibin/ipython3: No such file or directory
01:04:33 <ais523> `! ipython -c "print(1 - 2 - 3 - 4)"
01:04:34 <HackEso> /hackenv/bin/!: line 4: /hackenv/ibin/ipython: No such file or directory
01:04:38 <b_jonas> the few special cases is that when you start to parse a statement you can't tell if it's an assignment starting with an lvalue-like expression or an expression statement that's an rvalue expression, so you have to parse it in a way that works for both and then check and fix it up afterwards
01:04:42 <ais523> `` ipython3 -c "print(1 - 2 - 3 - 4)"
01:04:43 <HackEso> /hackenv/bin/`: line 5: ipython3: command not found
01:04:48 <ais523> `` ipython -c "print(1 - 2 - 3 - 4)"
01:04:49 <HackEso> /hackenv/bin/`: line 5: ipython: command not found
01:05:06 <ais523> `` python3 -c "print(1 - 2 - 3 - 4)"
01:05:23 <b_jonas> the tree will have the same shape, it's not like symbols have different precedences in lvalue versus rvalue, just some things are invalid in rvalues
01:05:26 <ais523> it is quite hard to parse "1 - 2 - 3 - 4" to -8 in LL(1)
01:07:41 <b_jonas> I think scan (my very old and bad toy language) has an LL parser that parses 1 - 2 - 3 - 4 to -8
01:07:43 <ais523> to make it work in LL(1) you need to parse it as (1 + (-2 + (-3 + (-4))))
01:07:54 <ais523> doable but not very intuitive
01:08:12 <b_jonas> there are no plus signs, they're all subtractions
01:08:19 <b_jonas> but I assume that's what you're thinking too
01:08:51 <ais523> LL(1) can't parse it as (((1 - 2) -3) -4) because it would need to know how many brackets to open before it had read past the first - sign
01:09:24 <b_jonas> ok, maybe the parser of scan isn't LL then
01:12:16 <b_jonas> the function Parse_expr that parses an expression first parses an expression that doesn't have (unparenthisized) infix operators, then has a do-while loop that peeks one token, checks if it's an infix operator, and if is then replaces the current expression with an infix operator expression by consuming its operator and parsing its right hand side, then continues the do loop
01:12:40 <b_jonas> so that makes it not an LL parser?
01:13:10 <b_jonas> it's a bit more complicated than this
01:13:32 <b_jonas> it actually sometimes decides that it doesn't want the infix operator that it peeked because it's too low precedence for the expression that it's parsing
01:13:50 <b_jonas> the parsing function takes a numeric argument for what precedence of expression it's parsing
01:15:10 <b_jonas> there's some more magic but I've no idea how it works, this code is ugly and I forgot it
01:15:42 <b_jonas> though I think in principle parsing this way is fine, it's just a lot of other things that are wrong
01:16:15 <ais523> that sounds a bit like a Pratt parser, or a modification of one
01:16:50 <ais523> I ended up independently reinventing those when working with ayacc (I wasn't the first to discover them, but came up with the technique before seeing the prior art)
01:17:08 <b_jonas> yeah, I think ayacc can write these
01:17:12 <ais523> it's basically a compressed form of LR parser, specialised for expressions (also very efficient)
01:17:42 <b_jonas> it kind of has to as an optimization because yacc allows operators with precedences in its yacc input
01:20:53 <ais523> oddly, ayacc's optimization is independent of how yacc does things, and yacc precedences don't work like you'd expect
01:21:03 <ais523> they're implemented as static resolutions for shift/reduce conflicts
01:22:02 <ais523> which is a silly way to do it – better would be to explicitly split the cases for a rule into precedence groups, then say that a rule can't call higher-precedence (or equal-predecence and wrong-associativity) cases of itself recursively
01:22:25 <ais523> yacc's method of specifying precedence is very tied to implementation details of yacc, which has lead to interesting bugs in practice
01:22:35 <ais523> (because the precedence declaration doesn't do what the programmer thought it did)
01:22:59 <b_jonas> ais523: do you mean the optimization emits the same code no matter whether (you use yacc's %left and %right feature as a shortcut) or (you write the grammar the ordinary BNF way with separate productions for expressions at different precedences)?
01:23:43 <b_jonas> ah I see, yacc's method can cause strange problems
01:24:27 <b_jonas> ok, so what I should ask is, can ayacc emit the optimization if you write the grammar the ordinary BNF way with separate productions for each precedence?
01:25:05 <ais523> b_jonas: in theory yes, because the optimizer ignores information about where the shift/reduce table comes from and just looks at the table
01:25:20 <ais523> in practice, it doesn't – I think it's because it finds a different optimized form first and the optimizer isn't confluent
01:25:57 <ais523> the naive implementation is O(n²) in terms of the parser size, the optimized version for both yacc-precedence and manual-BNF-precedence are O(n), but the two are different from each other
01:28:08 <b_jonas> and yes, I think the naive yacc implementation emits a table where one axis is about as large as there are terminal tokens, the other axis about as large as the grammar because that's how many states there are or something
02:11:14 -!- ais523 has quit (Quit: quit).
02:42:16 <esolangs> [[Brainfunct]] https://esolangs.org/w/index.php?diff=108387&oldid=108379 * Nurdle * (+0)
02:43:49 <esolangs> [[User:Nurdle]] https://esolangs.org/w/index.php?diff=108388&oldid=108370 * Nurdle * (+28) /* Things I've Made */
02:44:02 <esolangs> [[User:Nurdle]] https://esolangs.org/w/index.php?diff=108389&oldid=108388 * Nurdle * (-1) /* Esolangs */
02:51:21 <esolangs> [[Esolang talk:Featured languages]] https://esolangs.org/w/index.php?diff=108390&oldid=81109 * Nurdle * (+103)
04:55:55 -!- example99 has joined.
05:15:23 -!- example99 has quit (Ping timeout: 260 seconds).
07:57:07 -!- Sgeo has quit (Read error: Connection reset by peer).
09:04:51 -!- chiselfuse has quit (*.net *.split).
10:41:47 -!- __monty__ has joined.
10:53:34 <esolangs> [[Trainfck]] https://esolangs.org/w/index.php?diff=108391&oldid=108386 * Mujk * (+37) /* operators */
11:41:49 -!- sprout_ has joined.
11:45:02 -!- sprout has quit (Ping timeout: 246 seconds).
12:18:29 -!- sprout_ has changed nick to sprout.
13:16:05 <esolangs> [[Sheep]] N https://esolangs.org/w/index.php?oldid=108392 * Ashli Katt * (+3447) Created page with "{{infobox proglang |name=Sheep |paradigms=Functional |author=[[User:Ashli Katt|Ashli Katt]] |year=[[:Category:2023|2023]] |class=[[:Category:Unknown_computational_class|Unknown]] |files=<code>.sheep</code> }} == About == Sheep is a functional esolang where the only da
13:16:34 <esolangs> [[Trainfck]] M https://esolangs.org/w/index.php?diff=108393&oldid=108391 * PkmnQ * (-22)
13:17:00 <esolangs> [[Sheep]] https://esolangs.org/w/index.php?diff=108394&oldid=108392 * Ashli Katt * (+1)
13:18:12 <esolangs> [[Sheep]] https://esolangs.org/w/index.php?diff=108395&oldid=108394 * Ashli Katt * (+134)
13:22:07 <esolangs> [[User:Ashli Katt]] N https://esolangs.org/w/index.php?oldid=108396 * Ashli Katt * (+316) Created page with "Hello, I'm Ashli K. I enjoy programming languages, especially the ones found here! ==== Languages I've Made ==== * [[Tupilled]], a functional language with nothing but tuples. * [[Foreach]], a language with only arrays, with only for-each and functions as con
13:22:45 <esolangs> [[User:Ashli Katt]] https://esolangs.org/w/index.php?diff=108397&oldid=108396 * Ashli Katt * (+14) /* Languages I've Made */
13:25:02 <esolangs> [[Twoee]] M https://esolangs.org/w/index.php?diff=108398&oldid=72657 * PkmnQ * (-22)
13:29:45 -!- ais523 has joined.
13:30:07 -!- chiselfuse has joined.
13:35:48 -!- example99 has joined.
13:59:14 -!- __monty__ has quit (Quit: leaving).
14:13:06 -!- example99 has quit (Quit: Client closed).
14:13:15 -!- example99 has joined.
14:29:56 -!- Sgeo has joined.
15:45:44 -!- ChanServ has set channel mode: +o int-e.
15:45:53 -!- int-e has set channel mode: -bo *!*@2001:9e8:6735:5500:* int-e.
16:26:33 -!- example99 has quit (Quit: Client closed).
17:00:51 <esolangs> [[Brainfunct]] https://esolangs.org/w/index.php?diff=108399&oldid=108387 * Nurdle * (+105)
17:14:46 <esolangs> [[Talk:Brainfunct]] N https://esolangs.org/w/index.php?oldid=108400 * Nurdle * (+658) Created page with "==Computational Class== Neither version of brainfunct is truly Turing Complete due to the way brainfunct calls functions, the maximum amount of functions would be 255, though the nested version may be able to make it potentially infinite. ===brainfunct-slashes===
17:17:05 -!- example99 has joined.
17:18:34 <esolangs> [[Ulioisc]] https://esolangs.org/w/index.php?diff=108401&oldid=108354 * Example99 * (-1) /* labels and short form */
17:18:34 <esolangs> [[Brainfunct]] https://esolangs.org/w/index.php?diff=108402&oldid=108399 * Nurdle * (+140) /* Computational Class */
17:29:23 -!- example99 has quit (Ping timeout: 245 seconds).
17:35:34 <esolangs> [[Talk:Brainfunct]] https://esolangs.org/w/index.php?diff=108403&oldid=108400 * Nurdle * (+153) /* Computational Class */
17:50:54 <esolangs> [[Brainfunct]] https://esolangs.org/w/index.php?diff=108404&oldid=108402 * Nurdle * (+139)
17:52:28 <esolangs> [[Brainfunct]] https://esolangs.org/w/index.php?diff=108405&oldid=108404 * Nurdle * (-11)
17:55:57 <esolangs> [[BrainFn]] https://esolangs.org/w/index.php?diff=108406&oldid=108381 * Nurdle * (+102)
17:58:37 <esolangs> [[BrainFn]] https://esolangs.org/w/index.php?diff=108407&oldid=108406 * Nurdle * (+225)
18:30:47 -!- vyv has joined.
18:51:38 -!- vyv has quit (Quit: Konversation terminated!).
18:53:12 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=108408&oldid=108343 * Peter * (-87) /* Proposed category: RISC */
18:53:38 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=108409&oldid=108408 * Peter * (-225) /* List of all categories? */
19:16:31 -!- FreeFull has joined.
19:40:52 -!- Noisytoot has quit (Quit: ZNC 1.8.2 - https://znc.in).
19:41:28 -!- Noisytoot has joined.
20:52:36 <esolangs> [[Special:Log/newusers]] create * Gatesolang * New user account
20:56:02 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=108410&oldid=108364 * Gatesolang * (+155)
23:51:24 <esolangs> [[Special:Log/upload]] upload * Nurdle * uploaded "[[File:BrainFn-logo.png]]": The official logo of brainFn
23:55:06 <esolangs> [[BrainFn]] https://esolangs.org/w/index.php?diff=108412&oldid=108407 * Nurdle * (+93)