To provide a short name for a class instead of the complete fully-qualified
name use either define-alias (or define-private-alias)
or the import-class combination.
For example, to be able to write ArrayList instead
of java.util.ArrayList do either:
(import (class java.util ArrayList))
or
(define-alias ArrayList java.util.ArrayList)
Using import is recommended:
It handles errors better,
and it allows you to define multiple aliases conveniently:
(import (class java.util Map HashMap))
Both forms allow renaming. For example if you want to refer
to java.lang.StringBuilder as StrBuf do:
(import (class java.lang (StringBuilder StrBuf)))
or:
(define-alias StrBuf java.lang.StringBuilder)
The name(s) defined by import are by default private.
A name defined using define-alias is by default exported;
to avoid that use define-private-alias instead.
You can also use define-namespace to introduce an abbreviation or
renaming of a class name, but as a matter of style define-alias
is preferred.
There is no direct equivalent to Java’s import PackageOrTypeName.*
(type-import-on-demand) declaration, but you can alias a package:
(define-alias jutil java.util) (define mylist :: jutil:List (jutil:ArrayList))
To import a static member, giving it a shortened name
(like Java’s static-import-on-demand declaration), you can use
define-alias. For example:
(define-alias console java.lang.System:console)
For static fields only (not methods or member classes) you can
use an import form, either:
(import (only (java lang System) out))
or:
(import (only java.lang.System out))
This works because Kawa can treat any class as a “library”; in which case it considers all public static fields as exported bindings.
Consider the Java SE member class javax.swing.text.AbstractDocument.Content.
Using the Java syntax doesn’t work in Kawa.
Inside you should use Kawa’s colon operator:
javax.swing.text.AbstractDocument:Content
Alternatively, you can use the internal JVM class name:
javax.swing.text.AbstractDocument$Content
The read-eval-print-loop of most Scheme implementations prints the
evaluation result using write, while Kawa uses display by default.
First note that it is easy to override the default with the
--output-format command-line option:
$kawa --output-format readable-scheme #|kawa:1|# "abc" "abc"
The reason display is the default is because of a vision of the REPL
console as more than just printing out Scheme objects in
textual form for use by a programmer.
Some examples:
A math program can display equations and graphs as the output of an expression.
An expression can evaluate to a "picture" which would be displayed inline.
An HTML/XML obj can be insert into the output in visual form if the console understands HTML. (There is a prototype for this that works by using the JavaFX WebView as the display.)
The plan for "Kawa-shell" functionality is to have expressions that evaluate to process objects, which would be lazy strings. This string would be the data from standard output. Thus the effect of displaying a process object would be to print out the standard output - just like a regular shell. Users would find it confusing/annoying if shell output used quotes.
This "repl-as-pad" model doesn’t work as well if the repl
uses write rather than display.