Ouch.. I had meant to say a bit more about ambiguities, but my touchpad acted in a way that sent the message within a small fraction of a second from when I selected it to edit. That was not my original intent, at least in the sense of how my personal taste would have expressed that intent.
Nevertheless, since my point was something along the line of "ambiguities are, to some degree, unavoidable", perhaps it can also serve as an illustration. We can squeeze ambiguities out of our expressions, but we have too many concepts of abstraction to avoid ambiguities on all of them. In the case of my accidental sending of a message without content, I can take that as an illustration of an ambiguity in the user interface which I use to compose my email. Specifically: it has a "design feature" where the machine can send a message nearly instantly without me managing to use the keyboard at all. (And there are a number of aspects about the touchpad implementation which I think could be significantly improved, though I mostly ignore such issues.) All programming languages have similar characteristics. I just happen to find J's approach to be particularly appealing to my personal tastes. On a related note, $$y might be an expression for the rank of y, but ($$) y is not. It's kind of interesting, though, to speculate on what constraints and contexts would make ($$) into a useful operation. [If we ignore its value, for example, it can be a mechanism for rejecting values of y which cannot be valid shapes - but we would also need a constraint on size unless were were prepared to ignore some denial of service style resource overruns. (And before you entirely reject the idea of allowing resources to be consumed without application-imposed-bounds, realize that many web applications use regular expressions which have been implemented with similar flaws.)] Thanks, -- Raul On Sun, Oct 6, 2013 at 9:23 AM, Raul Miller <[email protected]> wrote: > On Sun, Oct 6, 2013 at 8:59 AM, Henry Rich <[email protected]> wrote: >> My view of ambiguities is less tolerant. Yes, English is a wonderful >> language for expressing ambiguities, but it is not wonderful when you are >> trying to avoid ambiguities. Legal writing & government regulations are so >> ugly because that's the kind of English you are forced to use to say exactly >> what you mean. >> >> Is 3 'more than' $0? I don't know. But I think it's wrong to seek the >> answer in the result of the execution of a sentence. I could appeal to >> >> if. 3 > $0 do. >> smoutput 'it's greater!' >> end. >> >> as answering the question 'formally'. But then, >> >> if. -. 3 > $0 do. >> smoutput 'it's not greater!' >> end. >> >> I would find that my definition of 'formal' needs work. >> >> I don't think different expressions for the same computation represent >> ambiguity. Ambiguity is multiple meanings for the same expression: magical >> in poetry, abhorrent in technical writing, intolerable in a computer >> language. >> >> Henry Rich >> >> >> >> >> On 10/6/2013 6:00 AM, Raul Miller wrote: >>> >>> If we think of this in J terms, we might treat "more" as a verb such as >>> >>> more=: > >>> >>> Then your first sentence becomes a question about 3 > ,2 which has an >>> answer which matches ,1. >>> >>> Your second sentence would involve more work to translate to J. I >>> could translate it as >>> (3 > $0) +. 3 > 4 1 >>> >>> ... but this gives us a length error, and our distaste for errors >>> might drive us further afield, to find another translation for "or". >>> If we felt exploratory, we might try: >>> >>> or=: ; >>> >>> so another almost plausible translation could be >>> ($0) ;&(3&>) $4 1 >>> >>> Put differently, english is a wonderful language for expressing >>> ambiguities and translation tends to freeze some of those ambiguities >>> in the resulting work. >>> >>> With J we are also faced with ambiguities, but because it is an >>> executable notation we get another perspective on ambiguities of >>> expression, where different expressions might achieve the same end. >>> >>> Thanks, >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
