If you don't mind some limitations, that:
(*) the ... token can only be used in explicit definitions
(*) the ... token must be preceded by a space
(*) the resulting definitions do not actually contain the ... delimited coments
(*) these definitions must use a lone ')' as the closing delimiter, and so
(*) these definitions cannot be nested
You can implement support for it in current versions of J9.
Actually, we could allow any token as the ... token (but tokens which
begin with : or . must be preceded by a space):
defn=: {{
body=. ;<@(m (i.{.[)&.;:~ ]);.2(0 :0)
0!:0'u=.{{',LF,body,LF,'}}'
u
}}
Example:
avg=: '...' defn
( ... average operation
+/ ... sum
% ... divided by
# ... length
) y
)
Example of example:
avg 2 3 5
3.33333
FYI,
--
Raul
On Thu, Apr 28, 2022 at 5:57 AM Ed Gottsman <edward.j.gotts...@gmail.com> wrote:
>
> 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.r...@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.jac...@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
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
