Hi! Andy Wingo <wi...@pobox.com> skribis:
> On Mon 03 Apr 2017 17:35, l...@gnu.org (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’.
