Re: display vs write

[Helmut Eller <eller dot helmut at gmail dot com>]

* Per Bothner [2012-02-03 20:10] writes:

> 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|#

Ah yes. I was using that for ages but forgot to set it on Android.

> 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.)

Those don't seem particularly feasible/useful on a text terminal.

> * 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.

Well, I find it confusing/annoying when it turns out that (a b c) is not
a list with three symbols but a list with strings ("a" "b" "c").

Regular shells also have job control commands.  A shell without job
control that doesn't let me background/stop/kill processes is very
annoying.

Helmut