Raul wrote:
> For example, should we allow J to assign definitions to APL
> tokens (using =:)?
The question of what to permit as "assignable" codepoints is still open.
But, at first blush, I don't see why not.
Raul wrote:
> If so, does what does this mean for APL's
> assignment arrow, and quad?
I don't see what J has to do with APL's symbols, or why we should consider
them differently from, say, musical notes.
Raul wrote:
> If not, what kind of burden
> does this put on our J implementation team?
If you're asking whether the fact that these symbols are assignable should
imply they have the same definitions in APL, then no. I doubt that's what
you (Raul, in particular) are asking, but cannot find another way to
interpret the question.
J is not APL, for broader reasons than symbol set. Permitting Unicode
identifiers will effect Part I of the dictionary (Alphabet & Words) but
not Part II (Grammer; in particular Section E, the parse table) [1].
Today, is =: =: is illegal; analogously, in the hypothetical
J-with-Unicode-identifiers, {apl-arrow} =: =: would be illegal. The
reason is the same in both cases: the spelling of the identifier is not
problematic, the part of speech of the referent is.
Put another way, just because you can't say {apl-arrow} =: =: doesn't
mean you shouldn't be able to say {apl-arrow} =: @: . In fact,
expressions like idxWhere =: I. <- E. might have mnemonic value
("the results of E. feed into I.", "the data flows left"). Of course
then you wonder if I.<-E. would be optimized like I.@:E. is; but that
issue is not introduced by Unicode identifiers. Consider of =: @: .
Similarly, I don't see why we shouldn't permit {apl-quad} as an assignable
name. In fact, a J user who came from APL might find [] <-
(request_user_input @: print_verb_input) a familiar definition. But he'd
be responsible for writing it.
Don Guinn wrote:
> And if UTF characters were opened up for names would this
> prevent the use of those characters as primitives at some
> future date?
This is the strongest argument against Unicode identifiers I've seen so far
(well; 3rd place. 2nd the current (non-)transparency of Unicode use and
1st is it's not a priority for Roger. The latter two are probably
related.)
Even so, I don't imagine it represents such a hurdle. If J introduces
primitives using codepoints you'd previously included in identifiers, it's
not such a hard task to find and replace them.
Raul wrote:
> Perl6 is, in essence, a language for writing parsers, and may never
> be completed. Do you really think this would be a good model for J?
I don't believe the "is" of Perl6 has gelled yet. Specifically because it
may never be completed.
Raul wrote:
> If you want to write something like this, I would be willing to give
> it a try.
It's on the to-do list. About halfway down. FYI, even the items at the
top are yellowed with age.
-Dan
[1] And while permitting Unicode identifiers may eventually effect the
Vocabulary, by increasing our range of succinct names for primitives, and
letting us explore possible definitions for those names, this is a
side-effect, not a neccesary consequence.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
