This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

display vs write (was: getting close to Kawa 1.12)


On 02/03/2012 06:08 AM, Helmut Eller wrote:
On Android printing a thread seems to hang, e.g.:
#|kawa:1|# (define x (java.lang.Thread:currentThread))
#|kawa:2|# (format "~a" x)

Prints nothing and just hangs; no error in the log. The same for display.
(write x) prints #<future Thread-15>.
Is this supposed to happen with the new lazy/promise stuff?

That is because: (1) the thread is started as a future; (2) a future is a Lazy value, (3) display of a Lazy value implicitly forces it; and (4) the repl by default uses display.

So we can fix/change one or more of these.

What I would do first is change (1) so the the repl code
creates a vanilla java.lang.Thread, rather than a future.
That fixes the immediate problem, and I think makes sense.

(2) is inherent in the concept of a future, so I don't
we can/should change it.

When it comes to (3), implicit forcing makes sense given
that display produces human-readable output.  If we have
implicit forcing (which I think has a number of benefits),
then I think display should do implicit forcing.

When it comes to (4), note that it is easy to override the
default:
$kawa --output-format readable-scheme
#|kawa:1|# "abc"
"abc"
#|kawa:2|# (delay (+ 4 5))
#<promise - not forced yet>
#|kawa:3|#

Should Kawa's repl by default use write rather than display?
After all, most Scheme implementations do.  The reason I'd
prefer not to do so is because of my 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: http://per.bothner.com/blog/2007/ReplPane/
* An HTML/XML obj can be insert into the output in visual
form if the console understands HTML.  (I have a prototype
of this based on the JavaFX webnode component I'm working on
in my Day Job.)
* My idea 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.

I think I'll add this to the FAQ.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]