Status of my Joy implementation, ideas for uses of Joy, etc.

cpcogan — 2007-01-06 19:45:21

Hi.



Before I get to my main topics, I'd like to suggest some ideas for

thread topics (some of which may already have been used, but I haven't

yet gone over all the posts I've missed):



    1. Joy and genetic programming (why it's such a good tool 

    for this, etc.). 

    

    2. Joy as a computer-aided-instruction language (an 

    alternative to Pilot, for example).

    

    3. Joy as a model for a formal system notation (symbolic 

    logic, etc.)

    

    4. Joy as a basis for a complete system of mathematical 

    Notation (like APL, Mathematica, etc.).

    

    5. Joy as basis for the engine in a Mathematica-like package.

    

    6. Joy as the basis for the engine in a general-purpose data-

    manipulation tool (allowing the user to perform operations 

    for whatever he could write Joy code for or find a plug-in 

    for, like an APL or Mathematica environment, but far more 

    general).

    

    7. Joy as the basis for a handwriting-recognition system 

    evolved by genetic programming (my ideas on this in a 

    future post, I hope).

    

    8. Joy as a keystroke macro program (see below).

    

    9. Joy as a macro language for other applications (i.e., a 

    macro language in IDE's, etc.) (see below).

    

   10. Joy as a scripting language (for enabling a program to 

    interact with remote applications)(see below).

   



I have some thoughts (mostly half-baked -- or not even in the oven

yet) on these topics, but I admit I may never get around to posting

anything on them. I talk a little about some of them below, but I'm

sure there is much more to be said that others may be better qualified

than I to say (I haven't even actually written any significant code in

Joy much above the level of the required "Hello world" program, so I'm

definitely not the best person to talk about the actual Joy code for

anything).



==========================================



It's been over two years since I last posted. I haven't been keeping

up, either, sad to say, though I have taken a look a couple of times

to see what was going on. I've started two or three other messages

that I never finished. One showed how using local variables could

simplify the qroots code (and make it more readable, as well), which I

hope I still have on my computer at work (it doesn't seem to be on my

flash drive or my machine at home). I may finish and send it if

reading the posts on the quadratic question leads me to think that I

have anything to contribute. I have some other ideas about

representing mathematical formulas, but, again, I should go over what

has been posted about the qroots issue before I take up space with my

thoughts on this.



My implementation of Joy has over 200 "primitives." It uses a

"compiler" that creates what might be called "object threaded code" in

which each item in the thread is a Joy language code element object.

At execution-time, each element has a "delegate" (a fancied-up,

type-safe pointer) that is executed (actually, the function it points

to is executed), even if the code element is really just a string or

number. This produces a slow but uniform way of doing things (so that

the "interpreter" merely takes each code element and executes the

delegate, basically, and doesn't have to know anything about it).

Continuations are used (actually, the "compiled" code for each

function is copied onto a continuations stack, each with its own index

so it knows where to resume execution when a called function returns).

Copying is done so the code can be manipulated without changing the

dictionary entry, though I may change this so the code has to

explicitly copy any code it wants to manipulate. 



Using my "object threaded code" approach also allows me to completely

reconstruct the executable portion of the source for any function

(without comments and original formatting). I used this latter feature

in the IDE to display a tree-structured representation of the code any

non-primitive function in the dictionary, and it means that the code

can be edited by other code even after it is "compiled" (for example,

I could have code that searches for a given stretch of code and then

replace it with another, even at run time, if I want). (In the tree

view, the user can collapse or expand parts of the tree, or view the

code for any function call (in a popup box that follows the mouse

cursor) just by moving the mouse over the corresponding node.) 



I haven't actually used my implementation, except for basic testing (I

fed a bunch of the library stuff into it and tried a few functions,

etc.), so I'm sure there are many bugs still in it. At some point I

may convert it to C# or C++, but right now it's in Visual Basic (not

my favorite conventional programming language, but I got into using it

a work years ago because Basic was all I had access to), so I'm more

or less stuck with it -- and, for a regular programming language,

Visual Basic .NET is not too bad, and it has pretty much all the

features of the other languages, but in a less-concise form (for

example, ends of constructs are indicated with "End If," "End While,"

"Next," etc., instead of just the curly brackets of the C-derived

languages, which actually improves readability but not coding)).



I started this message to say that I'm successfully using Joy as a

macro language within a larger application (still being developed). I

wrote the entire Joy "engine" so it can be created as an object and

then accessed as needed, in several ways (each such instance can have

its own set of dictionaries and sub-dictionaries).



To enable the application to use the Joy engine, I wrote a bunch of

new application-specific "primitives" that are added to the Joy

dictionary at run time, by the application (using calls of the Joy

object's methods to do this, so the app doesn't have to know anything

about the Joy processor's innards). They can use other Joy primitives

or do their own thing, as needed. Right now, nearly all of them are

wrappers for application functions, written to make them parameterless

(in Visual Basic .NET terms, not Joy terms).



The application loads a table of scripts (which are currently Joy

source code without comments). When the user clicks a command button,

a small command processor retrieves the script for that command and

then passes it to Joy for execution. Here's a simple example (I don't

have any complex ones so far, but about a hundred simple ones):



        [ "UDA" "Enter Last Name" "UDA Last name for UDA" "Last Name:"

PROMPT ] Ocmd



"UDA" is the name of a command in a mainframe application. The UDA

command takes a person's last name as a parameter, so, when the

content of the list is executed (by Ocmd at the end of the script), it

prompts the user for the person's last name, and then puts the name on

the stack.



When Ocmd is executed, it picks up all the parameters from the stack

down to a marker (automatically put on the stack prior to executing

the script), builds a command string which it then sends to a

mainframe front-end program called Extra! (the annoying exclamation

mark is actually part of its name), along with a carriage-return (to

tell the mainframe application to take what's been sent to it and

execute the corresponding command.



I think Joy is almost ideal for such scripting and for use as a macro

language (like those built into many programmers' editors and even

word processors like Word). The application-specific interfacing is

fairly easy, and the actual execution engine is so small that it need

not cause the app to be too bulky (as it probably would if you tried

to use many other languages of equal power, because of the high

overhead of processing source in nearly all languages except for

non-mainstream languages like Joy and Forth). 



Another of the many things I've considered but have not yet done is

using Joy as a keystroke macro program, either within an app, or as a

general utility (functionally similar to Perfect Keyboard or other

such programs). Because of its strongly sequential nature, it should

be pretty easy to use it this way, I think. Because of its small

compiler/interpreter size, it would not be too large. The only

disadvantage that I've encountered is that strings in Joy are in

quotes, but in most keystroke macro programs, it's the language

constructs and non-string data that are somehow "quoted" (Perfect

Keyboard uses angle brackets, as in: <down>, for the down-arrow key,

and: <wx>(100), to tell the macro processor to pause for 100

milliseconds). However, using normal Joy conventions might actually be

an advantage in cases where there is a lot of Joy code and only a few

strings. Keystroke macro programs typically try to make strings the

default, but, since this is done at the expense of making the language

components annoying to use, it means that they discourage

more-sophisticated uses of such languages that might otherwise be made. 



The work I do involves many forms, and I haven't yet developed an

interface for working with forms, but it doesn't seem especially hard

to do, except that I don't like the idea of writing bazillions of

little interface wrappers for the methods and properties of Visual

Studio forms (and their "controls," as Microsoft calls text boxes,

buttons, and the like that appear on forms), so I'm hoping to be able

to make a single general-purpose interface to such objects and use it

without having to write code for each individual item (and, for

complex forms, there can be many hundreds of things one might want to

have access to).



--Chris (Cogan, that is)