Given that this feature has generated quite some interest I will give it higher priority. At the expense of syntax coloring/context-sensitive intellisense, for the initial stage. Something to play with, pretty dumb but illustrating the concept, just to get a feel.
On Tue, Apr 9, 2013 at 4:48 PM, Steven Taylor <[email protected]> wrote: > just want to point out that I'm Steven Taylor, not Stephen Taylor. I've > met Stephen once. He was the editor of Vector magazine in the UK... so, I > don't want to create any heat for Stephen. ;-) > > "APL character set actually *enhances* the unification of similar notions" > > I hope so. I remember a comment at an APL conference when an APLer said to > me, "it's just a matter of time before they [the J crowd] will be back to > using symbols." It's a surprisingly passionate debate. > > I'm curious to see what Greg cooks up. I am in VS most days, so I'm bound > to check it out. > > J coalesced for me after spending a lot of time reading and rereading the > vocabulary page. I still get little gems now and then from reading it. > > Do the lessons of html, css, js, jsv, json apply here? It's nice being > able to send an email with some code, and it'll just work. > > > > On 9 April 2013 19:09, Greg Borota <[email protected]> wrote: > > > Amen brother :-) > > > > > > On Tue, Apr 9, 2013 at 12:55 PM, Skip Cave <[email protected]> > > wrote: > > > > > Stephen, > > > > > > I agree that making libraries and argument conventions more accessible > > > would take a significant step toward smoothing the J learning curve. > > > However, there is just something elegant about Iverson's notation that > > > attracts people, eases the learning curve, and keeps diehard > programmers > > > using the APL language. Ideally we should do both with J. > > > > > > You mentioned your concern about the APL symbol set causing us to "shy > > away > > > from embracing the potential of unifying similar notions with > conventions > > > such as inverse, stop, colon" > > > > > > Actually. I believe that the APL character set actually *enhances* the > > > unification of similar notions. Look at APL's equal and not-equal, and > > > compare that to J's equivalent equal and not-equal (nub sieve) symbols. > > It > > > is much easier to see the relationship between the two APL symbols than > > the > > > J symbols. > > > > > > In J, how is Box (<) related to floor (<.)?. There are many cases in J > > > where stop and colon were added to an ASCII character to define a > > primitive > > > which had no relation to the single-character primitive. In every case, > > > similar APL symbols represent related functions. > > > > > > Wher APL characters really shine is in the ability to imply > functionality > > > from graphic cues. APL's take and drop (up and down arrows) are great > > > mnemonics for the functions, when compared to J's curly braces. Look at > > > APL's rotate and transpose, and compare them to the J equivalents. It > > would > > > be hard to improve on APL's simple, single-glyph symbols that better > > > represents these functions. > > > > > > APL's usage of traditional mathematical symbols when appropriate > > (multiply, > > > divide, greater-than-or-equal, less-than-or-equal) also ease the > > transition > > > from grade-school math notation to the single-glyph symbols. Most > > > programmers have long-forgotten their confusion when first presented > with > > > the asterisk as a multiplication symbol, but that is an issue for every > > new > > > programmer. > > > > > > Stephen Taylor said: > > > It's a worthwhile experiment, but it definitely sounds > > > like a fork in the road. Should we recognize this as such? > > > > > > I wouldn't call the ability to display J in a single-glyph form as a > > "fork > > > in the road". Rather it is an alternate way to display/write J code, > much > > > like changing the font in a Word document. Programmers can choose to > work > > > in either environment, and display their code in either form. It will > be > > > obvious to anyone, which form is being shown. If one wants to see the > > other > > > code form, just paste the code in the editor, and switch > representations. > > > > > > So we don't have to force anyone to choose their favorite > representation > > - > > > we just enable a choice. I suspect that most people will be able to > read > > > code in either representation fairly easily. > > > > > > Skip > > > > > > On Tue, Apr 9, 2013 at 11:00 AM, Steven Taylor <[email protected]> > > wrote: > > > > > > > I still think making the libraries + argument conventions more > > navigable > > > > would be a more productive and better received application of the VS > > IDE. > > > > > > > > I did enjoy seeing Mark Simpsons APL to J mappings. Visually things > > like > > > > square root and not made more sense. > > > > > > > > With this symbol variation approach I'd think that there'd be a > > tendency > > > to > > > > shy away from embracing the potential of unifying similar notions > with > > > > conventions such as inverse, stop, colon should people use a visual > APL > > > > type bridge to J. It's a worthwhile experiment, but it definitely > > sounds > > > > like a fork in the road. Should we recognise this as such? > > > > > > > > > > > -- > > > Skip Cave > > > Cave Consulting LLC > > > ---------------------------------------------------------------------- > > > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
