Normally Arc will flush all output for you. Thus if you say
arc> (do (repeat 5
(pr ".")
(sleep 1))
(prn))
you will see a dot being printed every second.
However, it can be inefficient to writing every little string constantly. If you'd prefer to call flush yourself, you can say:
arc> (declare 'explicit-flush #t)
now Arc won't call flush for you. If you run the above example again, you won't see one dot per second; instead you'll see nothing for five seconds and then all the dots will be printed at once.
Since noisy-each might be called with explicit-flush on, it calls flush to ensure that the dots are printed as it runs. This does no harm when explicit-flush is off.
I've been working a bit on rainbow optimisation lately, mostly to get welder up to an approximately usable speed. The bottleneck in welder is tokenising arc source code, so the tokeniser in parser.arc has been the target of my benchmarks.
On my mac, arc3 performs about 3 times faster than rainbow, which itself is now performing 5 times faster that it was a few weeks ago.
I used to use a prime-number generator to compare ... curiously rainbow performs slightly better for small numbers (find all primes under 10000, 413ms vs 465), but worse for large numbers (find all primes under 100000, 8.4s vs 7.4s). This particular generator uses continuations; there are probably other ways of writing it to exploit weaknesses in either java or scheme to get different results.
Wouldn't it be simpler just to fork from 4.2? Making immutable pairs not-really-immutable shouldn't actually break any existing PLT-based code, since that code won't modify them. ^_-
It might break some low-level optimizations in PLT Scheme itself (which could be fixed in the forked version), it might break compatibility with other projects that dig into the PLT code, and it might annoy some library writers who really didn't want careless users to shoot themselves in the feet or expose security holes, but that's all the trouble I can think of offhand.
Breaking the PLT Scheme optimizer by mutating pairs it thinks are going to be immutable and then going in and figuring out which optimizations to fix doesn't sound very simple to me... but, assuming that it was easy to do, what does starting from 4.2 do for us?
I guess I just see "Take the newest MzScheme and implement not-so-immutable conses again" as a conceptually easier task than "Take the fork and implement feature A and feature B as inspired by the newest MzScheme." Of course, the more objections we have to MzScheme changes, and the more features of our own we want to include, the harder this becomes.
Try it for yourself... you really need to be running timing tests against code that you want to run, since different code may end up being faster or slower.
This update gets ac.scm back into being a module, so to run Arc using this patch go back to using "mzscheme" as the command to run:
~/plt-4.1.5/bin/mzscheme -f as.scm
but no "-m", as that option has changed in plt4.
Getting ac.scm back into a module makes this version almost twice as fast as the last version of the patch. Unfortunately that's still not very good: it's taking 3.5 times as long to get to the Arc REPL prompt with this patch using plt4 as it does with the unmodified Arc using plt3.
The fix (import unquote and unquote-splicing) was both obvious and simple once I figured it out, but in the meantime I was quite bemused: how did I manage to do that?! :-)
However, I honestly don't think this is a useful or general enough function to go in arc.arc, especially as we already have 'fill-table, 'listtab, etc.
As for "creating a named table", er:
(= foo (table)) ; I'm unclear on what's difficult about creating a table.
I think the difficult part is passing in an arbitrary name to a function, for which the tables 'name' becomes set to, but I am just guessing that's what he wants...
and I agree I don't see a whole lot of need for the function to be part of the arc release..., since there are probably better ways to accomplish the same end result.... a good example of which is news.arc's storage of story records.
I think the difficult part is passing in an arbitrary name to a function, for which the tables 'name' becomes set to, but I am just guessing that's what he wants...
I rather doubt that's the issue, as it's easy to do with a macro.
arc> (mac filltbl (tbl keys vals)
`(= ,tbl (fill-table (table) (mappend list ,keys ,vals))))
#3(tagged mac #<procedure: filltbl>)
arc> (filltbl blah '(a b c) '(1 2 3))
#hash((c . 3) (a . 1) (b . 2))
arc> blah
#hash((c . 3) (a . 1) (b . 2))
I think it's just a request for a convenience function to zip together a list of keys with a list of values into a table, since the existing methods for creating tables center around having alternating key/value pairs.
Right now getting to the "arc>" prompt is 6.2 times slower, but that could be from not loading the Arc compiler as a module yet or from using the r5rs library.
Arc lists are terminated by 'nil, Scheme lists by '(). Because Scheme lists sometimes appear in Arc, the Arc runtime (such as 'is) treats '() like 'nil.
