On Fri, Apr 3, 2015 at 10:54 PM, Aistis Raulinaitis <[email protected]> wrote: > Still, what I would really like to see is maybe some ability to add define > *closed* sums in J. https://en.wikipedia.org/wiki/Sum_type
You could say that J has closed sum types. Consider that an array can be numeric or literal or boxed, for example. How is that not a closed sum type? That said, you want to be able to *define* closed sum types. And that might seem like a minor thing, but I believe that *if done right* it's a massive project, because in my opinion doing it right requires considering the implications and mathematics of each of the existing verbs in the context of the new types, combining each of the new types with each of the existing types in the context of each of J's dyads, formatting these types for display, adding constants for some key elements of the new types to the language , the performance and implementation implications of these new types, and especially updating all the existing documentation to adequately describe the new types. So, anyways, that's a fair amount of pain and time that you should expect to have to deal with when defining closed types. And when I look at code people have written, I see a ton of effort going into this kind of thing and the usual result is systems that perform awfully and are easier to replace than to upgrade. Not that there's anything wrong with that... but you already have these abilities in other languages, so why not stick with them if that's what you want? > Since it's easy > to fake it with tags and such, you just don't get the benefits of > exhaustiveness checking. But to me, I don't really see how it would fit > into J and at this point is just a dream. Maybe one day. I agree with you - this seems like a poor fit to me also. Mind you, I do see some value to this approach if we were to start with a minimalist J subset -- toss out rank, toss out most of the verbs, toss out a lot of the existing types, build a compiler for the result and gradually work up to compatibility with existing J. But I expect mostly a lot of noise from such attempts. > I was wondering what your opinion on this blog post by Mr. Harper is: > https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ Hmm... First, the title "Dynamic Languages are Static Languages" - that's true to the degree that you are not willing to see distinctions between them. So right off, we've got a constraint on the relevance of the the meanings of these terms. If I accept this point of view as accurate, I don't see that there's anything interesting left to talk about. (Ok, not strictly true - for example, talking about plumbing could be interesting to talk about - but that's outside of the frame of reference he's imposing here.) Then, looking at his first paragraph, we see that he's talking about "less expressiveness" vs. "more expressiveness". But what does he mean by "expressiveness" and is this "expressiveness" a positive feature or a negative feature? And I expect that the answer to that question would have to be contextual. So what's his context? Reading through his post, I don't see that he's trying to solve any practical problem. It looks like he's trying to solve some kind of grammar problem. But my guess would be that he's actually objecting to some specific programming language characteristics in programming languages he's somewhat familiar with. But which ones? Looking over his book that he linked to, I see him mentioning ALGOL/Concurrent Algol/Distributed Algol/Modernized Algol/Parallel Algol, Caml/ML/Standard ML, Dynamic PCF/PCF, Haskell, Hope, Lisp, Miranda, Prolog, T. I might have missed some of what he had in mind here... But the emphasis on PCF, along with the range of languages he mentions, suggest that his focus is on language implementation more than anything else. It looks like he's trying to talk about the mathematics of compilers though I'm not sure that he's implemented any compilers (at least not in the sense of emitting machine code for any modern machines). And a problem with this approach is a tendency towards shallowness - it all sounds great but when you try to put it into practice these ideas sort of shatter and don't fit very well. But that's OK, I guess. First, it leaves plenty of room for other people to do other things. And second, any theory is going to only partially fit with practical problems - you wind up having to ignore practical issues to understand the theory, and vice versa. Put differently, there's plenty of art which goes into the physical side of things. > I'm almost certain that he did not have J on his mind when he was writing > it. Maybe you can give me and him a piece of your mind? Well... in the context of J... J can be thought of having dynamic types (nouns are an example) and J can be thought of as having a grammar with static types (we also have verbs and adverbs, for example). But that's not what's interesting about J. J's grammar is something you have to learn, if you want to learn to how to use J well, but J only becomes interesting when you use it to solve problems which are outside the scope of the language itself. But I sort of doubt that any of this is relevant in a context where we start by assuming that dynamic languages are static languages. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
