Thanks for your thoughts. It's nice to know what I missed discussing (mostly because I have been working on this subject too long to realize what needs explaining).
In terms of the implicit/explicit arguments, I'll mention that I didn't mean this as an alternative to explicit mapping on the whole. If I had posted more examples of code with implicit mapping, it would also be full of instances of "fork" and "map." I also would include in the language a function "domain" which takes a normal function and a domain function (which takes n arguments and returns a list of n booleans) and produces a function that maps according to that domain. It's a generalization of rank, and we could recover the rank conjunction from it by taking a length n vector r and feeding it to the domain as the function (r < #@$each), which compares the rank of the function to the rank of each argument. I'm not sure what you mean about Haskell's "deriving" descriptor. If I understand typeclasses at all, what "deriving" accomplishes is rather weak and not at all related to implicit mapping. You're right about the Haskell description. My intention was to formalize the ideas in the paper, but since it's dynamically typed, the type signatures don't accomplish much. Marshall On Sun, Feb 5, 2012 at 12:37 PM, Boyko Bantchev <boyk...@gmail.com> wrote: > On 5 February 2012 06:28, Marshall Lochbaum <mwlochb...@gmail.com> wrote: > > I've written a paper which describes a way to replicate and extend J's > > behavior with arrays and forks as part of a single framework. I thought > > this would be interesting to the J community since it elaborates on the > > kind of thinking that drives J's powerful approach to function > application. > > May I share some comments? > > 3.3: What is called ‘fork’ is not a fork in the J sense. > > 3.3: What is called commutativity in the last paragraph is in fact > associativity. Moreover, I find the whole explanation in this > last paragraph incorrect. > > 3.5: I am not sure I understand what it says. > > 4: ‘The idea of mapping when a function needs to map, rather than > when a user tells it to map, makes the mapping much more flexible > and powerful.’ > If you are saying that implicit (as opposed to explicit) mapping is > ‘much more flexible and powerful’, then I disagree. >> >> 4: ‘The idea of mapping when a function needs to map, rather than > > when a user tells it to map, makes the mapping much more flexible > > and powerful.’ > > If you are saying that implicit (as opposed to explicit) mapping is > > ‘much more flexible and powerful’, then I disagree. > > First, in J, it is the combination of rank and implicitness – and not > > the latter alone – that ensures flexibility. Without controllable > > verb ranks, implicit mapping is of little use. (Strange that you do > > not discuss ranks, of nouns or verbs, at all.) > > Second, explicit mapping has its own ways of bringing in flexibility > > and power: when map is a function, it can be properly typed (and type > > checked), composed, passed to other functions, partially applied, etc. > > Overall, it is hard to choose implicit or explicit as ‘the better’ > > mapping – they are just different. > > First, in J, it is the combination of rank and implicitness – and not > the latter alone – that ensures flexibility. Without controllable > verb ranks, implicit mapping is of little use. (Strange that you do > not discuss ranks, of nouns or verbs, at all.) > Second, explicit mapping has its own ways of bringing in flexibility > and power: when map is a function, it can be properly typed (and type > checked), composed, passed to other functions, partially applied, etc. > Overall, it is hard to choose implicit or explicit as ‘the better’ > mapping – they are just different. > > One form of ‘almost implicit’ mapping is Haskell's ‘deriving’ > descriptor that one can attach to a type (you do mention Haskell > but omit this relevant and very useful bit): once given, it > ensures implicit lifting (mapping) of functions to the level of > the said type; but one has the choice to use it or not. > > 6: Matrix-vector multiplication on p.7 does not work the way you > are presenting it. > > 7: This is really so much non-Haskell that it is probably not worth > including it at all. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
