Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Parser generators

Name: Anonymous 2014-09-16 23:41

Are they really better than handmade parsers? The code they produce is fucking ugly, it's cluttered with cryptic variable names and you need to read entire books to understand how they really work. Yet everyone claims writing parsers is stupid because we've had parser generators for years and they will always produce much better results.

How true is this statement? Is it akin to the ``you don't need to write ASM because compilers are much better than you'' bullshit? I, for one, have never been in a situation where I need to write my own assembly, but that doesn't make GCC any less of a piece of shit.

Name: Anonymous 2014-09-30 10:08

Just use Perl 6.

Name: Anonymous 2014-09-30 10:24

>>29
what does parsee have to do with this

Name: Cudder !MhMRSATORI 2014-09-30 12:21

>>30
Two words: recursive descent. Simple and more than fast enough. There's a reason GCC/Clang both use RD (and GCC used to use lex/yacc, changing to the RD one actually made it go a little faster: http://gcc.gnu.org/wiki/New_C_Parser ). otcc/tcc uses RD.

Fun fact: I heard that the bash bug wouldn't have happened if they used RD, since then they would've been far less inclined to use the whole bloody command parser/evaluator to evaluate a simple function definition instead of the piece of the parser that only handled funcdefs - you can't arbitrarily pull out a piece of a lex/yacc parser to reuse.

Name: Anonymous 2014-09-30 14:57

>>31
Gramps, it's 2014! Forget your "perl" already.

Name: Anonymous 2014-09-30 15:05

>>34
Hey, it'll be finished before the end of the century! and hopefully before I die

Name: Anonymous 2014-09-30 17:24

>>34
But >>31-san is right, Perl 6 grammars are good.

Fun fact: Rakudo bootstraps in essentially one pass by updating the language core incrementally at run time to provide the language features needed to complete the compilation of the compiler and standard library, including the grammar support needed to parse much of the code that the initial grammar can't parse.

Name: Anonymous 2014-09-30 18:03

Too bad Perl is SLOW AS BALLS

Name: Anonymous 2014-09-30 19:08

>>37
It's not Ruby slow, it's not even Python slow.

Name: Anonymous 2014-09-30 20:01

everything higher-order perl wrote of can be done better in lisp.

Name: Anonymous 2014-09-30 20:03

>>39
That's not the issue. When Lisp gets Perl 6 grammars we can talk.

Name: Anonymous 2014-09-30 20:05

>>40
lol u think common lisp isn't the best language
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooool

Name: Anonymous 2014-09-30 20:22

>>40
Theoretically, you could write a lisp macro that compiles perl 6 to lisp.

Name: Anonymous 2014-09-30 21:09

>>42
Bring it.

Name: Anonymous 2014-09-30 23:54

>>42
Theoretically, ducks can move across a infinite river in either direction.

Name: Anonymous 2014-10-01 0:42

>>44
Theoretically, dicks can fuck a throat even when the head in question is up an ass.

Name: Anonymous 2014-10-01 1:54

>>44
This is true.

Name: Anonymous 2014-10-02 3:35

SNOW BALLS

Name: Anonymous 2014-10-02 4:36

>>45
This is also true.

Name: Anonymous 2014-10-02 19:26

>>45
Like that Oboro chick in Taimanin Asagi.

Name: Anonymous 2014-10-13 18:19

Thanks to the recursive descent guy for pushing me in the right direction.
I am in a process of rewriting shitty ply code in funcparserlib, having fun doing so, while also making code more compact (parsing code is 30% of what it was LOC-wise).

Name: Anonymous 2014-10-13 22:17

You are told to write a parser for a small subset of the following languages for a scripting engine. Do you make your own parser, or do you use a generated parser?

1. R5RS
2. C
3. Symta
4. Haskell

Name: Anonymous 2014-10-14 3:56

>>51
1. Own parser.
2. Generated parser.
3. It looks top downable. Own parser.
4. Generated parser.

Name: Cudder !MhMRSATORI 2014-10-14 8:59

>>51
Own parser, obviously.

Name: Anonymous 2014-10-14 11:10

>>51
Own parser, always.

Name: Anonymous 2014-10-14 11:50

>>51
Parsin? For such trivial job, I would hire a nigger from Africa to do it for me.

Name: Anonymous 2014-10-15 1:30

Semantic parser, from emacs.

Name: Anonymous 2014-10-15 2:49

>>51
5. HTML
generated regex

Name: Anonymous 2014-10-15 7:08

You don't need to write ASM because compilers are much better than you. You cannot possibly deal with the stack at such a level that compilers can.

Name: Anonymous 2014-10-15 8:24

>>58
what are you even talking about? shit isn't that hard.

Name: Cudder !MhMRSATORI 2014-10-15 12:38

>>58
Maybe they're better than you, retard. Have you ever seen what MSVC, or even worse, GCC outputs?

https://lkml.org/lkml/2014/7/24/584

Name: Anonymous 2014-10-15 14:16

>>58
that's lame...

Name: Anonymous 2014-10-18 20:12

>>60
lol wat a fuckin autist

no point in pooping all over da fuckin mailing list over spilled milk

then cdr the truck echoes wenis torvalds' poopy on progrider lmao

was a good compiler, GCC. richy stolman built it himself out of gnu carcass

Name: Anonymous 2014-10-18 21:31

>>60

Have you ever seen what MSVC, or even worse, GCC outputs?
I've and they do optimizations, like loops unrolling, a human being would find too tedious to even consider.

Name: Anonymous 2014-10-18 21:46

>>63
lol this retard and his ``mental limits''

Name: Anonymous 2014-10-19 5:36

The dual of mental limits is anal colimits, also known as "anal cock-limits".

Name: Alexander Dubček 2014-10-19 6:04

Doubles generators

Are they really any better than handmade doubles? The numbers they produce are fucking ugly, they're cluttered with cryptic non-repeating digits and you need to read entire posts to understand how they really work. Yet everyone claims getting doubles is stupid because we've had doubles generators for years and they will always produce much better results.

How true is this statement? Is it akin to the ``you don't need to check my doubles because imageboards are much better than you'' bullshit? I, for one, have never been in a situation where I need to check my own doubles, but that doesn't make /prog/ any less of a piece of shit.

Name: TPoGDMI 2014-10-19 8:28

The Pleasure of Getting Dubs Manually Inside.

Name: Cudder !MhMRSATORI 2014-10-20 6:39

>>63
Loop unrolling is not a real optimisation. It's a stupid cache-bloating drag-race: "look how fast I can go in a straight line!!!!11"

Name: Anonymous 2014-10-28 13:08

68
Very fast in fact, if you consider that unrolled instructions happily run in parallel since the days of Pentium. This is basic knowledge for a modern compiler designer.
You can get up to 8x (12x on desktop AMD chips, 16x on Xeon) execution speed (relative to naïve sequential computation) if you are very mindful of what pipelines are occupied at what moment.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List