[Version 2.1]

This directory contains a Grail-to-JVM compiler called gdf (Grail 
defunctionaliser).  The gdf program was written using Moscow ML
and Peter Bertelsen's sml-jvm toolkit.

The current grammar of Grail can be found in the file grammar.ps.

To compile a file test.gr, type "gdf test.gr"; if there are no errors
then a Java class file containing the class specified in the Grail
source should appear in the current directory.  

This version of gdf implements the new parameter-passing mechanism:
if a local function is declared as 
	fun f(int a, int b) 
then every call to f must also use the parameters a and b.  

All variables are local: if a variable name appears on the right-hand
side of some expression then the variable must either be one of the
function parameters or must have been declared (using val ...)
earlier in the function.  "Global" variables can be declared prior to
any function definition, but they (and also the method arguments) must
be explicitly passed as arguments to any function wishing to use them.
The type of a variable must be constant throughout a method
definition: if a function f declares "val x = 5" then any variable x
in any other function must also have type int.  These restrictions
apply to each method definition separately: different methods in the
same class may use the same variables for different types of data.
(Variable names are really just shorthand for JVM local variable
indices, and the parameter list of a function gives the set of free
variables used by the function.)

Note that as in Java,  Grail methods are instance methods by default. 
To declare a static method,  write "method public static int g() = ..."

The "examples" directory contains several example files which
should help to clarify the Grail syntax.  These usually consist
of a .gr file containing a Grail definition of a class,  and a 
corresponding Java test file which can be used to test the gdf
output.  The Grail files should be compiled before the Java files
so that the Java compiler can find the appropriate classes.



Gdf contains a few bugs and has plenty of scope for improvement:

* No typechecking is performed for method invocation yet.  This means
  that one can attempt to call a method with the wrong type of
  argument on the stack,  leading to verification errors at runtime.
  It should be possible to infer most of the type information in the
  method descriptor from the arguments, thus simplifying the unpleasant 
  syntax for invokevirtual and invokestatic; the same should be true 
  for the various field access operations.

* ... and so on

[FIXED:
* The "new" instruction is not implemented properly yet. A "new"
  instruction should also specify a constructor;  only the default 
  constructor is produced at the moment.  Also,  gdf does not yet 
  equip classes with a default constructor
]

[FIXED: 
* Gdf should presently only be used to compile one file at a time as the 
  local variable allocations are not reset properly after a compilation.
  This may also cause problems if a Grail class definition contains 
  more than one method.]

[MORE OR LESS FIXED: 
* At present all methods and fields produced by gdf 
  are static and public.  The compiler should eventually support all 
  of the standard Java modifiers.][Access modifiers and static/final are now 
  supported.  The 'abstract', 'native', 'strictfp', 'synchronized', 'transient' 
  and 'volatile' keywords are not available.  Who cares?]

[FIXED: 
* As the Bigfac example demonstrates,  the Grail syntax becomes
  difficult to read when there are large numbers of references
  to external java classes.  It might be useful to provide
  some sort of abbreviation mechanism to avoid this.]

[FIXED: 
* No typechecking is performed for comparisons etc yet.  It's 
  acceptable to write "5 is null" for example.] 

[FIXED DUE TO NEW PARAMETER-PASSING METHOD: 
* Function parameters  passed on the stack,  leading to
  large numbers of "load" and "store" operations.  The output
  code could be made much shorter by optimising the parameter-
  passing mechanism. ]

[FIXED DUE TO NEW PARAMETER-PASSING METHOD:
* Every identifier should be unique.  This means that a large number
  of local variables may be generated (one for each identifier).  It
  is hoped that a future version of gdf will allow re-use of identifiers
  within distinct functions. ]
