Arc Forumnew | comments | leaders | submitlogin
Comments on srv.arc
13 points by kens2 5871 days ago | 9 comments
I've been looking at srv.arc and I have a few comments.

First, it is unusably broken on many plaforms due to the reasons people have posted before (date, news.arc, mkdir, etc.)

srv.arc has a severe lack of consistency. I count five (!) different ways of defining a continuation function: e.g. defop takes "req" and body, defop-raw takes "(str req)" and body, aform takes a continuation function, w/link takes a continuation expression, and onlink takes a continuation body.

A bizarre bug:

  arc> (defop mylink req (prn "hello"))
  arc> (defopr mylink req (prn "newlink"))
  arc> (defop mylink req (prn "hello"))
The result is /mylink generates a page that is the text for a redirect, including "Location:" (because redirector* is still set), but outputs this as HTML and doesn't redirect. This puzzled me for a while.

Parts of srv.arc seem nice and orthogonal. You can define a page or a redirect, without or with header access, with defop, defopr, defop-raw, and defopr-raw. You can make a form of these four types with aform, arform, aformh, and arform. But the bizarre part is that aform uses defopr, not defop. I.e. both aform and aformh go through /x so aform needs an extra (prn).

The set of operations seems somewhat random. Onlink seems mostly redundant with linkf. Operations that you'd expect for consistency are missing: w/rlink-if, timed-arform, rurl-for.

There's also the puzzling jfnurl*, which is a supposedly but not-really asynchronous call.

I'm pretty sure that harvest-fnids will die in the split if there are < 2000 fnids and > 18000 timed-fnids, but I haven't verified this.

(Is lack of consistency something that bothers other people, or do I have the wrong mindset here? Some things seem like accidental lack of consistency. But maybe the motivation behind 5 ways of creating continuation functions is that it makes the code shorter since you can pick the shortest technique and save a few characters. If so, it strikes me as the wrong tradeoff to make the language more difficult to use in order to make programs a few characters shorter. I.e. "onlink" makes the language more powerful according to the "brevity = power" metric since it can save a "do" token, but remembering that onlink works the opposite of w/link makes the language marginally harder to use.)



4 points by almkglor 5871 days ago | link

A very nasty lack is the fact that you can have an operation that's always a redirect, or an operation that always generates HTML (and only HTML too - the server automatically assumes that it's HTML without asking), but not one which might redirect or might generate HTML (or generate something else, like a bitmap from, say, a ray tracer or ray caster ^^).

> I'm pretty sure that harvest-fnids will die in the split if there are < 2000 fnids and > 18000 timed-fnids, but I haven't verified this.

Haruu, this conjecture seems correct.

Edit: Fixed(?) and on the git. Somebody had better check my code though.

>Is lack of consistency something that bothers other people, or do I have the wrong mindset here?

It bothers me too. For that reason I'm practically rebuilding bits and pieces of the server (e.g. w/html, cached-table).

-----

3 points by kens2 5870 days ago | link

Ok, I'm stumped. What's the difference between arform and arformh? I thought arformh gave access to the headers, but they both do. arformh doesn't update save-optime, but I think that's just an accident. Why do these both exist?

Here's sample code:

  (defop prreq req (prn req))

  (defop a1 req (arform [do (prn "Set-Cookie: foo=234") "prreq"] (submit)))

  (defop a2 req (arformh [do (prn "Set-Cookie: foo=345") "prreq"] (submit)))
Going to /a1 or /a2 and clicking the button shows that both update the cookie and redirect to /prreq. So why are there separate arform and arformh macros?

-----

2 points by almkglor 5870 days ago | link

My bet is, this is a thinko by pg. He planned to restrict arform to not emitting anything, but forgot to actually put the restriction.

The code for both forms are quite a few lines apart too.

http://www.paulgraham.com/gh.html section: recognition

Edit: after some time scanning through the code - it seems that arformh's time is measured, but arform's time is not. Or vice versa, I could've gotten confused.

Cref: rfnurl* and rfnurl2* . rfnurl* is "r", r is (defopr r ...), defopr is (... (defop-raw ...)), defop-raw is (... (save-optime ...))

rfunurl2* is "y", y is (defopr-raw y ...), defopr-raw doesn't add any code to the body: (fn ,parms ,@body)

-----

5 points by pg 5869 days ago | link

Some of these operators will probably go away eventually. The reason there are many is that I'm experimenting to see which variants end up being used most.

The defopr redef problem is in fact a bug; will fix.

-----

2 points by kens2 5868 days ago | link

I hope splitlines in app.arc is a leftover obsolete function. It makes no sense otherwise.

-----

2 points by kens2 5867 days ago | link

One comment on app.arc: readvar in app.arc uses valid-url, which is defined in news.arc. If valid-url were in app.arc instead, the layering would be better-defined. (Also, readvar wouldn't break when I comment out news.arc to work around the || redefinition problem.)

-----

1 point by drcode 5871 days ago | link

I think srv.arc is still pretty rough- I've been able to uses it with success, however, despite the quirks.

PG is not really a big fan of consistency. I think his reasoning is that consistency is another word for duplication and if you have it you're probably not using the most concise definition of your problem. I think this explains the inconsistencies in srv.arc. I suspect, as time goes on, this file will become smaller and cleaner as pg refactors it- However, I doubt it will become more "consistent".

One classic example of the lack of functions "for consistency's sake" in arc is that there is no 'cdar.

-----

4 points by kens2 5870 days ago | link

When you say you've been able to use srv.arc with success, do you mean the unmodified arc2.tar version or a patched version such as Anarki? Let me clarify that when I said above that srv.arc was broken, I was referring to the official version.

-----

1 point by drcode 5869 days ago | link

you are correct- I should have clarified I'm using the patched version with success :)

-----