Arc Forumnew | comments | leaders | submitlogin
2 points by CatDancer 5657 days ago | link | parent

Ah, I think there's another idea in here trying to get out that I haven't articulated.

If I'm writing a library function that provides access to some MzScheme functionality, then some bridging code needs to be written. In arc2, that bridging code is necessarily written in Scheme in order to implement Arc. However, once Arc is up and running, since I prefer to write in Arc over Scheme, I'd rather write that bridging code in Arc.

This bridging code is something I write very infrequently. And, someone who wanted to use my library function wouldn't need to look at the bridging code at all if they didn't want to.

From a kind of "Huffman coding" perspective we want symbols that are used a lot to be short (as long as they are still readable). Conversely we don't want valuable short symbols to be reserved for things that we don't have to type very often. This is why I don't like the naming of Anarki's "$" macro, not because I don't think that being able to evaluate a bit of Scheme code isn't valuable or important, but because such evals will usually be quickly encapsulated in some library function and I think that a symbol such as "$" to too rare and valuable to be used for something that just doesn't need to be typed very often.

Suppose the feature were named, I don't know, say "ac-passthru" or something. This would be no burden for me to type when I was writing library functions.

Then, if I, personally, wanted to use "mz" for some quick hacking, I can easily make a macro that expands mz into ac-passthru [assertion untested]. Now I get to use "mz" when I want, but I'm not preventing other programmers from using "mz" for their code (an abbreviation for "moonlight zebras" in someone's code, perhaps? :)



2 points by conanite 5657 days ago | link

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?

-----

1 point by CatDancer 5657 days ago | link

Are you prematurely worrying about conflicting names ? :))

touché, mayhap I am

add the relevant xdef in ac.scm

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.

-----