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
.