HI all ! Hehe. Well a compiling J with lazy evaluation and only one(1) :) type does not seem that bad. I guess with Haskell classes this one type can be resticted if you want.
I think I understood most of your reply. My goal was not to get the Haskell type system, but I guess type information of some kind is necessary for compilation. I'm not sure if the possibility to declare class and type information could make the J programs easier to read or more foolproof to use. Haskell can also do lots of nice things if you pass functions as function arguments. I hope for other ideas around this. Maybe I can pass the detailed questions on to our other readers. Cheers, Erling -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of Raul Miller Sent: den 2 oktober 2009 17:06 To: Chat forum Subject: Re: [Jchat] Haskell On Fri, Oct 2, 2009 at 9:36 AM, Erling Hellenäs <[email protected]> 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
