Arc Forumnew | comments | leaders | submitlogin
What to name syntax to bypass / tunnel through the Arc compiler?
5 points by CatDancer 4574 days ago | 6 comments
I have a little patch which introduces a syntax I've been calling "mz" which causes its contents to be passed unchanged through the Arc compiler. For example, if I say

  (mz (+ 1 2))
and I look at Arc's compiler output, the "(+ 1 2)" appears literally, and thus what I get is MzScheme's "+" being applied with an MzScheme function call to 1 and 2.

This lets me embed a bit of MzScheme inside of my Arc program. It can be used for some of the same tasks that Anarki's "$" macro (which lets you eval some MzScheme code) is used for, but also gives the bit of MzScheme code access to local lexical variables.

  (let a 4
    (mz (+ a 3)))
Naturally, what this does depends on the precise details of what the Arc compiler is generating, and thus will most likely be even less stable than the Arc language. Still, for quick hacks it's a fast way to get at some bit of MzScheme functionality.

That's all great, but I don't think the name "mz" that I've been using is a very good name. What the syntax does is cause an expression to pass through the Arc compiler unchanged. In a way it's like a form of quoting... A regular quote like

  '(+ a 3)
protects the expression from being evaluated. This compiler quoting form protects the expression from being compiled by the Arc compiler. Which has nothing to do with MzScheme ("mz") particularly.

Thoughts?



2 points by CatDancer 4573 days ago | link

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 4573 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 4573 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.

-----

1 point by conanite 4573 days ago | link

Which has nothing to do with MzScheme

Given that arc compiles to mzscheme, mz seems like the right name. If there was a CL-based arc with the same feature, the name would be more debatable. In rainbow for example, a "pass through the compiler unchanged" feature is meaningless - there is nothing on the other side that would understand. "mz" also has the advantage of being short, expressive and euphonic, unlike "qac" or "ptac"

-----

3 points by rntz 4567 days ago | link

More generally, why would you want the pass-through-compiler feature to be named the same thing in different arc systems if the backend is different? Code that works when you're compiling to mzscheme is useless if you're compiling to CL; you'd rather have it warn you that it doesn't know what the hell you're talking about when it sees "mz" than have it (mis)interpret your mzscheme code as CL code.

-----

2 points by thaddeus 4573 days ago | link

I like mz. It's short and clear to me.

-----