> ... why not define them as functions/verbs
> [if] a noun is brought in where a verb is needed then maybe
> the rank operator could be implied to do a conversion.
Wow. That did not occur to me. That's thinking out of the box.
I want to write up a longer response, but I am preparing for a trip. For now,
let me rephrase your suggestion as I understand it, for others to comment:
1. The primitives [. and ]. would be verbs.
2. They would be supported by special train syntax
(i.e. in section F), such that:
if ]. appears in a train, the result is a
conjunction; otherwise, if [. appears in a
train, but ]. doesn't, the result is an
adverb; otherwise the current train rules
apply.
3. The primitives refer to the argument(s) of their
longest enclosing operator (in a manner similar
to $: which refers to the longest enclosing
verb).
4. This "longest enclosing" rule makes these
primitives more useful in nested trains
(where they'd otherwise refer to the verbs outside
their immediate nest).
5. If the argument(s) to the longest enclosing
operator is/are nouns, rather than verbs, then
[. ]. refer to m"_ n"_ respectively.
6. We could make this latter rule terser by always
defining [.=.u"_ and ].=.v"_ , which would have
the same effect on noun arguments and no effect on
verb arguments. However, it would have an effect
on verbs derived from verb arguments (e.g. {...@[.
would be different if [. were +."_ rather
than plain +. ).
Note that these rules are aimed at making defining verb-deriving tacit
operators easier -- deriving other parts of speech would be convoluted (or
impossible -- I haven't thought deeply about this).
For example, today:
conj =. 2 : 'u + v'
2 conj 3 NB. Derives a noun
5
compare that with the "equivalent" conjunction defined tacitly using the tools
outlined above:
conj =. [. + ].
2 conj 3 NB. Derives a noun
2"_ + 3"_
This is in the spirit of tacit J, which aims to make deriving verbs (the most
common use case) easy, sometimes at the expense of other use cases.
Again, I haven't thought about this deeply; this is just my rephrasing of your
suggestion. I haven't worked through many examples of the new syntax. There
may be serious drawbacks I haven't considered. It may not even be backwards
compatible.
But I'd be interested in what other Jers have to say (besides that it's
unlikely to ever be implemented).
-Dan
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
