<spk121>amz3: you could normalize to the machine's Dhrystone's benchmark <rlb>guile-2.2 is back in Debian testing <roelj>Is it possible to merge two hash tables (that are produces using the same hash function)? <hugo>You have to do it manually <hugo>It's actually not possible to merge two hash tables, except for inserting everything from one manually into the other <hugo>(define (merge-hash-table! to from) <hugo> (let ((key (car handle)) <hugo> (hash-set! to key value))) <hugo>roelj: this procedure does the trick <roelj>hugo: Alright! Thanks for showing the way. ***x1n4u- is now known as x1n4u
<justin_smith>alternatively you can create a third table and merge the other two in - there's something to be said for not mutating inputs <amz3>apparantly reverse! is faster that reverse <amz3>if there's something to be said for performance <justin_smith>of coures, it makes sense to make the mutating call the implementation level if you aren't using optimized immutable data structures (my head is stuck in that paradigm currently) <amz3>and I am stuck in performance trick lately <justin_smith>depending on use case, the immutable version can be a bonus because it means you don't need to make defensive copies, and merges / key adds can reuse internal structure <OrangeShark>need to evaluate your case and choose the best paradigm <amz3>when I create a list (or something similar) inside a procedure, I always use mutable version of sort and reverse, from the outside world, the procedure appears pure <amz3>like (define (proc) (sort! (map cons (iota 5) (iota 5)) (lambda (a b) (< (car a) (car b)))) <OrangeShark>amz3: yes, in the end, nothing is ever truly pure, you can only hide it <amz3>longer modules makes it for longer compilation times <amz3>I am experimenting with long modules <amz3>but it's handy otherwise <amz3>I joined my first pattern using my query engine