djspiewak
-
I must admit though, there's a lot of nerd cred to be had from configuring your own kernel or manually installing a bootloader.
about 11 hours ago
from Tweetie
-
Ah, the joys of Gentoo! It's so rewarding to finally complete that 14 hour marathon tweaking something Ubuntu would have handled for you.
about 11 hours ago
from Tweetie
-
@ +1 My understanding is that JDI really doesn't impose much overhead at all. A lot of companies run their production apps that way.
about 13 hours ago
from Tweetie
in reply to wycats
-
Wow! RT @: Final success! A primitive ObjectSpace.each_object using JDI debug hooks:
about 13 hours ago
from Tweetie
-
@ The prag book is very good. Mix in a healthy dose of REPL, a little Emacs and a nice experimental project.
about 14 hours ago
from Tweetie
in reply to al3x
-
RT @: I think I'm just going to go ahead and add gradual typing to JRuby. At some point.
about 16 hours ago
from Tweetie
-
@ What do you mean by "non-CFG"? Recursive nested comments are still context-free, they just require scannerless parsing (e.g. SGLR).
about 18 hours ago
from Tweetie
in reply to alblue
-
@ Scala's grammar is still context-free. It may not look like it, but it is (aside: Haskell and C/C++/Obj-C are *not* context-free).
about 18 hours ago
from Tweetie
in reply to alblue
-
@ Sure, code gen differs based on how exactly something is used, but the parser can annotate that into the AST.
about 18 hours ago
from Tweetie
in reply to alblue
-
@ Formal grammars with ambiguities tend to be *easier* to develop than strictly LL or LALR equivalents (if they exist).
about 19 hours ago
from Tweetie
in reply to alblue
-
@ I'm not sure I buy that. Sure, ambiguous grammars require more powerful parsing techniques, but they aren't that hard to use.
about 19 hours ago
from Tweetie
in reply to alblue
-
@ Similarly, the production `expr ID expr` is always sugar for `expr.ID(expr)`.
about 19 hours ago
from Tweetie
in reply to alblue
-
@ There is no rule `expr expr` anywhere in the grammar. The production `expr ID` is always sugar for `expr.ID()`.
about 19 hours ago
from Tweetie
in reply to alblue
-
@ Actually, *neither* of your possible interpretations are valid. e.g. `(foo !) bar` will parse as `foo.!().bar()`.
about 19 hours ago
from Tweetie
in reply to alblue
-
@ Either way though, what you're talking about is a parser ambiguity and has absolutely nothing to do with language versions.
about 19 hours ago
from Tweetie
in reply to alblue
-
@ Scala does not support the "space syntax" for n-ary functions. Thus, `foo ! bar` can *only* be `foo.!(bar)`.
about 19 hours ago
from Tweetie
in reply to alblue
-
@ That's very true, but I'm not sure how that relates back to `foo ! bar`.
about 19 hours ago
from Tweetie
in reply to alblue
-
@ The scala parser distributes the resolution rules, and that's a large part of why it's so dreadfully unmaintainable.
about 20 hours ago
from Tweetie
in reply to alblue
-
@ My point is that Scala's grammar really requires a generalized parser which discretely handles the ambiguous cases.
about 20 hours ago
from Tweetie
in reply to alblue
-
@ Unfortunately, it would also mean much longer compile times, higher memory usage and more complex typing.
about 20 hours ago
from Tweetie
in reply to alblue
|
|
