[Jprogramming] Extended precision question

[Ed Gottsman]

Hauke,

My apologies: I expressed myself awkwardly.  No disrespect was meant to any editor.  :-).  Emacs and vim would be my choices, too, were I feeling a lot more ambitious.

I have the sense that there are two basic approaches under discussion.  In the first (the one I think you’re articulating), the editor would change but could (in principle) feed “vanilla” J to the interpreter/debugger.  That is, the .ijsx file format could be invisible to the J runtime. 

In the second (which is what I think I’m hearing from Raul), the interpreter/debugger would be opened up and enhanced to deal with the ijsx format (which would live in .ijs files).

An adjunct to the first approach might be a simple front-end translator that the (otherwise unchanged) J runtime could invoke to translate .ijsx to .ijs on load.  That would let J deal directly with the enhanced format but would not require opening up the interpreter/debugger.

The first approach strikes me as an easier lift with many of the benefits, but my ignorance in all of this is nearly perfect. 

Ed

Sent from my iPad

> On Apr 28, 2022, at 10:24 AM, Hauke Rehr <hauke.rehr at uni-jena.de> wrote:
> 
> Smarter than emacs? Vim. :)
> editor wars aside, I’m having a hard time
> imagining any editor smarter than these two
> 
> They may call themselves “smarter” but mostly
> that translates to “more cumbersome”.
> 
> folds are natural in any coding editor,
> and I guess Tim Pope would come up with a solution
> showing the comment associated with the token under
> the cursor (if any) in no time; maybe I’ll try and
> write some addition to the J file type plugin even
> though I’m far from expert at vimscript –
> /if/ this syntax should ever be supported.
> 
>> Am 28.04.22 um 09:56 schrieb Ed Gottsman:
>> Jan-Pieter,
>> I like that file format a lot.  Like JSON, it’s human- and machine-readable.  Further, a “slightly smart” editor (here I’m thinking perhaps of emacs macros) could toggle between it (one token per line with comments) and a conventional view (all tokens on one line, no comments).  A much smarter editor might have other, more sophisticated display/edit formats that would show both tokens and comments.
>> Ed
>> Sent from my iPad
>>>> On Apr 28, 2022, at 8:49 AM, Jan-Pieter Jacobs <janpieter.jacobs at gmail.com> wrote:
>>> 
>>> I actually was intending for quite a while to propose an extension to
>>> comments along the lines of the suggestions in this thread:
>>> to use ... as line continuation indicator that turns everything after it up
>>> to and including the next line break to be considered comment, and still
>>> considers the line to continue (Matlab does this the same, IIRC). It could
>>> be thought of as a non-line-breaking version of NB. .
>>> 
>>> For instance (silly example):
>>> 
>>> avg =: ... averag operator
>>> +/ ... sum
>>> % ... divided by
>>> # ... length
>>> 
>>> Now, it's certainly overkill for this tiny example, but I think it could be
>>> valuable for longer trains.
>>> 
>>> Advantages of ... :
>>> - not in use at the moment
>>> - clear meaning (i.e. more code to follow)
>>> - fits in with J word formation rules
>>> - easy for communication to non-J experts
>>> - length the same as NB.
>>> 
>>> Jan-Pieter
>>> 
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
> 
> -- 
> ----------------------
> mail written using NEO
> neo-layout.org
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm