Yeah, since it's not even a cross-compiler... as you'd need closures, tail recursion etc.
I am thinking of Haskel machine in J. > From: Erling Hellenäs <[email protected]> > > Hi all ! > > I must admit, if there is anything serious in this, I don't understand it. A > crosscompiler from Haskell to J ? Why would it be useful ? > > Cheers, > > Erling > > -----Original Message----- > From: [email protected] [mailto:[email protected]]on > Behalf Of Oleg Kobchenko > Sent: den 2 oktober 2009 23:26 > To: Chat forum > Subject: Re: [Jchat] Haskell > > > > Put differently, if I were to implement J in Haskell, I would > > > This is only one way to approach it. Quite another, which > I think is more interesting: is to implement Haskell in J. > (Haskel is just another Lisp even more so than Smalltalk, > the similarity with which is the use bytecode in some Haskells.) > > J can act as a backend. Here's JavaScript acting as a backend > in the a browser: > > http://haskell.org/haskellwiki/Haskell_in_web_browser > > > > > > From: Raul Miller > > > > On Fri, Oct 2, 2009 at 9:36 AM, Erling Hellenäs > > wrote: > > > I think the J notation is shorter than the Haskell notation. If you see > J as > > > a "homogenous algebra", I'm interested in how a Haskell implementation > or a > > > compiled language written in Haskell that uses something similar to this > > > algera would look. The type information in Haskell is impressive, and I > > > didn't mean to say it could be shorter. > > > > Well... > > > > From my point of view, J's functions have domains which > > do not map well onto types. In the general case, every > > function's domain can be independent of any other function's > > domain. And, when the result of one function is used as > > the argument for another, the derived function may have > > some yet different domain. > > > > For example, the domain of i.@,~@(^&1r2) is square numbers. > > > > Types, from my point of view, are an attempt at characterizing > > domains, but with constraints on what can be represented > > to avoid issues with the halting problem. And, I believe that > > if you work around those constraints, I think you lose a lot of > > the power of the type system. > > > > Put differently, if I were to implement J in Haskell, I would > > build myself an array type, which contained a list of > > dimensions and a sequence of lists of primary data (each > > sequence would be a different primitive type -- character, integer, > > float, etc, and.only one of them could be non-empty). I would also > > want an efficient way of determining which of those types > > was present. I think this would let me implement any J operation > > in Haskell, but I do not think Haskell's type system would give me > > much traction on functions which use this data type. (But I could > > be wrong, maybe Haskell's type system can make meaningful > > and significant inferences in this context? Mostly, though, I think > > it would be telling you when you were passing "non-J-like" data to > > "J-like functions" which is an issue which you do not even have > > to consider when you work directly in J.) > > > > Does my point of view make sense to you? > > > > If so, do you agree or disagree with me? > > > > If not, where does what I wrote start descending into nonsense > > for you? > > > > Thanks, > > > > -- > > Raul > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
