mjvesa / herd Goto Github PK

Some things require client side development. It would be nice to have the same language available on the client side. See if doing something like what is done in Spil is possible here.

The source directory for Herd sources is hardcoded in the Files class. It should be moved into herd.properties file as herd.source.directory or similar.

A good portion of the CORE wordset has already been implemented. The remaining words should be implemented.

As some things are done differently than in regular Forth (strings are a good example), F4V will however never be 100% compliant.

The editor component uses Ace, which already has thid-party syntax hilighting support for Forth. That should be enabled for a nicer experience when editing.

Herd should already have most of the requirements in place for showing the constituent words of any word, and also recompiling that word when modified. Such ability would make it possible to live-edit a running program for fixing and debugging purposes.

The heap is currently accessed directly in SQLWordSet. That should be refactored into a peek and poke method call instead.

There are plenty of warnings issued by eclipse or by FindBugs. All of those should be eliminated by fixing the underlying problem.

There are plenty of files missing. Upload those and make sure the project can be built and deployed.

ForthIDE still looks like it has been quickly hacked together. This appearance should be reduced by refactoring the whole class. Once refactored, all parts of the UI should be easily locatable in the source.

Add the .herd suffix to existing source files and handle it in the file view

All words (built-in and defined) should be visible somewhere in the UI. Built-in words could be grouped by their WordSet and the description string could also be shown at least as a tooltip.

Defined words could also use some kind of additional documentation system. For example the stack effect diagram could be shown if available. Also some system for
defining a documentation string for each definition would be nice. That string could then
be shown along with the other information on that word.

There is a description field for each built-in word. That should be filled with the stack effect of the word and a description of what the word does.

Port this thing to Vaadin 8 first using the legacy widgets, then move to the new ones. Table needs to be replaced with Grid and so on.

Previously MySQL was used for the database backend. This should be replaced with hsqldb. Additionally all the stuff from the SQL class should be moved into the SQL wordset.

A production mode needs to be added. In this mode the IDE will not be available,
and instead a file to execute is specified and only the main panel is shown.

There are some word sets currently that simply wrap Java APIs. Those could by implemented in Herd if there was a simple API for interoperation with JVM code. Something like:

"com.vaadin.ui.Label" new "I am caption" .setValue

Let's add an interop wordset and special handling for the period. Same scheme as with Java dot notation from JScheme should be used, as that is used in Clojure as well and seems to be very effective.

The Forth source files are currently called "blocks", which is not correct. They are normal files, and should be called such in code and in the UI.

Executing code and swithing between various views are good candidates for keyboard shortcuts. Reasonable shortcuts should be added for a quicker workflow.

The interpreter is currently in one large switch block. While this is the traditional way to implement Forth in a C-like language, it could be better to implement each word in its own class.

With an uniform interface for executing words it could be possible to compile defined words into series of method calls using the ASM tool.

The list of defined words should be sorted alphabetically.

The MovieBase example is a naive movie database. It used to work before the core was refactored and must be fixed.

As the JVM is a stack based VM, it may be possible to optimize things a bit by exploiting that. There are many limitations to fully using the JVM stack, but hopefully some gains in speed could be made.