So I guess it's on purpose that `(hook 'somewhere)` doesn't do anything until you define a hook for that place yourself, e.g.:

    (defhook somewhere () (pr "Hello from somewhere"))

Guile, Picolisp and Arc can't make self-contained binaries, right? But Ferret looks interesting.

[0]: https://common-lisp.net/project/ecl/

[1]: https://call-cc.org/

- It breaks anything relying on `run-news`. For example if you have Anarki running as a systemd unit, you'll have to fix that.

- It breaks existing News sites because it expects the `www` folder to be in a different location.

- It creates an overcomplicated folder hierarchy for the Anarki package manager, e.g. if you add a custom app through prompt.arc, it will now be in `anarki/apps/news/www/apps/[user name]/[app name]` rather than `anarki/www/apps/[user name]/[app name]`. Is it really necessary to have another `apps` folder inside the `apps` folder? Why?

- Perhaps when new stuff is added, it is fine to break things, but what new features does this commit bring, or what problem does it solve? I am not sure what this ongoing shuffling around paths and files really helps, but it sure does break stuff. Would it not be more interesting to work on new features for News or new programs in Arc than bike shedding existing code?

I think you should really just check out the existing Arc package manager, prompt.arc. It does have a way of separating user apps from the rest of the Anarki repo. It can be used from within News, but perhaps it needs to be documented more in the README and shown more prominently in the News interface?

I am not saying what commits should stay or go, as the idea with Anarki is that it's open for everyone's commits. However, I do find this folder shuffling somewhat disagreeable, so perhaps I should just keep my own Anarki fork?

Again, sorry for being negative here. Am I being unreasonable?

Fair enough, although I would point out that, given that this is a language designed for experimentation with an open commit policy, breaking changes should be tolerated and expected if the end result improves the codebase, which in this case I believe it does.

Given that is not a mature language or a stable framework yet, I would disagree that breaking changes, per se, should be avoided as a matter of course. We should be breaking things harder and more often.

And... people just have to fix it once. No one is suggesting a new hierarchy every week. Literally, just that applications should live somewhere other than /lib.

> It creates an overcomplicated folder hierarchy for the Anarki package manager, e.g. if you add a custom app through prompt.arc, it will now be in `anarki/apps/news/www/apps/[user name]/[app name]` rather than `anarki/www/apps/[user name]/[app name]`. Is it really necessary to have another `apps` folder inside the `apps` folder? Why?

The package manager should be updated as well, mea culpa. But that demonstrates that the forum should have been moved to begin with, since it didn't conform to that convention. Also /anarki/www/apps/[user name]/[app name] is more complicated than the convention I want to use, which is /anarki/apps/[app name].

> Perhaps when new stuff is added, it is fine to break things, but what new features does this commit bring, or what problem does it solve?

It solves the problem of the forum being in the same path as the library. Every other language with a web framework separates one from the other.

>Again, sorry for being negative here. Am I being unreasonable?

For the criticism? No, I'm the newb, my last commit was kind of garbage, I can take it and I welcome it.

Not allowing in obvious breakage is also a way to show respect for your collaborators, other people programming on the same codebase. When you come to Arc you would be demotivated if the news app didn't work, if you had to first get it working, figure out who broke it and how. It's the same with others. When we find a few hours to hack on something fun, we all prefer that it start out in a non-broken state. And we try to leave it in a non-broken state.

So I have a suggestion for you: everytime you create a PR, first try to break it yourself. Ask yourself what changed, and what it may affect. Try to catch the really obvious stuff yourself, like "does news load, does it look the same, can I submit a post?" Run the unit tests. Report in the commit message or PR what all you did by way of testing. These exercises will make you a better programmer. Tell yourself that the goal is to make changes in an efficient manner, solve the problem in a single PR, rather than require more changes to fix breakage in one change, that cause their own breakage, and on and on.

Certainly a lot of things could be tested more; this would help.

But also, we might want to set Github to require the tests to pass on a PR before letting it be merged. I could be wrong, but I think a PR can be merged even if the tests fail.

It isn't broken, though, at least not if "broken" implies an unusable state. I did test the forum before I pushed, I just didn't catch everything... I didn't even know prompt.arc existed, or what it was for, but apparently neither did you. ;)

As for "breaking things harder and more often". I don't think 'harder' has to happen 'often'. I'd be ok with 'harder' when need be with more 'often' being good.

This language has 3-6 people active users and maybe another 6-10 lurkers. More changes like the app/news change have potential to garner more users and more users means more changes which may lead to a fuller and richer language.

Having the news app so heavily integrated was a poor design choice to begin with. This is a language and the language development should not be constrained by a single application which is currently the case. That app needs to be a downstream consumer of the language.

Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.

>Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.

I think it's possible to experiment with things while still considering stability and backwards compatibility. I recently reworked the password hashing function, but I took care to not break the logins of every user, when doing that.

I must say I'm a bit upset by you being so apparently casual and careless about creating several breakages[0][1][2] in News that I've had to fix, and then suggesting that I should just get off the master branch if I don't like your "experimentation".

I will. I'm done with this.

Experimentation is not the same as carelessness. Seriously, WTF is this?:

    (abs-link site-url* "anarki" "http://github.com/arclanguage/anarki"))

What bugs me here is not so much that stuff gets broken now and then, but this nonchalant attitude to breaking things, and lack of acknowledgement for others that have to wipe up the mess.

> And... people just have to fix it once.

> Given that is not a mature language or a stable framework yet, I would disagree that breaking changes, per se, should be avoided as a matter of course.

Also, I have a strong aversion to CAPTCHAs, partly because they're non-free Google SaSS, but also just because they are just plain annoying. Why would anyone want to inflict that upon themselves? There's already plenty of ways to deal with spammers in News.

You don't have to wipe up the mess. I didn't ask you to wipe up the mess, and I didn't expect you to. I also suspect you're conflating my beliefs about whether or not Anarki should be willing to make breaking changes when necessary with some general lack of regard for whether or not anything works at all, and that's not the case.

I'm new to lisps, to this lisp in particular, to this framework, and to working in a team. I admit (and have admitted) that I make mistakes and I've picked up some bad habits that I need to correct. If I know about an issue, I will gladly deal with it.

But, as to the specific issues you listed... I don't know what happened with the css (it worked for me when I pushed it but your comment that it might have needed testing in other browsers is correct,) but #104 wasn't broken, but misconfigured. And you've explained at length already why that entire commit was misguided, but it wasn't broken.

But sometimes I do miss things, forget things, there are some mistakes I might not even see because I'm working on Windows. But I am trying to make things better here. So thank you for cleaning up after me, and I will try harder in the future.

That said, I stand by moving news, and I stand by my statement that we should be making breaking changes (with the caveat that those changes improve the code.) Now is the time to do that, when there are so few people actually using this codebase, as opposed to later when there might be dozens or hundreds, or never, simply because change is difficult to deal with. Chances are most of the entire universe of people using this fork in production are already in this thread. Moving news to a new folder shouldn't be a reason to create a hostile fork.

And that's why I agreed with i4cu's suggestion earler that a stable branch might be a good idea... which for some reason you interpreted as a personal attack,

    "(...) and then suggesting that I should just 
    get off the master branch if I don't like your "experimentation"."

I agree. That was my own expectation, and also I might have been wrong in expecting stability from a repo that's meant to be "extremely permissive in accepting patches."

> And you've explained at length already why that entire commit was misguided, but it wasn't broken.

That I don't agree with. I would consider a commit, that makes all links not work in the default config and prepends the site name to already absolute links, broken as well as misguided.

> But I am trying to make things better here. So thank you for cleaning up after me, and I will try harder in the future.

That's great. It's good to see work done on Arc. Looking forward to see where this goes.

> Moving news to a new folder shouldn't be a reason to create a hostile fork.

It's our job, yours and mine and that of other long-time participants, to explain the norms that we have here. And to do it in a nice way, realizing that what's obvious to us isn't necessarily obvious to newcomers.

This is a pretty non-standard repo where anybody can make changes, so it's understandable that a newcomer may think stability is not important. We have to articulate precisely what sorts of stability are necessary and what we don't consider important. It's a tough job. So I really hope you stick around to help us out :)

Definitely!

> I'm actually curious how you run a production service on Anarki. Everytime I ever tried to do that I would maintain a cutout in between that was wholly in my control, and decide what patches should flow from Anarki to it.

Usually I'm trying out the latest commits on a local laptop before doing git pull on the server. Works fine. If it's broken for some reason, then I'll just do a `git reset --hard [known-good-revision]`, because the `www` folder with all the news data is outside the git tree anyway so it stays as it is (and no-one have yet been changing the data format, so that's not an issue either.)

That, to me, is a good argument for a karma.arc library.

> to integrate into the layout and navigation of News.

In Clojure there are namespaces and I can rebind vars like such:

  (alter-var-root #'app.arc/site-url* (constantly "http://news.example.com/"))

I think people are already experimenting elsewhere even if its only their local machines.

Rocketnia has done some work on namespaces in anarki/lib/ns.arc but I haven't had too much of a look at it yet. I would personally appreciate if there was a little bit added to the README about how those work.

Keep in mind that if you use ns.arc to load an Arc library in a namespace, you'll usually have to work around problems with unhygienic macros on a case-by-case basis. I don't think this would typically be any easier than working around whatever problems were preventing you from loading it in the main namespace.

What you're saying would make sense if html.arc were a self-contained library for public use. Why does it have shortcuts for some HTML tags but not others? Someone in the public might want to use those others!

I think I'd approach this differently: Every client of html.arc can already say (tag foo ...) or (tag (foo ...) ...) to write an HTML tag. Verbosity is sometimes valuable; it can let us grep the codebase for something like "tag" to find all the places HTML tags are generated. So if the shortcuts of html.arc are causing distress over their inconsistency, I would remove all of them... from html.arc, at least.

Sometimes brevity is valuable too. It helps us fit a bunch of code on one page, for instance. So those things I would remove from html.arc could still belong in another file. Or maybe a few other files; sometimes utilities are self-consistent on their own but are inconsistent when viewed as part of a group.

I think your vision of how these shortcuts should work is self-consistent, and it would even work well as a Racket library. In Racket, we can use `(require (only-in ...))` or `(require (except-in ...))` to require some identifiers from a library without getting identifiers that clobber the ones we're using for other purposes. And we can use `(require (prefix-in foo: ...))` to require a library's entire set of exports under a prefix.

Anarki doesn't have Racket's `only-in`, `except-in`, or `prefix-in` abilities; it only has the ability to load everything in a file. But Anarki users can achieve something similar: The library itself can use more verbose names like `body>` or something, and users can write `(= body body>)` if they want to get rid of the verbosity.

---

I think I've actually seen that `body>` naming convention somewhere, but I can't find it. While I was looking for it, I noticed a similar level of brevity in almkglor's whtml.arc on the old Arc 2 Anarki branch:

https://github.com/arclanguage/anarki/blob/arc2.master/whtml...

  (w/html
    ('head ('title (prn "Page")))
    ('(body style "font-size: 200%")
      (prn "HELLO!")))

The thing is, it is, whether it's meant to be or not. Arc's documentation describes it under the heading "html generation" (in general.) It's in what appears to be Arc's "standard library" /lib, so any newcomer is going to see it there and think that's what they should use when they want to generate html. And it has the rather canonical-seeming name of "html.arc."

If html.arc isn't supposed to be Arc's general purpose library for HTML generation then what do we call it when we make it?

I think discussions about APIs and interfaces are missing the confusion (which, admittedly, may just be mine) over what exactly /lib is supposed to be for?

>I noticed a similar level of brevity in almkglor's whtml.arc on the old Arc 2 Anarki branch:

That documentation is for Anarki Stable, the branch meant for users who aren't thrilled with Anarki's changes and just want to use official Arc, but who would rather not have to fix official Arc's known bugs on their own. On that branch, html.arc probably is the only HTML-generation library we can or should document.

Despite not being written as documentation for the Anarki master branch, it's nevertheless some of the most accessible documentation for that purpose. I see that's pretty frustrating. It's good that you're mentioning it or no one would work on it.

Yesterday, since this was on my mind thanks to these threads, I wrote some code for generating a simple HTML page based on Anarki's (help foo) documentation. Once I get this to automatically deploy with each new Anarki commit, it should give us a much more up-to-date documentation resource to link to.

---

"any newcomer is going to see it there and think that's what they should use when they want to generate html"

It pretty much is! Even if it's not as good as you can imagine it being, it's still the go-to HTML generation library for Anarki.

When I implied it wasn't "a self-contained library for public use," what I meant was that it was primarily made to get the webapps to work. It's quite a non-minimalistic approach to HTML generation if you ask me -- I'd rather treat every attribute uniformly rather than having a big table of special cases -- but in other places it does only what it needs to do for the purposes of those applications.

Paul Graham pursued the web server code in order to put pressure on the "core language" in arc.arc, to make sure he was focusing on operators that were actually good for something. He released the language to the public so he could put a wider variety of pressure on arc.arc. The operators in arc.arc were never finished, so html.arc was probably a long way from being finished itself.

---

"If html.arc isn't supposed to be Arc's general purpose library for HTML generation then what do we call it when we make it?"

If someone makes a new library for HTML generation, we can potentially embrace that as the new html.arc. Anarki is unstable enough that this would be pretty normal (although I think people have had a polite tendency not to delete something in case someone else was still attached to it).

---

"[paraphrased] What is /lib for?"

Personally, I'm reluctant to call it a "standard library" without a standards document, but it does "come standard" with Anarki, so...

Of the 14 files in the release of arc0.tar, the libs.arc file contained this:

  (map load '("strings.arc"
              "pprint.arc"
              "code.arc"
              "html.arc"
              "srv.arc"
              "app.arc"
              "prompt.arc"))

Looks like there was always a lib/ directory in Anarki, even as far back as the first Git commit. At this point it's the obvious place to put files that some people might be interested to (load ...) and some people wouldn't care about. If someone has a single .arc file to share, dumping it there is easy regardless of what state it's in, and it usually fits right in.

---

"I really like it... but wow am I not capable of even reading that code ._."

Aw, I bet you could! :) Do you want to? Maybe if you've got a specific piece of code that perplexes you, we can help out.

I'm used to more verbose languages and the redundancy of heavier syntax. Sometimes Arc reads to me like a diagram sketched on a napkin.

>It could be that whtml.arc's time for porting has arrived. :-p

What you want are local macros (Common Lisp's `macrolet`, Racket's `let-syntax`). Suppose we name Arc's equivalent `w/mac`.

Then (w/html ...) could expand to this:

  (w/mac html tag-html
         head tag-head
         body tag-body
         ...
    ...)

This would be something of a breaking change to Anarki because it means Anarki will now allow a local variable to shadow a global macro. That was the problem you encountered with (body) in the first place; some calls to local variables were expanding as macro calls now because the macro lookup ignored local variables altogether.

There might be some code out there of the form

  (let foo 1
    (bar foo))

For some time I've thought it would be worth it for the local macro support, but I'm too afraid to make the breaking changes.

Nevertheless, a while back, there was a consensus here that the way things worked already was a bug. See "Global macro names take precedence over local lexical variables" at [1]. I don't remember if this bug was ever fixed in Anarki; it doesn't seem to be fixed now. (Maybe there was another consensus to reverse it? It could happen.) It's the very same bug you encountered with (body) in the first place.

I was responding to this:

"Of the 14 files in the release of arc0.tar, the libs.arc file contained this:

  (map load '("strings.arc"
              "pprint.arc"
              "code.arc"
              "html.arc"
              "srv.arc"
              "app.arc"
              "prompt.arc"))

Ha. Yeah. (cough (body) cough).

>I'm not sure what you'd consider problematic about news.arc being in the lib folder

It's not news.arc per se, it's everything belonging to the forum (folders, static files, tests, etc) and the general practice of keeping applications in the same place as the standard library (for want of a better term.)

>(But also: why?)

Just a quick thought on this: Has anyone tried using Racklog[0] within Arc?

The main idea is pretty much just 'S-expressions have dots; what if that dotted part could be not just an atom but a full structured expression like a Lisp form'. (or a Prolog term, if you are familiar with Prolog).

This very small idea opens up a number of new possibilities in creating very compressed notation, I think. It's mostly useful for people interested in building Domain Specific Languages, where you want a minimum amount of friction from the underlying syntax, and no limit on the kinds of expressions that can be represented.

With a particular emphasis on something that can be embedded easily into raw text as a markup language, without needing to remap a lot of characters like in HTML, but that also allows the full syntactic power of an arbitrary programming or data-representation language (eg Lisp or Prolog) if required. Also something that can be used to represent very low-level concerns, like circular references and read-time macro insertion and other tricky syntax-level things that Lisps tend to use reader macros to do.

Again, this is purely at the syntax level. Translating an actual language to work smoothly on top of this syntax is a much bigger project. But this syntax stands midway between raw S-expressions and 'heavier' syntaxes that have a notion of 'typed expressions' which S-expressions don't natively provide.

SXML is a great example of how XML can be translated into pure S-expressions. But I think using T-expressions we could translate, losslessly, all of XML/HTML, CSS, Javascript, Lisp, RDF/N3, etc, into something like Lisp 'forms' or Prolog 'terms' on top of a very thin layer of lists-plus-type-markers.

For this:

  (cons 1 (cons (car x) (cdr y)))

  (1 (/ car x) / cdr y)

  `(1 ,(car x) . ,(cdr y))

  (quasiquote (1 (unquote (car x)) . (unquote (cdr y))))

If you write a slightly different macro where the syntax for (unquote ___) is (/ . ___), then you could use it like this, which matches the syntax of your example exactly:

  (t-expr (1 (/ car x) / cdr y))

It sounds like you're looking at this as a data encoding? A lot of data encodings take pains not to be Turing-complete. Then again, for inexpressive languages like HTML, there are a lot of Turing-complete templating languages designed to dynamically generate them.

HTML has other languages embedded in it like JavaScript, and it sounds like that's relevant to what you're going for here. You're going for a language which can begin running even though not all the syntax is computed yet. That's pretty interesting. (Actually, maybe I'm projecting, 'cause I've been dreaming of something like that too: A language which multiple people collaborate on, which can begin running before all of the code has been written.)

You can of course experiment with that in most Lisp dialects using a quasiquoted term where all the unquotes have functions in them:

  (my-interpreter `(1 ,(lambda () (car x)) . ,(lambda (cdr y))))

Would be seriously cool if the CAPTCHA was implemented in Arc and generated the images locally instead of relying on some Google SASS.