Is ./mzscheme a symbolic link pointing to a missing file? Or is ./mzscheme a shell script with an invalid interpreter line? (the first line, beginning with #! )
I totally have to remind myself every time that it's "ontable" for tables, not "each"
The (each (k v) h ...) syntax feels like a natural destructuring way to iterate over a table. And the cost of an extra pair of parens is more than offset by having an each that behaves the way you'd expect it to.
Thirded. I'd very much like to see this get into arc3's final release. This makes iterating over a given table just like iterating over the corresponding association list.
This makes iterating over a given table just like iterating over the corresponding association list
That's a cool point!
If calling a list wasn't already doing a lookup by position, I might like a call on a cons to do an alref so that I could use x!foo to do a lookup by 'foo whether x was a table or an assoc list.
It's easily recognisable even when small which is important for a logo and a favicon. I like the colours. And clearly it shows an amazing degree of artistic talent, the sort that could only be acquired in art school :)
Allow me nonetheless second some other commenters who observed
- the #\a concept is not obvious
- the keystone would normally be part of the arch, not under it
- the blue and black are difficult to distinguish in the small version
- while you explain the #\a and the keystone, the red/blue business is mysterious, and perhaps a tad decadent - art for art's sake and all that.
At a glance, it looks like the white bit has risen up out of the red bit (if you'll forgive the technical language here), and the blue bit is just background.
A slight improvement might be to make the horizontal edges of the #\a (top and bottom) a little thicker, to enhance the a-ity (although I can see that that might diminish the arch-ness). Another might be to use a brighter blue.
Are you planning to stick with this or are you inviting suggestions (not that the absence of an invitation has stopped me or anyone else) ?
arguably, this is incorrect, because 1.234 obviously isn't an integer, so arc3 improves on this by rounding. But (coerce "1.234" 'num) isn't available (in arc 2 or 3), so there's no way to use coerce for non-integers.
If there's a way to restrict the memory used by the mzscheme process, you could set an upper limit, and then
(with (things nil n 0)
(while t
(prn (++ n))
(push (new-thing) things))) ; not tested!
and wait for it to die. You won't have the memory size in bytes of each thing, but at least you know how many fit in your process, and that might be the more important number depending on your purpose.
Are you prematurely worrying about conflicting names ? :))
I admit I'm a bit confused about the bridging-code issue. I think if there was a bit of scheme functionality I wanted permanently available in my arc, I would add the relevant xdef in ac.scm. 'mz as it stands is fine for once-off or exploratory hacks, and as it's not there unless you've installed the patch, the name conflict isn't such an issue really.
I wonder is anyone preparing an app for mediocre zoos, motorcycle zen, or the Mark of Zorro?
Sure, that works. I prefer to program in Arc though.
as it's not there unless you've installed the patch, the name conflict isn't such an issue really
Oh, but I'm writing more code like my "lib" library which uses mz, so if you want to use my libraries, the name conflict issue will come up, if it is an issue.
Maybe I'll decide that I like "ac-passthru", not because I'm worried about possible future naming conflicts (which, as you point out, I've previously claimed should be dealt with in a different way), but because I think it's a better name for what it does.
An "mz" for once-off or exploratory hacks could after all be implemented in different ways, using ac-passthru or Scheme eval or connecting to a remote Scheme process, so I might be more comfortable not assuming that if I want to hack with a bit of Scheme code that passing through the Arc compiler is necessarily the way I want to do it.
