Re: RFC: (ice-9 sandbox)

[Ludovic Courtès]

Hi!

Andy Wingo <address@hidden> skribis:

> On Mon 03 Apr 2017 17:35, address@hidden (Ludovic Courtès) writes:
>
>> Riastradh’s document at <http://mumble.net/~campbell/scheme/style.txt>
>> has this:
>>
>>   Affix asterisks to the beginning and end of a globally mutable
>>   variable.  This allows the reader of the program to recognize very
>>   easily that it is badly written!
>>
>> … but it doesn’t say anything about constants nor about %.
>>
>> It could be ‘all-pure-bindings’, or ‘*all-pure-bindings*’, or
>> ‘%all-pure-bindings’.  So, dunno, as you see fit!
>
> I feel like I would have less of a need for name sigils like *earmuffs*
> or %preficentiles if we had more reliably immutable data.

[...]

> However we it is possible to do a more expensive check to see if a pair
> is embedded in an ELF image (or the converse, that it is allocated on
> the GC heap).  I just looked in Guile and there are only a few dozen
> instances of set-car! in Guile's source and a bit more of set-cdr!, so
> it's conceivable to think of this being a check that we can make.
>
> If we are able to do this, we can avoid the whole discussion about
> SIGSEGV handlers.
>
> It would be nice of course to be able to cons an immutable pair on the
> heap -- so a simple GC_is_heap_ptr(x) check wouldn't suffice to prove
> immutability.  Not sure quite what the right solution would be there.
>
> FWIW, Racket uses four words for pairs: the type tag, the hash code, and
> the two fields.  Four words is I think the logical progression after 2
> given GC's object size granularity.  It would be nice to avoid having
> the extra words, but if we ever switched to a moving GC we would need
> space for a hash code I think.
>
> Thoughts on the plan for immutable literals?

My feeling is that using GC_is_heap_ptr or similar would be nicer than
adding bits to the type tags, because we’d need to add this read-only
bit for every type, and we could have bugs where we forget to check them
in some cases.

GC_is_heap_ptr is probably enough until we support immutable objects
allocated on the heap.

> Concretely for this use case, assuming that we can solve the immutable
> literal problem, I propose to remove sigils entirely.  Thoughts welcome
> here.

In practice I guess the funny characters will stay for a while.  :-)

But I agree that it’d be nice to have a generic way to represent
immutable objects.

Ludo’.