Arc Forumnew | comments | leaders | submitlogin
3 points by akkartik 2098 days ago | link | parent

Alternatively, we could make handler names start with the leading '/', so you say "defop /" instead of "defop ||".

Do people consider srv.arc to be 'part of arc' for compatibility purposes?

---

Or we could define the root handler using "defop nil".

  wart> (sym "")
  nil


2 points by Pauan 2097 days ago | link

"Do people consider srv.arc to be 'part of arc' for compatibility purposes?"

I would consider any Arc program to be "part of Arc" for compatibility purposes because any Arc program is supposed to use only the core and things defined in arc.arc (along with its own libraries, of course).

Obviously all bets are off if it uses the $ macro to drop into Racket, but then you're not really writing Arc code anymore, so I'm ignoring that case.

---

"(assign || (sym ""))"

That's a pretty good way of solving that one particular use-case, but it won't help in general because there might be some Arc program that actually does use the |...| notation more extensively.

However, I suspect such programs are quite rare, and with good reason. So I don't think it's a major deal if an Arc implementation chooses to not implement the |...| notation. However, such incompatibilities should be documented, so people using your implementation know what works and what doesn't (and why it doesn't work).

And in that case, it would probably also be a good idea to have your implementation throw an error if a program ever uses the |...| notation. That makes it easy to figure out which programs are broken, and makes it easy to pinpoint where the problem is so it can be easily fixed, rather than failing silently or at a later step in execution.

-----

1 point by akkartik 2097 days ago | link

"I would consider any Arc program to be "part of Arc" for compatibility purposes.."

I don't understand. If I write a hello world arc program, are you saying that's part of arc?

"..because any Arc program is supposed to use only the core and things defined in arc.arc."

I'm not sure what this means either. I think my question boils down to, "what do you consider to be the core of arc?"

-----

1 point by Pauan 2097 days ago | link

"I don't understand. If I write a hello world arc program, are you saying that's part of arc?"

For the sake of compatibility with Arc, yes. An implementation claiming compatibility with Arc should be capable of running programs designed for Arc 3.1.

---

"what do you consider to be the core of arc?"

We were discussing what constitutes "part of Arc" for compatibility purposes. "srv.arc" is not a part of the core of Arc, nor are any libraries written in Arc. But it is still "part of Arc" for the sake of compatibility, in the sense that a compatible implementation of Arc must be capable of running them, warts and all.

Unfortunately, that means that certain programs may end up relying on things inherited from Racket, such as the |...| syntax. I think it must be decided on a case-by-case basis whether compatibility with Arc 3.1 is worth it or not. In the particular case of |...| I don't think it's worth it. But I'm not the one implementing Arcueid: that's up to dido to decide.

-----

1 point by thaddeus 2097 days ago | link

That's my vote -> (defop nil ...)

-----