|
tef posted:i mean, i could give up on having negative lookahead and ordered choice, yes, but i've decided that returning shift/reduce errors isn't an improvement does trying to snow people by throwing around jargon often work for you? did I say some words that sounded like “I think you should have gone with LALR” to you?
|
#
?
Jan 28, 2024 00:47
|
|
|
|
| # ? May 26, 2024 17:10 |
|
|
Nomnom Cookie posted:the real answer is it sounds to me like you’ve boxed yourself in by choosing peg too early. first figure out what set of accepted grammars has the right ergonomics then make a judgment on how you’re going to handle them. imo that's kinda what i'm doing: i have pegs + left recursive features, and i'm trying to make this judgement Nomnom Cookie posted:does trying to snow people by throwing around jargon often work for you? did I say some words that sounded like “I think you should have gone with LALR” to you? like, "you chose peg too early" ~> "you chose top down methods too early, if left recursion is a problem you want to solve" "figure out the right set & handle them" ~> "left recursion generally means handling things bottom up in some form or another, which inevitably means building some sort of LR like automaton to handle the nondeterminism" i did assume you weren't suggesting any of the methods i'd already outlined to bolt things onto the peg engine, like cancellation parsing or precedence climbing, you were suggesting i go back and find a "one size fits all approach", but really, unless you were about to spring an earley parser on me, you were going to suggest some form of LR parsing i mean, sure, maybe you're a big fan of demer's generalised left corner parser but i figured if that was the case you'd have been infodumping and not shitposting Nomnom Cookie posted:pop up a message box that says here’s a lookahead kid go get yourself a real grammar but mostly this set the vibe, hth
|
|
#
?
Jan 28, 2024 03:10
|
|
|
tef posted:that's kinda what i'm doing: i have pegs + left recursive features, and i'm trying to make this judgement no I was saying you need to decide what would be a good interface to present to users and have that drive implementation. writing grammars is really loving hard so a tool that consumes grammars isn’t going to be worth a poo poo without obsessive focus on what grammars users will write and how to make success as easy as possible. what algorithm you end up using is entirely contingent I do like earley parsers because that lets you decouple the capabilities of the parser from the grammars you accept and focus purely on creating useful restrictions rather than working around the limitations of your parser. but that is not really relevant here
|
|
#
?
Jan 28, 2024 04:22
|
|
|
tef posted:i have this parsing evaluation grammar, i want to extend it with means of defining stuff like infix operators. like `e := e "+" e`, and i'm mulling over the various ways of trying to make it work just use prefix S-expressions
|
|
#
?
Jan 28, 2024 06:57
|
|
|
tef posted:especially because i'm also parsing markup languages well there’s your real problem
|
|
#
?
Jan 28, 2024 07:00
|
|
|
eschaton posted:just use prefix S-expressions (now (have you (problems two)))
|
|
#
?
Jan 28, 2024 07:50
|
|
|
Visions of Valerie posted:(now (have you (problems two))) lmao
|
|
#
?
Jan 28, 2024 08:27
|
|
|
Presto posted:inline static const std::unordered_map<const unsigned long long* const, const unsigned long long* const>* const butts = nullptr; Is it weird that the craziest part of this to me was that you were using a pointer as a map key?
|
|
#
?
Jan 28, 2024 10:07
|
|
|
Visions of Valerie posted:(now (have you (problems two))) thread title
|
|
#
?
Jan 28, 2024 13:56
|
|
|
Visions of Valerie posted:(now (have you (problems two)))
|
|
#
?
Jan 28, 2024 14:39
|
|
|
Visions of Valerie posted:(now (have you (problems two)))
|
|
#
?
Jan 28, 2024 15:00
|
|
|
Presto posted:inline static const std::unordered_map<const unsigned long long* const, const unsigned long long* const>* const butts = nullptr; think they are referring to this https://en.cppreference.com/w/cpp/language/value_category quote:a glvalue (“generalized” lvalue) is an expression whose evaluation determines the identity of an object or function; and it keeps changing...
|
|
#
?
Jan 28, 2024 15:28
|
|
|
Phobeste posted:thread title
|
|
#
?
Jan 28, 2024 15:44
|
|
|
Sweeper posted:think they are referring to this https://en.cppreference.com/w/cpp/language/value_category i read that quote and the only thing i can think of is "did you just tell me to go gently caress myself?"
|
|
#
?
Jan 29, 2024 21:13
|
|
|
https://i.imgur.com/3wlxtI0.gifv still cracks me up
|
|
#
?
Jan 29, 2024 21:35
|
|
|
pokeyman posted:https://i.imgur.com/3wlxtI0.gifv still cracks me up and you still end up with bugs caused by something uninitialized somewhere
|
|
#
?
Jan 29, 2024 23:11
|
|
|
Zlodo posted:and you still end up with bugs caused by something uninitialized somewhere thats just another form of initialization
|
|
#
?
Jan 30, 2024 00:34
|
|
|
Zlodo posted:and you still end up with bugs caused by something uninitialized somewhere shrimp are the bugs of the sea
|
|
#
?
Jan 30, 2024 01:03
|
|
|
the main reason to hate c++ is that probably some of the finest pl pedants of our generation are tied up in defining all the irrelevant poo poo going on in it.
|
|
#
?
Jan 30, 2024 01:30
|
|
|
that sounds like a good thing tho it’s a containment zone
|
|
#
?
Jan 30, 2024 01:33
|
|
|
c++ language efforts compared to “digging holes, then filling them in again so PL researchers / developers don’t go and invent yet more languages”? bjarne stroustrup 🫡
|
|
#
?
Jan 30, 2024 02:32
|
|
|
Cybernetic Vermin posted:the main reason to hate c++ is that probably some of the finest pl pedants of our generation are tied up in defining all the irrelevant poo poo going on in it. iirc the reason for inclusion was "it would really improve C++ adoption among students" which is clearly the thing the STL should be focusing on
|
|
#
?
Jan 30, 2024 09:56
|
|
|
no that proposal was obsoleted by the other proposal to put an entire web browser in the standard library
|
|
#
?
Jan 30, 2024 12:12
|
|
|
To be fair (lol), there is no mechanism to force someone to stop submitting a paper. As long as someone wants to, they can keep sending in the 2d graphics paper.
|
|
#
?
Jan 30, 2024 14:27
|
|
|
was the problem that the committee was being kind and not telling the person "lol. lmao. no." amd instead giving constructive feedback on a proposal that would never accept?
|
|
#
?
Jan 30, 2024 15:04
|
|
|
repiv posted:no that proposal was obsoleted by the other proposal to put an entire web browser in the standard library
|
|
#
?
Jan 30, 2024 15:29
|
|
|
the problem was that it was herb sutter's idea and you can't just go "lol no" to the chairman of the committee
|
|
#
?
Jan 30, 2024 16:46
|
|
|
just put tk into every language spec imo
|
|
#
?
Jan 30, 2024 17:04
|
|
|
every graphical operating system has apis for opening a window, flipping a texture to that window, and obtaining keyboard and pointer events smoothing out the differences between these apis to achieve a portable and reasonably performant common denominator is a gigantic pain in the rear end. multiple very complicated open source libraries exist to achieve this goal, with varying amounts of additional bells and whistles: SDL, raylib, allegro, etc it would be nice if the creators of more languages and language ecosystems considered being able to do that sort of poo poo out of the box essential, rather than some kind of esoteric distraction from the real language approach of offering stdio and leaving users to write their own bindings to C libraries if they need anything else
|
|
#
?
Jan 30, 2024 17:12
|
|
|
precisely because platform apis are so different, a portable library over them is a recipe for a lovely experience both for programmers and users. inevitably you end up less wrapping the platform frameworks and more implementing your own quixotic least-common-denominator framework that unsurprisingly ends up looking and feeling totally different from the normal platform
|
|
#
?
Jan 30, 2024 17:47
|
|
|
microsoft is deftly solving that problem by having so many disparate UI frameworks that nobody can even tell what's supposed to be the native look and feel anymore
|
|
#
?
Jan 30, 2024 17:50
|
|
|
I am emphatically not talking about a "UI framework"; i'm talking about a minimum-viable IO layer like SDL, Raylib, and Allegro, which have been a perfectly acceptable "experience" for building hundreds of thousands of games and applications
|
|
#
?
Jan 30, 2024 18:10
|
|
|
but then why not fix the underlying issue of it being a major pain in the dick to be able to use external libraries (and in a way that compiler implementors actually can build, so maybe not like modules) i mean, having something like sdl in the stl would mean that every new os or wm feature would take six years to land in major compilers. sure, it'd be standardised but you can also "standardise" simply by using sdl
|
|
#
?
Jan 30, 2024 18:48
|
|
|
Internet Janitor posted:every graphical operating system has apis for opening a window, flipping a texture to that window, and obtaining keyboard and pointer events except that it sucks when they build in a cross-plat interface, like Java did. poo poo looks like rear end
|
|
#
?
Jan 30, 2024 20:14
|
|
|
awt and swing look dated and non-native, and are kind of a pain in the rear end to use, but they're functional. with a little effort you can get results comparable in many ways to Qt, but unlike Qt you don't have to run all your code through an insane custom preprocessor java2d, the graphics foundation that underlies awt, is much closer to what i'm advocating. it provides performant (hardware accelerated where available) and perfectly cross-platform basic canvas-style drawing capabilities
|
|
#
?
Jan 30, 2024 21:28
|
|
|
the big issue is if you start saying "i want this code to look like it's using native os widgets with native styling", while simultaneously saying "i want it to look the same on every platform", which are two goals that are literally impossible to achieve simultaneously
|
|
#
?
Jan 30, 2024 21:31
|
|
|
at no point have i remotely implied i want to be able to make anything look like it's using native widgets with native styling
|
|
#
?
Jan 30, 2024 21:33
|
|
|
i give very few shits about things looking native, as nothing does anyway. i do otoh think that just providing some drawing primitives will inspire some bad decisions about internationalization and accessibility. tbh in 2024 it is simply the reality that the way to do a ui in a sensible way is some kind of webview.
|
|
#
?
Jan 30, 2024 21:35
|
|
|
p-js: just added a non-trivial unit test to my project and had to add this to my __init__.py:Python code:
|
|
#
?
Jan 30, 2024 22:29
|
|
|
|
| # ? May 26, 2024 17:10 |
|
|
I see the appeal of just not doing native ui but whenever I have to use some text edit control that implements yet another completely different, wildly insufficient subset of the behaviors that every Windows text box since '95 supported, it does make me feel like a high level widget toolkit ought not only to ship with the programming language but actually be mandatory to use unless you have a waiver from one of those old times HIG experts
|
|
#
?
Jan 30, 2024 23:42
|
|
