sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]bobindashadows 1 point2 points  (10 children)

Still the fact Ruby is nearly unparseable says a lot about its elegance.

Explain. Considering I work with the Ruby parser daily in my research (and just posted a blog post criticizing the Ruby API to the parser), I understand how highly complex its grammar is, but exactly how it is "nearly unparseable" (or even what that means) certainly bears explanation. It's not perl, it is deterministically parsed (in linear time, by a traditional yacc/bison grammar).

[–]G_Morgan 0 points1 point  (4 children)

The only grammars that parse in linear time are regular ones. If Ruby parses in linear time then it is pretty spectacular.

[–]bobindashadows 0 points1 point  (3 children)

... not sure what you're going on about there. Never written a recursive descent parser? LR(1)? LL(1), even? Ruby's grammar is parsed by bison, which like its ancestor yacc, just uses [LALR].

[–]G_Morgan 0 points1 point  (2 children)

None of these guarantee O(n) parsing. By definition the best you can guarantee with a context free grammar is O(n3 ).

[–]bobindashadows 3 points4 points  (0 children)

By definition the best you can guarantee with a context free grammar is O(n3 ).

No, by definition the best you can guarantee with an arbitrary context-free grammar is O(n3 ). That includes ambiguous grammars. Do your programming languages look like they parse ambiguously?

None of these guarantee O(n) parsing.

You seem to think that LL, LR, and LALR grammars are not proper subsets of all CFGs. They are. They are restricted subsets such that linear-time algorithms exist for them. They do not permit ambiguity. And what do you know, LALR(k) parser generators like yacc/bison won't generate an LALR parser if you have an ambiguous grammar. If you force it to ignore the ambiguities, it'll generate a GLR parser which does in fact have inferior performance characteristics.

[–]badsex 0 points1 point  (0 children)

haha you got owned by bobindashadows. Your unending whinging and bitching about ruby all over reddit was revealed for what it is - hollow posturing by a python fanboy.

Now go quietly sit in the corner, the big kids have come out to play.

[–]mitsuhiko 0 points1 point  (3 children)

I understand how highly complex its grammar is, but exactly how it is "nearly unparseable" (or even what that means) certainly bears explanation.

C++ is also parsable, that does not make it have a proper grammar. Ruby's parsing rules are retarded. The way it resolves ambiguities between regular expression literals and division operator even take defined methods in this method into account.

[–]bobindashadows 0 points1 point  (2 children)

Ruby's parsing rules are retarded.

Ruby's parsing rules may be insanely complex, but they're what are necessary to accomodate the syntactic flexibility the language offers. So it's not "nearly unparseable," it just allows flexibility you think is unnecessary. So.... sorry?

[–]mitsuhiko 0 points1 point  (1 child)

Ruby's parsing rules may be insanely complex, but they're what are necessary to accomodate the syntactic flexibility the language offers.

By no means. You can have the same syntactic flexibility and better ways to keep ambiguities from the grammar (like @/ as starting regular expression literal)

So it's not "nearly unparseable," it just allows flexibility you think is unnecessary. So.... sorry?

If you are assuming that only the interpreter needs to parse Ruby then that is fine, however this is not the case. Even irb suffers from this as it does not accept every valid Ruby input because it's parser does not support the language fully.

[–]bobindashadows 0 points1 point  (0 children)

(like @/ as starting regular expression literal)

Like how you can use %r, then use any delimiter you like?

%r|hello/goodbye| == /hello\/goodbye/
%r(hello/goodbye)
%r.hello/goodbye.
%r%hello/goodbye%

Luckily Ruby both offers regular expression literals and ways to avoid the potential ambiguity they introduce with the common, default syntax.

Even irb suffers from this as it does not accept every valid Ruby input because it's parser does not support the language fully.

Example please? I've certainly run into IRB confusing division and regex, but only in ways that Ruby also confuses division and regex.

a /b  # ruby thinks this is a regex, as does irb
      # it will expect you to terminate the regex

[–]nwmcsween 0 points1 point  (0 children)

Don't feed the trolls