Non-deterministic J

What makes a J script non-deterministic? Answering this question would allow us to:

• Make the perfect J syntax highlighter

• Make the perfect J-code "shootout" rules.

• Make a safe, sandboxed execution environment for J code that isn't fully trusted (e.g. for scripts that accept user-supplied data), analogous to Perl's "taint". This is required to implement a decent J CGI interface.

events

Try to make a comprehensive enumeration of asynchronous events in J:

Definitely asynchronous:

• wd events

• Sockets events via socket_handler

• Timer events via sys_timer (this is wd-dependent but requires no forms)

• DLL callbacks via cdcallback

• Theoretically, anything that could return the session to immex and trigger the 9!:26'' sentence (e.g. break file handling).

Potentially (but probably not) asynchronous:

• Mapped files: Certainly a mapped name in a J session can change whilst the session is idle (not running any sentences), if another process modifies the underlying file. But is J asynchronously informed of this change? That is, could a user application detect that NAME at time N is different from NAME at time N+k without polling?

• Spawned processes à la load 'task': I don't J can spawn processes asynchronously (that is, it can either spawn a process and detach from it, thereby losing its output, or it can spawn a process and wait for its output, in which case the J session won't be idle).

• Windows-specific:
  • DDE: I think this is dependent on the IDE or a hidden form.
• POSIX-specific:
  • SIGnals: E.G. SIGUP. Are user applications informed of these?
  • (Named) pipes: I don't even know if J supports these.

There may be others I haven't I haven't enumerated.

arbitrary execution

Try to make a comprehensive list of sentences with a fixed, finite number of tokens which can result in the execution of arbitrary J code? (ignoring host interaction such as file reads).

The fundamental example is ". 'S' where S is J code (of arbitrary length). Consider also ". I{a. where I is a list of integers instead of characters, but again is treated as an indivisible token.

host interaction

In a perfect world, what would 9!:24[1 enforce?

Try to make a comprehensive list of effects J can have on "the outside world" (i.e. things not specified by the Dictionary). That is, what would we have to forbid to guarantee that a J script is idempotent? That it is in a tightly controlled "sandbox"?

syntax highlighting

Finally, we want to make a list of "suspect code". Suspect code is code which is non-deterministic to a static syntax analyzer (i.e. a context-free grammar). Think of things that would give a syntax highlighter trouble. For example:

   'name another'=.y
   '`name another'=.y
   another =. 'name'~
   another =. 'name' f.

What about "gerundy" operations, like ^:? They can executed arbitrary verbs which are encapsulated in finite nouns .. try to exploit this.

Consideration should also be given to the "keyword programming problem". That is, if we wanted to replace J primitives by their named "equivalents", how would we do it? Consider the example avg =. sum/ % #; should this be replaced with avg =. sum over quotient tally or avg =. plus table quotient copy? We cannot know until we know the invocation context of avg (if it's used monadically then it's the former; if dyadically, then the latter; if ambivalently, then neither; we'd have to say avg =. plus over quotient hash or somesuch.

shootout rules

Definition of tokens should be:

Token count :: Number of J words (#@;:), plus (scaled) number of atoms in specified (not computed) nouns.

Golf rules:

• Your results must be guaranteed by the DoJ
• Your expression must not assumptions about the state of the world. That is, the expression must be completely functional.
  • You may not depend on any names normally defined in the standard library.

  • You may not depend on the host system (2!:0 or 11!:0 or 15!:0).

  • You may not assume you're on Windows or Linux or Mac.

  • You may not assume you know where you are in the file system (the results of 1!:43'').

Make this a JAL package, with a "enforcer script" and sub-scripts for each shootout. That way users could create and test their contributions. When they're happy, they could press "submit", the Wiki would be updated, and a message would be sent to the Forum in their name (or maybe we subscribe the Forum to the RSS feeds for all Shootout/ subpages). A standard, centralized server should be used as the final authority for efficiency calibration.

Users should be able to contribute their own "shootouts" and new "corner case" test data for pre-existing shootouts. Not only time, token count, elegance, etc, should be measured, but also time of submission (in the format T+time, where T means time the shootout was posted). Each shootout should be able to completely customize its metrics (but not retroactively). It should, by default, import the constraints and metrics laid out on this page.

other discussion

Try to make a list of everywhere this has been discussed (on the Wiki, the Fora, comp.lang.apl, Vector articles, etc) and compile their ideas:

• "Sierpinski triangle" thread on JProgramming

mullings

J accumulates state, and this state effects execution. See State in J. Of course, the host system has state too, and that can and most likely will effect execution. For example, 6!:0'' will never return the same value, and there is no guarantee on the output of 1!:1<'filename.ext'. Maybe some research into Monads in the Haskell sense of the word (state encapsulation).

Setting, query, J interpreter, host system.

The phrase for_name. creates a name, but like name=. and 'name'=. it is identifiable statically. Not so with )=. or )=:.