Andy Wingo writes:
> On Thu 23 Jun 2016 18:57, Mark H Weaver writes:
>
>> Andy Wingo writes:
>>> Or, we could use print states. But print states are not so great and
>>> ideally we would remove them eventually.
>>
>> We will need print states, or something like them, to support writing
>> cycl
On Thu 23 Jun 2016 18:57, Mark H Weaver writes:
> Andy Wingo writes:
>> Or, we could use print states. But print states are not so great and
>> ideally we would remove them eventually.
>
> We will need print states, or something like them, to support writing
> cyclic data structures as required
Andy Wingo writes:
> Or, we could use print states. But print states are not so great and
> ideally we would remove them eventually.
We will need print states, or something like them, to support writing
cyclic data structures as required by R7RS.
Mark
On Tue 21 Jun 2016 14:38, Zefram writes:
> Andy Wingo wrote:
>>Thoughts?
>
> How was this managed in Guile 1.8?
The printers and the backtrace handling was quite different, but it used
"print states".
> It seems that you need the truncated-print mechanism to be always
> available internally, bu
Andy Wingo wrote:
>Thoughts?
How was this managed in Guile 1.8?
It seems that you need the truncated-print mechanism to be always
available internally, but this doesn't require that it be always visible
to the user. You can still require the full libraries to be loaded for
the user to get access
Not really sure what to do here.
Ideally we could just use ~@y in the format messages. However we can't
rely on having a full format loaded up, only simple-format. We could
lazily load the full format when needed, but I don't know if we should
train users that the full `format' is always around.
