The more I think about it, the more I think that naming things to avoid symbols is a mistake - names can have unintended connotations and they hide relationships between things.
However, using them for occasional pedagogic illustration can be useful. On Sun, Jan 19, 2014 at 12:37 AM, Steven Taylor <[email protected]> wrote: > I mean a push button translation a bit like the inverse of flatten f., but > for teaching purposes. > > On 19 Jan 2014, at 05:34, Steven Taylor <[email protected]> wrote: > > > Is it worthwhile to have a translation to/from a long form? Would this > help with adoption? > > > > > > scan=:\ > > insert=:/ > > sum=:+ > > til=:i. > > scan=.\ > > NB. same as +/\i.20 > > sum insert scan til 20 > > > > NB. but what about special forms? > > scan3=:\&3 > > sum insert scan3 til 20 > > > > > > On 17 Jan 2014, at 17:01, Devon McCormick <[email protected]> wrote: > > > >> Thanks for the tips. > >> > >> I will attempt to emphasize the practical values of 1) being able to > hold > >> an entire solution in one's head > >> at once, and 2) time-to-completion as a good metric of efficiency, not > >> "how quickly code runs". > >> > >> For the parens example, I'm thinking of showing it something like this: > >> > >> phrase=. '0{11{22{333}222}1}0' > >> +/\ 1 _1 0 {~ '{}' i. phrase > >> > >> Then backing up to explain successive sub-expressions in order of > >> evaluation. I may further elaborate by assigning the verb to a name and > >> generalizing this to take a left argument of the paren pair to use. > This > >> will allow me to introduce the tacit/explicit distinction as well. > >> > >> I think my basic problem is to avoid trying to cover too much, so I'm > now > >> thinking of showing a few other variants of scan, then maybe "cut" or > the > >> "power" conjunction. > >> > >> > >> > >> On Fri, Jan 17, 2014 at 11:24 AM, Roger Hui <[email protected] > >wrote: > >> > >>> Suggestion: Make more of a distinction between the data and the code. > >>> Thus: > >>> > >>> x=: '@{ foo; if (abc) { if (q) { m; } } }' > >>> > >>> +/\ 1 _1 0 {~ '{}' i. x > >>> > >>> > >>> > >>> > >>> > >>> On Fri, Jan 17, 2014 at 7:50 AM, Joe Bogner <[email protected]> > wrote: > >>> > >>>> If it's helpful for the presentation, I wrote up how the parentheses > >>>> nesting idiom looks in a few other languages: > >>>> > >>>> There are two relevant concepts - the array thinking and the > >>> implementation > >>>> > >>>> J > >>>> +/\(1 _1 0){~'{}' i. '@{ foo; if (abc) { if (q) { m; } } }' > >>>> 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3 3 3 3 2 2 1 1 > 0 > >>>> > >>>> Javascript > >>>> var runsum=0;'@{ foo; if (abc) { if (q) { m; } } > >>>> }'.split('').map(function(x) { var opp={'{':1,'}':-1}; return > >>>> opp[x]||0; }).map(function(x) { runsum = x+runsum; return runsum; }) > >>>> 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, > >>>> 2, 2, 2, 3, 3, 3, 3, 3, 2, 2, 1, 1, 0 > >>>> > >>>> PicoLisp > >>>> (reverse (mapcon '((X) (list (apply + X))) (reverse (mapcar '((X) > >>>> (cond ((= X "{") 1) ((= X "}") -1) (T 0))) (chop "@{ foo; if (abc) { > >>>> if (q) { m; } } }")) ) )) > >>>> (0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3 3 3 3 2 2 1 > 1 0) > >>>> > >>>> > >>>> > >>> > http://csilo.com/!article?2014/01/15/J-vs-Javascript-vs-PicoLisp-short-comparison > >>>> > >>>> On Fri, Jan 17, 2014 at 10:41 AM, Devon McCormick <[email protected] > > > >>>> wrote: > >>>>> I'll be talking on J to a meetup here in New York this coming > Tuesday - > >>>>> http://www.meetup.com/7-Languages-in-7-Months-NYC/ - so I've been > >>>> watching > >>>>> the "fork examples" discussion w/some interest. > >>>>> > >>>>> I did a dry run of my talk at NYCJUG this past Tuesday and, at that > >>>> time, I > >>>>> was looking to build up to a final, mind-blowing example like the > >>>>> Newton-Raphson iterator, but now am thinking that that's too "tricky" > >>> and > >>>>> what I'd really like to do is go into detail on some simpler > examples. > >>>> Joe > >>>>> Bogner's interest in the parenthesis-nesting idiom reminded me of how > >>>>> innovative the array approach still is, so I'm definitely using that > >>> one. > >>>>> > >>>>> David Lambert, who was at the NYCJUG meeting has also given me a > couple > >>>> of > >>>>> good ideas since then but I'm interested in anyone else's favorite J > >>>> idiom > >>>>> - "Jems" as Dan would have it - that illustrate the usefulness of > array > >>>>> thinking. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Devon > >>>>> -- > >>>>> Devon McCormick, CFA > >>>>> > ---------------------------------------------------------------------- > >>>>> For information about J forums see > http://www.jsoftware.com/forums.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 > >>> > >> > >> > >> > >> -- > >> Devon McCormick, CFA > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
