Earlier quoted context omitted.
Also https://github.com/lihaoyi/Metascala for a JVM implemented in Scala running on the JVM.
Seems… redundant, no?
Seems like a reasonable goal.
21–30 of 185 posts
Earlier quoted context omitted.
Also https://github.com/lihaoyi/Metascala for a JVM implemented in Scala running on the JVM.
Seems… redundant, no?
Seems like a reasonable goal.
Great project, congrats! Mad respect. Started working on something very similar a few years back and gave up pretty soon for some stupid reason. Maybe I should try again, am getting better at getting stuff done.
I think of them as retirement projects before I retire. When I actually retire I'll maybe finish them.
(That said, I have in the past tried taking jobs that were adjacent to my "research" interests, and found the joy of building these things from scratch is much better than fiddling with the levers on the side of someone else's thing they built from scratch years ago. I like working on and improving production systems, but if they intersect too closely to my personal interests, it can be demoralizing.)
Earlier quoted context omitted.
I think op meant "String literals". For those the spec seems to require interning: > Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern. And later: > Literal strings within different classes in di…
Thanks, makes sense yes. Still if the JVM look up in all cases defers to value after ref mismatch, it should work identically, no? Even if interning is mandatory as per spec, I'm not sure how it'd change the outcome of evaluation.
Earlier quoted context omitted.
I think op meant "String literals". For those the spec seems to require interning: > Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern. And later: > Literal strings within different classes in di…
Thanks, makes sense yes. Still if the JVM look up in all cases defers to value after ref mismatch, it should work identically, no? Even if interning is mandatory as per spec, I'm not sure how it'd change the outcome of evaluation.
How often will this post be reposted on HN ? Recent posts: https://news.ycombinator.com/item?id=36735344 - 6 days ago https://news.ycombinator.com/item?id=36717967 - 7 days ago https://news.ycombinator.com/item?id=36710803 - 7 days ago (OP) Btw. nice project!
Doesn't really count as a repost if none of the previous submissions didn't get any traction.
Earlier quoted context omitted.
I think op meant "String literals". For those the spec seems to require interning: > Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern. And later: > Literal strings within different classes in di…
Thanks, makes sense yes. Still if the JVM look up in all cases defers to value after ref mismatch, it should work identically, no? Even if interning is mandatory as per spec, I'm not sure how it'd change the outcome of evaluation.