The sentence separator would be a J word, akin to a control word but
allowed in any sentence. Its internal type would be MARK, as that is
defined in the parsing table.
The above implies that the separator would NOT terminate a comment.
Henry Rich
On 7/27/2021 4:05 AM, Ian Clark wrote:
I'm warming to the idea of dotdot as a sentence-separator. Visual as well
as logical.
It would be an estimable anti-strabismus device for instructing newbies.
You could chain dotdot for emphasis:
foo=:3 :'(0 0 $ 1!:2&2)2 1$y;z=.(#~((+.)(1:|.(> </\)))@('' ''&~:))y
............z'
empty foo ' the quick brown fix ; '
as you can with right-bracket:
foo=:3 :'z[[[[[[[[[[ (0 0 $ 1!:2&2)2 1$y;z=.(#~((+.)(1:|.(> </\)))@(''
''&~:))y'
And for those preferring (>::) -- there's nothing stopping us having more
than one sentence-separator.
Would dotdot terminate a comment? Inline comments would be nice to have.
On Tue, 27 Jul 2021 at 03:04, 'Pascal Jasmin' via Programming <
[email protected]> wrote:
from my extensions at https://github.com/Pascal-J/jpp
I use cut on ` for "everything" replacing any native ` with named
conjunctions that build gerunds with a more complete spec.
as many of you know, you can build a multiline sentence with a a list of
boxed strings.
bb =: 1 : 'dltb each (''`''&cut) m'
'a =. x+y ` +: a' bb (4 : )
4 : 0
a =. x+y
+: a
)
in jpp, quotes aren't needed and extra builtins simplify function
creation. so above is created and called as
2 (a =. x+y ` +: a bb. 4.. ]3
10
between ... and >:: , I prefer ... for being easier to type, standing out
more, and the inherent nature that it is simply a cut mark.
On Monday, July 26, 2021, 09:19:04 p.m. EDT, Henry Rich <
[email protected]> wrote:
I don't see much downside to implementing a sentence delimiter, except
for a nagging feeling that the good Lord left that space for you to put
commentary in.
Take a moment to consider what is the best delimiter. I prefer >:: to
.. or ... because it shows the left-to-right order.
Henry Rich
On 7/26/2021 10:44 AM, 'Michael Day' via Programming wrote:
APL lives/d with the diamond separator, which works from left to
right, in addition to
left tack and right tack (in Dyalog anyway) which are similar to J's
[ and ] .
So this modification might help recruit any APL-ers still averse to or
unaware of J.
Cheers,
Mike
On 26/07/2021 14:47, Eric Iverson wrote:
Michal,
I slightly favor having a statement separator. Others are violently
opposed. You have started an interesting discussion that might take a
while
to pick up steam. Don't give up yet!
There are some complicating issues, such as debug.
On Mon, Jul 26, 2021 at 4:57 AM Michal Wallace
<[email protected]>
wrote:
Come on... :) Obviously I know how to write the code I wrote. :D
Yes, I can write the whole thing like this:
puts@']' fgc@9 puts 4 {. s=.1|.s [ fgc@15 puts@'[' goxy xy [ bgc 4 [
fgc 9
I'm just saying it looks backwards and awkward to me.
This thing draws a string on the screen that looks like [.oOo] in
various colors, and the .oOo part is extracted from a larger string
so it looks like a little indicator that the machine is still doing
something
or waiting for you to do something. (Or rather, this draws one frame
of the
animation)
If I were putting that string together without setting the colors and
moving the cursor, i'd write:
echo '[', (s=.1|.s), ']'
But with the color and cursor stuff, I seem to have to break it into
multiple lines, or write it backwards.
In this particular case, what I plan to do instead is write a little
language that lets me set colors
and move the cursor in the natural order, so it's not a big deal...
(Maybe
for J, i'll just make a
"left-to-right" verb that operates on gerunds or something...)
But... lately, I've also been working on some parser combinators, and a
small virtual machine.
In all these cases, I have bits and pieces of the code which are more
naturally expressed as
sequences of imperative operations, rather than function
compositions, and
I find myself
wanting this same statement separator.
I use K every day at work, and it uses the semicolon for this
purpose. I
often find myself wishing K
had forks, and J had statement separators. (and native dictionaries,
and a
literal syntax for symbols.. :))
Anyway, I noticed '..' was free now and it seems to have a nice
symmetry
with '{{' and '}}'
and I thought it might be a good notation for this.
I don't really expect this proposal to make it into the language
(for one
thing, it's not clear to me that
there's an actual process by which language decisions get made),
but... I
also didn't expect we'd
ever get anything like {{ and }} (which I've also wanted forever),
so I'm
asking.
On Sun, Jul 25, 2021 at 9:45 PM 'robert therriault' via Programming <
[email protected]> wrote:
Hi Michal,
In your first line you are already doing what I would do, which is
to use
[ to separate the different results.
goxy xy [ bgc 4 [ fgc 9
You can continue to do that as long as you get the order right and
lower
things vertically would precede the upper ones
fgc 15 [ puts '[' [ goxy xy [ bgc 4 [ fgc 9
or perhaps I am misunderstanding what you are trying to do.
Cheers, bob
On Jul 25, 2021, at 17:00, Michal Wallace <[email protected]>
wrote:
I love the new '{{' and '}}' ...
what are the chances we could bring '..' back as a statement
separator,
at
least inside these new double curly braces?
Often I have a bunch of really short lines that I would love to just
stick
on one line, like this demo code from the terminal library I'm
working
on:
while. -. keyp'' do.
goxy xy [ bgc 4 [ fgc 9
puts '['
fgc 15
puts 4{. s=.1|.s
fgc 9
puts']'
sleep 150
end.
I can easily stick these on one line with @ or [: but the code
winds up
feeling very backward, so I find myself just using newlines and
wasting a
lot of vertical space on my screen.
One answer here is to make a mini-language for terminal operations
that I
can just pass as a string, but there are other places where I find
myself
wishing I could just write a sequence of expressions (evaluated
right-to-left as usual) but all on one line, and sequence them from
left
to
right... (I use K at work, and this is a pretty natural style)
----------------------------------------------------------------------
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
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
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
