I must come in on the side of Björn here. Not for myself: reading other people's tacit expressions don't in practice give me too many problems (you can worry them out using 5!:2 or 5!:6 until you can understand them). But, writing "J in a Day" http://www.jsoftware.com/jwiki/JinaDay I found I couldn't point my novice readers at an "accepted" effective procedure for analysing a tacit expression.
13: '...' lets you convert a suitably amenable explicit definition into tacit, but there's no equally straightforward tool (which one might call a "decompiler") for going the other way. This harks back to the time-honoured jibe at APL that it is a "write-only" language. A search of the wiki on 'tacit' reveals a lot of good work by a lot of clever people on developing methods and tools to analyse tacit expressions. Let me draw attention in particular to: http://www.jsoftware.com/jwiki/Scripts/TacitToExplicit --tool by Zsban Ambrus http://www.jsoftware.com/jwiki/DavidAlis/TacitExpressions --tool http://www.jsoftware.com/jwiki/Guides/Reading%20Tacit%20Verbs --hand http://www.jsoftware.com/jwiki/PascalJasmin/Explicit%20To%20Tacit%20Reference%20Card --hand If reading tacit expressions posed no significant problems to anyone except dunces, then surely there would have been no need for this work and it would not have been done? So doesn't this put Björn's assertion beyond debate? Ambrus's approach seems the most promising from a novice's pov (one expert in another programming language). It's convenient: a pair of adverbs (one each for monadic/dyadic usage) which, applied to a given tacitly defined verb, decompile them into working explicit definitions. Reminds you of (f.). But does it all represent finished work? BTW This is what they give for Björn's example: bjn=: [: +/ [: > [: ".&.> [: [ [: {.&.> [: [ [: ":&.>@p: i. bjn ttem NB. monadic usage 3 : 0 p3=. i. y z3=. [ (":&.>@p:)p3 t4=. [ ({.&.>)z3 s4=. > (".&.>)t4 (+/)s4 ) bjn tted NB. dyadic usage 4 : 0 r4=. x i. y q4=. [ (":&.>@p:)r4 p4=. [ ({.&.>)q4 z4=. > (".&.>)p4 (+/)z4 ) 5!:6 breaks down z3 a little more, viz. into: ((":&.>)@p:), but the results look convincing enough. Ian 2010/11/21 Björn Helgason <gos...@gmail.com>: > I completely disagree. > There are very few people who can read and understand tacit expressions. > > 2010/11/16 Don Guinn <dongu...@gmail.com> > >> I thought the original issue was on how readable tacit expressions are, not >> the correctness or most efficient the expression. Based on the comments in >> this thread it seems that people can read the original tacit expression >> quite well. >> >> On Tue, Nov 16, 2010 at 11:53 AM, Roger Hui <rhui...@shaw.ca> wrote: >> >> > > My input is numbers and my output is numbers >> > > and fundamentally I'm doing arithmetic - so why should I have to >> > > translate to strings & back? (I know the answer, I'm just >> > > giving you my thought process. ... >> > >> > I am curious regarding what "the answer" is. >> > >> > There is an analogy from mathematics. Number theory >> > (the study of integers) advanced by leaps and bounds >> > with the application of the the machinery of calculus and >> > complex analysis. Why should complex numbers >> > have anything to do with integers? >> > >> > >> > >> > ----- Original Message ----- >> > From: Dan Bron <j...@bron.us> >> > Date: Tuesday, November 16, 2010 9:30 >> > Subject: Re: [Jprogramming] tacit programming >> > To: 'Programming forum' <programming@jsoftware.com> >> > >> > > Raul wrote: >> > > > {.&.":&> seems more natural than anything involving #: >> > > or #.inv >> > > >> > > I'll buy that as a practical matter. But as a notational >> > > matter, it just >> > > doesn't "feel" right to me. My input is numbers and my >> > > output is numbers >> > > and fundamentally I'm doing arithmetic - so why should I have to >> > > translateto strings & back? (I know the answer, I'm just >> > > giving you my thought >> > > process. This similar to the reason I was nettled by >> > > "."0@": being >> > > optimized rather than 10&#.^:_1 [1] .) >> > > >> > > > An issue here is that #: and #.inv are designed to pad >> > > with leading >> > > >> > > Yep, that's what stymied the first correction I sent to Bjorn: I >> > > had [: >> > > ({."1) 10 #.^:_1 p:@:i. but I had to change it to >> > > {.@(10&#.^:_1)@p:@:i.for exactly this reason (naturally, I >> > > realized this 14 microseconds after >> > > hitting "send" - OTOH I am always pleased to find a natural use >> > > for @ as >> > > opposed to @: and since {."1 required parens anyway, the new >> > > formulationwasn't any messier). >> > > >> > > But #: padding on the left is helpful much more >> > > often than it is a >> > > nuisance (we're array programmers, after all), so I shouldn't >> > > complain. >> > > -Dan >> > > >> > > [1] http://www.jsoftware.com/help/release/digits10.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 >> > > > > -- > Björn Helgason, Verkfræðingur > Fornustekkum II > 781 Hornafirði, > t-póst: gos...@gmail.com > gsm: +3546985532 > sími: +3544781286 > http://groups.google.com/group/J-Programming > > > Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans > > góður kennari getur stigið á tær án þess að glansinn fari af skónum > /|_ .-----------------------------------. > ,' .\ / | Með léttri lund verður | > ,--' _,' | Dagurinn í dag | > / / | Enn betri en gærdagurinn | > ( -. | `-----------------------------------' > | ) | (\_ _/) > (`-. '--.) (='.'=) ♖♘♗♕♔♙ > `. )----' (")_(") ☃☠ > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
