search

bloom-lang / bud

Prototype Bud runtime (Bloom Under Development)
http://bloom-lang.net
Other
854 stars 60 forks source link

Consider freezing values in tuples #272

Open neilconway opened 12 years ago

neilconway commented 12 years ago

Mutating values that are referenced by tuples can lead to all sorts of problems (e.g., the state of the database can be inconsistent with the key constraints; derivations can exist that don't have ground, and vice versa). This is particularly relevant because strings in Ruby are mutable.

A possible way to address this would be to invoke #freeze on values before allowing them to be stored into Bud collections.

sriram-srinivasan commented 12 years ago

Do we do this in the current sandbox and examples?

neilconway commented 12 years ago

If you mean "does the sandbox/example code mutate values that are referenced by tuples stored in Bud collections?" -- I'm not sure. It is unlikely you'd want to do it intentionally, but we don't disallow it or detect such a situation.

sriram-srinivasan commented 12 years ago

If you mean "does the sandbox/example code mutate values that are referenced by tuples stored in Bud collections?" -- I'm not sure.

Yes. This is a problem for all aliasable refs in general in any language, but I was wondering if you had encountered it in some existing code. Also, good to know about freeze.

neilconway commented 12 years ago

It might also have a perf difference: when you stash a mutable value as a hash key, the builtin Ruby hash makes a copy (and then freezes the copy). We might do asymptotically fewer copies if we did a single freeze of all values when they enter Bud (which would let Hash skip a possible extra copy when a new tuple is derived).

jhellerstein commented 12 years ago

Huh. My assumption would be that freeze adds cost. But I guess I'm wrong: http://www.cse.dmu.ac.uk/~hgs/ruby/performance/

Meanwhile, beware of freeze's semantics w.r.t. variables: http://m.onkey.org/ruby-i-don-t-like-3-object-freeze