It's hard to understand what could possibly remain to explain. Well,
lets see if something more happens in the discussion. I'll give up on
the second and third question. /Erling
On 2017-09-27 16:23, Henry Rich wrote:
I am sorry, but I have not been able to make sense of the last several
messages. JWithATwist is outside my area of interest. If you can
describe this idea fairly precisely, and explain why it should be
implemented, I will try to understand it.
To me, yes, what you can do with a language is the only thing that
counts.
Henry Rich
On 9/27/2017 10:13 AM, Erling Hellenäs wrote:
So it would be relevant to discuss this request in terms of
programmer productivity?
Any opinions? /Erling?
On 2017-09-27 16:01, Don Guinn wrote:
If you want the most powerful programming language it has to be
assembly.
It can do everything that every other programming language can do
and so
much more. But what is the purpose of languages like J and C++? They
are to
make people more productive, not computers.
On Sep 27, 2017 7:34 AM, "Erling Hellenäs"
<[email protected]> wrote:
Hi all !
See comments below.
There are still two unanswered questions. You are not required to
answer
them, of course.
Cheers,
Erling Hellenäs
On 2017-09-27 13:36, Henry Rich wrote:
The syntax is that of explicit J but missing some things, like control
words and assignment, and perhaps the ability to write multiline
expressions. If it produces tacit J, it's also not going to be
able to
define modifiers.
I don't know what question this answers. JWithATwist handles modifiers
during interpretation, in the same way I think tacit J does. To set
them at
runtime you might have to use the same tricks as normal tacit J. Yes, I
imagine the tacit-v expressions to have the same functionality as
normal
tacit J. No control words and no assignment.
I just don't see that having a new way to write tacit verbs is a change
worth making, if it doesn't allow something that the old way didn't.
And what you can do with a language is the only thing that counts?
C++ is a
million times better than J?
To discuss other arguments for and against the different notations
would be
of no use?
Henry Rich
On 9/27/2017 6:25 AM, Erling Hellenäs wrote:
Hi all !
See comments below.
Henry, you answered one of three questions.
Cheers,
Erling
On 2017-09-27 11:09, Henry Rich wrote:
I have trouble contributing to this because I don't understand your
proposal as written. One thing I don't understand is why you
call your new
verbs 'tacit'. It appeared to me that they used ] and [ as tokens
indicating the input arguments. That would make them explicit,
by the
definition of that word.
We can call them something different, I just choose tacit-v
expressions
for the purpose of my request.
They are very similar to tacit expressions. They have exactly the
same
functionality, just different syntax, and that syntax is the
syntax of
explicit J.
The tacit language shows up inside lines of code. When you write
sortedbycol1 =: (/: 1&{"1) array
there a little tacit code there. We wouldn't want to lose that.
The tacit-v expression would be
sortedbycol1 =: (: ] /: 1 {"1 ] ):
if we choose the (: ): brackets. The brackets are needed here as
long as
present tacit J is the default.
The tacit-t version can be written like this.
sortedbycol1 =: /: 1&{"1
Brackets are automatically added, creating the hook. If we directly
compare the notation,
] /: 1 {"1 ] is equivalent to
( /: 1&{"1 )@] if we write code that can be moved between a
monadic and
dyadic context without rewrite.
However, as I said, the easiest implementation probably is to
continue
allowing the present tacit expressions in tacit-v expressions.
In the long run you would probably not want both ways to express
exactly
the same thing, you would want to let the new tacit-v expressions
replace
the present tacit expressions as I see it. There is a question
about how it
could be done. One way is to not allow them in tacit-v expressions
from the
beginning, as I propose, but there are other ways. To block them
from the
beginning would make the first implementation much harder.
sortedbycol1 =: (/: 1&{"1)
sortedbycol1 i. _3 4
0 1 2 3
4 5 6 7
8 9 10 11
All the uninflected delimiters are taken, and {. }. and {: }: and
<. >.
and <: >:; but (. ). and (: ): are available.
It seems out of the question to redefine any of { } [ ] as they are
used in so much existing J code.
Henry Rich
On 9/27/2017 4:33 AM, Erling Hellenäs wrote:
Hi all!
It seems like fast function definitions is only for creating
explicit J
verbs, adverbs and conjunctions?
This means it is only vaguely related to my proposal of tacit verbs
with explicit J syntax?
Maybe the fast function definition discussion should therefore have
it's own thread?
Let's say we wanted to implement tacit-v verbs.
-Is there a construct like { ... } or (. ... ). that could
possibly be
used for a new kind of bracket notation?
-Would x and y or [ and ] be suitable as symbols of the left and
right
arguments? If so, which of them ? If not, what would be a suitable
representation of the left and right argument ?
-Could the interpreter be easily modified to allow the explicit J
syntax in this new bracket construct, or would it be difficult or
impossible to achieve?
In the JWithATwist interpreter the difference between how
brackets with
explicit J code are handled and how tacit-v brackets are handled
is about
four lines of code. It think this indicates that this might not
be such a
revolutionary change in terms of actual code changes.
Cheers,
Erling
On 2017-09-26 22:34, Henry Rich wrote:
Good point, colorization. I never thought about that.
The big difference between Fast Functions and 3 : functions is
that
Fast Functions are recognized when a script is loaded, instead
of when the
3 : is executed. It is the fact that 3 : is executed like any
other
conjunction that prevents nesting of multiline verbs: the
nested verb can't
be defined until it is executed, and by then its definition is
long gone.
The innermost (. ). is analyzed and replaced by (m : string). The
process continues for all nesting levels. This completes the
prepass.
The generated verbs - (m : string) forms - are handled as they are
now, when the : is executed. That means nested verbs are not
processed
until they are encountered during execution.
Linear representation is used to make the (3 : string) form
atomic.
Yes, you would need to balance (. .
Henry Rich
On 9/26/2017 4:02 PM, Raul Miller wrote:
Prepass means essentially that this happens after word
formation but
before parsing. That does eliminate some problems, but creates
new
ones. It also suggests that you would be supporting explicit
control
words. But it also means that you need to put a lot more
thought into
how these would be represented (and stored) - there's no inherent
point to using linear representation to "unparse" here.
(Do inner (. ). definitions get reparsed every time the outer
expression gets evaluated? That might be the simplest
approach, but
does require significant changes in explicit handling.)
Multiline means that you get into behavior somewhat like you
get when
m :0 appears on a line. But getting out of that might be more
complicated than it is now (because you might not know if you
need ).
or a sequence of them or ) to end it - for example after pasting
something big into your session).
The complexities introduced by multi-line probably means that
interactive environments would want to colorize (. ). definitions
(especially incomplete definitions while being entered) based
on the
presence/absence of mnuvxy seen so far (probably not the
current line
though).
Thanks,
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
