tag:blogger.com,1999:blog-7141432593100470479.post6992545112860996504..comments2014-02-08T17:04:23.690+00:00Comments on The Oblong: Type Frustrations II : Return of the ErasureSnuthttp://www.blogger.com/profile/06737686885066577411noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-7141432593100470479.post-33973680002960844742010-03-19T16:29:55.708+00:002010-03-19T16:29:55.708+00:00Hi James,
I didn't mention it because it'...Hi James,<br /><br />I didn't mention it because it's news to me!<br /><br />I really am a rank amateur when it comes to Haskell, and only <i>very, very slightly</i> better with Scala. A lot of my frustration is not aimed at type erasure per se, but my thwarted expectations whenever it pops up. It looks obvious and correct, but doesn't work.<br /><br />Maybe this is the kind of thing manifests will help deal with. Simply tagging the Var[A] with an automatically generated type string might be sufficient for my needs...<br /><br />Regarding the nicely compact refactoring, I'm ashamed to admit I've not encountered the Scala backtick before. I assume it was left out of the original paper in this case to prevent the introduction of additional syntax.<br /><br />Cheers for the comment, and for introducing me to a handy bit of sugar!Snuthttps://www.blogger.com/profile/06737686885066577411noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-50364325079017766622010-03-19T15:40:30.892+00:002010-03-19T15:40:30.892+00:00You mention Haskell but what you don't mention...You mention Haskell but what you don't mention is that GHC Haskell lives in type erasure land. It just doesn't get you into trouble because, unlike Scala, there isn't a general "match on dynamic type" mechanism - only a match on constructor mechanism.<br /><br />Anyway, since v.type is the singleton type of v, I have to ask why you don't write the much simpler<br /><br /> def apply[B]( w: Var[B] ) : B = w match {<br /> case `v` => x<br /> case _ => Env.this.apply(w)<br /> }<br /><br />The backticks just mean you don't want to bind a new v you want to use an existing binding and match for equality (using .equals).James Iryhttps://www.blogger.com/profile/02835376424060382389noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-84213953508962219022010-03-19T12:26:15.320+00:002010-03-19T12:26:15.320+00:00Hey Paul, cheers for the comment!
I suspect I sho...Hey Paul, cheers for the comment!<br /><br />I suspect I should have written with more clarity on this point: I'm not interested in implementing any flavour of lambda calculus.<br /><br />I have a far less interesting problem. I want to represent a wide variety of game objects in a manner which is elegant to use and extremely flexible. The standard approach of just writing static classes is, well, boring to implement and inflexible. Component systems are pleasantly labile but tend towards ugly syntax, at least in my implementations.<br /><br />The 'property bag' approach is nice, but static typing in Scala makes it a pain to implement and, again, it gets ugly (Clojure or another lisp makes this deliciously easy). This implementation of environments <i>seemed</i> to address this, but run afoul of type erasure problems. Hence frustrated blog post and re-examining dynamically typed languages.<br /><br />I'll check out Kawa again, though, thanks for reminding me! Common Lisp is a bit... warty, I'm more of a Scheme person I suspect.<br /><br />I'm not married to the JVM, but it does make an interesting platform for writing windows/linux games and I am a huge fan of Scala, so anything with easy Java interop gets points.<br /><br />Re: Clojure... it's hardly pure, based on my limited experience. Like Scala, it defaults to a functional style but you can drop into imperative mode as needed, which seems very practical for writing (certain classes of) games. I'm not fussed about OO for the game logic, either.Snuthttps://www.blogger.com/profile/06737686885066577411noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-89768617466151099052010-03-19T01:20:23.827+00:002010-03-19T01:20:23.827+00:00First of all, if you're thinking of reimplemen...First of all, if you're thinking of reimplementing the lambda calculus, it's time to start using a lisp.<br /><br />If I wanted to write a game using a lisp within the JVM, I would look at either Armed Bear Common Lisp, or Kawa (scheme). Maybe the latter as Kawa is more mature, though I think CL is the superior language.<br /><br />If you don't require the JVM, there are many more options.<br /><br />Clojure is a very interesting language, but quite young, and lacks any OOP facilities (Rich Hickey is set firmly against OOP). More generally, it's a pure functional language like Haskell, and there is a reason that almost no games are written in such languages: it is a very unnatural paradigm in which to write games.eeeickythumphttps://www.blogger.com/profile/05779996702869044084noreply@blogger.com