Arc Forumnew | comments | leaders | submit | rocketnia's commentslogin

This is a blog post I wrote up about a bunch of programming I've been doing for my Cene language and some related Racket libraries.

I've finally been able to make an extensible `quasiquote` built on what I call hypersnippets. I've also referred to this as "higher-quasiquotation-shaped syntax" in the past, and lately I understand that my hypersnippets are the exact same thing as what people already refer to as "opetopes" in higher category theory.

Building this kind of extensible `quasiquote` operation is a goal I've been pursuing for two years now. Now I can work on polishing up the code, sorting things out, documenting them... and, ultimately, returning to the task I was doing two years ago before I had to go out of my way to figure out hypersnippets: Doing polish and documentation for the Cene language itself.

reply

3 points by akkartik 13 days ago | link

Looking forward to seeing what use you put user-defined unquote macros to!

reply

2 points by rocketnia 13 days ago | link

Thanks! :)

reply

2 points by hjek 13 days ago | link

What is a `hypertee`?

reply


Interpreter? Are you talking about Racket's bytecode interpreter?

reply

1 point by akkartik 17 days ago | link

No, I was forgetting that ac is considered a compiler :) But it compiles the Arc codebase every single time Arc starts up. Maybe we should start memoizing its outputs to disk somehow, see if that makes it noticeably faster. My suspicion is egregious runtime processing like ar-denil-last and ar-apply-args will cause it to not make a difference.

Given the pervasiveness with which Arc has to make such transforms at runtime, I've gotten into the habit of thinking of it effectively as an interpreter.

reply

4 points by rocketnia 18 days ago | link | parent | on: Installation on windows?

I've been pretty shy about it, but I finally sent a tweet three years ago.

https://twitter.com/rocketnia/status/658565199402692608

reply

3 points by akkartik 17 days ago | link

Tweets can be missed. Perhaps we should email hn@ycombinator.com.

I've been reluctant to do this, because the outcome may well be, "wait, is this old site really still up? Let's just take it down." :) Don't mind li'l ol' us out here, we're no trouble, no trouble at all..

reply

2 points by hjek 17 days ago | link

> "wait, is this old site really still up? Let's just take it down."

That is a valid concern. Perhaps, we could ask that if YC chooses to shut it down, could they at least give someone here a copy of the `www` folder?

Then someone could take over hosting this forum (which possibly might be on a different domain).

I have a somewhat reliable server running anyway, and it wouldn't be a problem for me to do this, but if someone else could do it, that would also be great.

But yes, worst case scenario is that this site is nuked. But that would just be such a disrespectful response, so I kinda doubt it..?

reply

3 points by i4cu 17 days ago | link

If someone does email, please request that the main page[1] be updated with a link to anarki as opposed to just a change in install instructions.

1. http://www.arclanguage.org/

edit: I'm ok if they take it down. I'll know where to go via the anarki wiki (if someone updates it). And it may actually be better if they do take it down IMHO as it will force everyone to find a place with more control over the setup.

reply

3 points by krapp 17 days ago | link

I mean... would it be so bad for the Anarki community to be hosted on a forum running Anarki?

reply

2 points by hjek 17 days ago | link

Then we would be even able to actually search stuff on the site!

reply

3 points by shader 17 days ago | link

I think if we fork the community site to run on anarki. which I think is more likely than being given control over the Arc Forum, we should consider ways to archive and bring forward all of the stuff on the existing arc forum. It shouldn't be too hard to crawl the forum, though I think there might be some DoS prevention that would slow it down.

reply

3 points by rocketnia 18 days ago | link | parent | on: Anarki Reference Documentation

Yeah, these would be great! I focused on shipping something, but there are many ways it can be improved. :)

reply

5 points by rocketnia 22 days ago | link | parent | on: Anarki Reference Documentation

Over the past week, I set up some HTML generation code and a deployment script on Anarki that creates this documentation page based on Anarki's (help ...) information.

I used this GitHub issue as a journal of my progress: https://github.com/arclanguage/anarki/issues/112

There are several more things I should explain about this:

-

===== What information a help entry is based on =====

Sometimes, some help information is populated while other information isn't available. For instance, right now `list` has everything help.arc is designed to display except for a docstring:

  arc> (help list)
  [fn]  (list . args)
  list is not documented.
  
  Examples:
    arc> (list 1 2 3)
    (1 2 3)
    arc> (list "a" '(1 2) 3)
    (a (1 2) 3)
  nil
  arc> (src list)
  (from "arc.arc")
  (def list args args)
  nil
It has a signature ('args), an implementation definer ('def), an implementation body ('args), a source file ("arc.arc"), and examples ('((list 1 2 3) (1 2 3) (list "a" '(1 2) 3) ("a" (1 2) 3))), and of course a value that has a type ('fn), but it has no docstring.

When the code in build-web-help.arc generates the HTML page, it determines whether to display a help entry purely by whether it has a docstring or not. I figure this is a good way to distinguish between things that are interesting to read about and things that are idiosyncratic helper functions, but one consequence is that there is no entry displayed for `list` right now.

-

===== Broken links =====

When the documentation refers to another entry by [[foo]], it's converted to an link to the relevant entry on the page. If there is no entry by that name on the page, it's instead converted to a span of style "broken-link", which shows up in red. If you'd like to fill in gaps in the documentation, you can view the source of the page to find all the occurrences of "broken-link".

-

===== Security of repository access privileges =====

The script pushes to Anarki's gh-pages repo using a personal access token for my GitHub machine user, rocketniabot. I just created rocketniabot for this purpose. The token is limited to pushing to rocketniabot's public repos, and right now the only public repo rocketniabot has access to is Anarki. If this changes in the future, I might want to ask someone else if they can use an access token. (And if no one wants to volunteer one, it's not the end of the world; we'll just stop having automatic pushes to the `gh-pages` branch until it's fixed again.)

The token is not committed to the repo; it's set up in the Travis CI settings as a so-called "encrypted environment variable," which is only exposed during a non-pull-request build or a pull request build that comes from another branch in the same repo. I believe this prevents non-contributors from accessing the token.

Although people could make rocketniabot look bad by having it push abusive content to the `gh-pages` branch, they would first have to either push a build script that exposes the token or push content like that to the `master` branch themselves.

If we notice either of those kinds of abuse occurring, I recommend we take two actions:

- Remove that contributor from the Anarki project on GitHub so they can't keep doing this.

- Please let me know so I can revoke the compromised rocketniabot access token.

- Until I do that, remove the rocketniabot contributor from the Anarki project.

- If you'd like to set up automatic `gh-pages` pushes again and I'm not responding to messages, then I recommend you choose another user account who's willing to be responsible for the automatic pushes, have that account set up a personal access token with public repo access, and put that token in the Travis CI configuration instead. (If you do this, please change the variable name so it's not "ROCKETNIABOT_GH_TOKEN". I think we need to keep track of whose it is so we can notify the right person when it's compromised.)

-

===== Security of the website's client-side data =====

If we ever have any page on the arclanguage.github.io domain store client-side data (like localStorage entries or cookies), someone could potentially access this information and take advantage of it before they're removed from the project. Because of this, I recommend we don't store any client-side data on that domain.

reply

3 points by rocketnia 26 days ago | link | parent | on: Separation of concerns

Please be patient with krapp, hjek.

You also made a bunch of breaking changes the repo a while ago. Because of those, I got more of the tests running under the Travis CI script to help us all monitor them without having to ask each other to remember to run them all the time. I really hope I didn't make you feel ashamed about that. You got to make changes, and I got to make changes, and I felt like the repo was better with both of those together. The same is true here.

reply

3 points by hjek 26 days ago | link

I did break some things in Anarki, and I appreciate you spending time helping me fix those breakages and adding more automated tests. Thank you.

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.

And, quite unrelated, I'm not big on Github as their site requires non-free JS, and I'm particularly wary of them since they were bought by MS, so that is just one more reason to host the code elsewhere. So, I've forked Anarki, and we'll see what happens: https://notabug.org/hjek/knark

reply

3 points by akkartik 25 days ago | link

I agree that we should hold ourselves to some standard about not breaking Anarki for each other.

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 :)

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.

reply

2 points by hjek 25 days ago | link

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

I find it a lot simpler to manage than for example Wordpress (although Wordpress on the other hand has tons more featuers and plugins).

reply

3 points by krapp 25 days ago | link

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

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"."
Rather than more charitably, that you should stay on the master branch and the unstable branch should be elsewhere, as I was actually conceding your point and agreeing with what I thought would be an equitable solution.

reply

2 points by hjek 23 days ago | link

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

Let's just call it a fork, not a hostile fork, shall we? Also there's some other reasons listed in the readme of the fork.

reply

3 points by i4cu 26 days ago | link

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

Languages allow people to make their own choices on what is worthy to build. Debates like this are why it's a shitty idea to have apps baked into the language.

reply

3 points by hjek 25 days ago | link

True. The tight coupling between Arc and News can in some cases be a problem.

It goes a bit further than the folder layout though, and I find the border between app.arc and news.arc a bit murky.

reply

4 points by i4cu 25 days ago | link

> I find the border between app.arc and news.arc a bit murky.

It could just be the name that's offsetting you, but app.arc is an application library just like srv.arc is, only manages application ops/state instead of server ops/state. The best way to look at it is that app.arc, like srv.arc, can optionally be used by different applications (like news.arc, blog.arc or whatever), which is why it's under lib. Someone who wants to build an app, needs to know what libs can be used and those can be. They also need to know that news.arc is not a library to to use for a new shiny app they want to build and when they want to share their app where to put it. Right now the only place is under app/, and ideally (IMHO) we can move them out further someday.

reply

4 points by hjek 24 days ago | link

Agreed. Yet it is also possible to imagine apps that could benefit from tighter coupling with News, e.g. to access user 'karma' and to integrate into the layout and navigation of News.

reply

3 points by i4cu 24 days ago | link

> to access user 'karma'

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

> to integrate into the layout and navigation of News.

which is an app. :)

reply

3 points by hjek 23 days ago | link

Interesting idea.

Also, the password reset email function in app.arc requires `this-site` to be set, but `this-site` is set in news.arc. I'm not sure how I'd go about fixing that.

reply

4 points by i4cu 23 days ago | link

I hadn't realized that arc could even point to an unbound variable and still have the file load without errors. Oh my.

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

  (alter-var-root #'app.arc/site-url* (constantly "http://news.example.com/"))
So I could just put values (like site-url*) into app.arc with default settings and reset them from news.arc. Provided that it's utilized dynamically then all is good.

However lacking this functionality in arc I would just move the required config settings to app.arc and be done with it. You're still loading app.arc at the top of news.arc so the only real problem is app users need to know to change the settings therein (a comment would do).

reply

2 points by krapp 24 days ago | link

>which is an app. :)

News already has a repl and "apps" in prompt.arc, and I'm already working on getting them to work together. That could provide the basis for a plugin (app, what have you) system.

reply

5 points by rocketnia 27 days ago | link | parent | on: Separation of concerns

Fixing other people's test breakage is one of the only things I can do for Anarki that doesn't make me feel like I'm breaking things myself. :-p

reply

4 points by zck 25 days ago | link

Well, it's a great help! Writing tests can help too, but just being around and helping is wonderful.

reply


Is sounds like most of what you're talking about is quasiquotation. (Maybe a lazy quasiquotation?)

For this:

  (cons 1 (cons (car x) (cdr y)))
You're writing this:

  (1 (/ car x) / cdr y)
The same thing with quasiquotation would usually be:

  `(1 ,(car x) . ,(cdr y))
And that's sugar for this (possibly using different words on different Lisp dialects):

  (quasiquote (1 (unquote (car x)) . (unquote (cdr y))))
And then `quasiquote` itself is a macro. It's an interesting macro to implement, and I just spent like two years trying to streamline the way I was implementing it for my languages 'cause I kept adding bells and whistles to it. :)

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))
I think the advantages of quasiquotation specifically shine when the quoted data is also program code in the same language (or like you just said, a DSL). In that specific case, I like that the code I'm writing looks the same regardless of whether it's under an unquote or not. There's a practical advantage in terms of being able to copy the code back and forth as necessary.

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))))
And you could write a macro that puts in those lambdas automatically so it's not so verbose. Then your parser could use the Lisp's reader, wrap the result in (t-expr ...), and eval it in an appropriate namespace to yield your compiled program-syntax-with-functions-in-it. Then you could pass that syntax through an interpreter.

Is this all making sense? XD I started going through ideas a little fast, and maybe I missed your point a long time ago.

reply

3 points by rocketnia 29 days ago | link | parent | on: Separation of concerns

Have you seen lib/ns.arc.t? If you want more examples than that... could you give examples of what examples you'd like to see?

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.

When I made ns.arc, I did make a few changes to Anarki so it would cooperate a little better with Racket namespace manipulation. When I made Anarki fit into the Racket ecosystem with `raco install anarki` and `(require anarki)` and `#lang anarki` support, I made several more changes that made it possible to do things like load more than one instance of the Anarki built-ins in separate Racket namespaces. However, ns.arc is still primarily a library for manipulating Racket namespace objects. Any use it has as a library isolation tool is still aspirational.

reply

2 points by krapp 29 days ago | link

One persistent problem is that the HTML macros have to work around everything else, and as a result, the implementation is haphazard.

You can't build an HTML table with (table) for instance, it has to be (tab)... but just ignore that (tab) doesn't print \t. I accidentally broke things adding a (body) macro because other macros were using that for expansion. The best possible world would be one in which every HTML macro matched its corresponding HTML tag, or if Anarki supported XML syntax natively. Without some kind of namespacing or scoping the former would be impossible, and I suspect the latter would annoy Lisp purists.

reply

2 points by rocketnia 28 days ago | link

I'm really glad you have an opinion about what the HTML library should do. Without bold, breaking commits like yours and hjek's, Anarki doesn't go anywhere. They're pretty much the only way Anarki gets maintained at all.

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!")))
Scoped DSL techniques like this one can be a nice way to get some greppability (searching for "w/html") while also getting some brevity (shaving three characters off of "tag " to arrive at "'").

reply

1 point by krapp 27 days ago | link

>What you're saying would make sense if html.arc were a self-contained library for public use.

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:

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

reply

3 points by rocketnia 27 days ago | link

"Arc's documentation describes it under the heading "html generation" (in general.)"

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"))
So essentially half of the files in the first Arc release were essentially lib/ files that just hadn't necessitated their own folder yet.

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.

Anyhow, one of the only reasons so many things are still stuck in the "arc2.master" branch is that porting them would be too much work. It could be that whtml.arc's time for porting has arrived. :-p

reply

2 points by akkartik 26 days ago | link

lib/tem.arc was extracted out of the original codebase. There may be other examples like that.

reply

3 points by rocketnia 26 days ago | link

Hmm, it doesn't look like tem.arc was in any of Anarki's versions of the official releases. Didn't you factor out that file?

reply

2 points by akkartik 25 days ago | link

Yeah, that's what I meant :) but I was lax in my phrasing.

https://github.com/arclanguage/anarki/commit/2820bbf7ee

reply

2 points by rocketnia 25 days ago | link

I'm not sure what you're saying it's an example of...

reply

2 points by i4cu 25 days ago | link

Your comment detailed what the libs.arc file contained.

the code within tem.arc was originally part-in-parcel within those files, but was extracted out into its' own file. So he was just commenting that there is other code that exists in anarki that was originally included and that there may be more examples of such.

reply

3 points by akkartik 25 days ago | link

Right. It's not the case that everything in libs/ that isn't an original filename is new code.

It was just a minor nit :)

reply

3 points by rocketnia 24 days ago | link

Ah, I didn't even know I was implying that. Thanks for clarifying. :)

reply

4 points by i4cu 24 days ago | link

Anytime you need us to let you know what you're thinking just let us know. We got you covered.

reply

3 points by akkartik 24 days ago | link

😂

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"))
So essentially half of the files in the first Arc release were essentially lib/ files that just hadn't necessitated their own folder yet."

But rereading it now I think I was responding to the contrapositive of what rocketnia said :)

reply

3 points by krapp 24 days ago | link

Is that an emoji?!

reply

2 points by krapp 27 days ago | link

>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

To me it still feels like a kludge for the actual problem, which is a lack of namespaces. Maybe it's time to try out ns.arc?

reply

3 points by rocketnia 27 days ago | link

Right now, the only things ns.arc can import into local scopes are non-macro values. (Or rather, it can import macro values, but it determines what value they have well after the code it's in has been macroexpanded, so you'll just see them as (annotate 'mac ...) values, and calling them will be a function call that fails with an error.)

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
         ...
    ...)
To implement `w/mac` requires changes to the macroexpander in ac.rkt. I don't know how much this will make sense to you, but this is the approach for anyone who wants to take it: It requires a change to the way `ac-call` looks up the macro's value (`ac-macro?`) so that it can look it up from the local scope (the `env` parameter). This in turn means the local scope value `env` needs to be refactored so it's a hash table rather than a list, and then `w/mac` can look it up from that table. The `env` parameter isn't passed into macros, so either `w/mac` would need to be implemented as a special form or we'd need to come up with a way that macros can optionally declare that they want to receive an `env` parameter.

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))
where (bar ...) is a macro call that expands to (foo ...) for some global macro `foo`. This code would now fail.

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.

[1] https://sites.google.com/site/arclanguagewiki/arc-3_1/known-...

reply

3 points by rocketnia 29 days ago | link | parent | on: Separation of concerns

When I saw your change, I liked it. I think it's pretty weird for news.arc to be part of lib/.

I get the impression lib/ was created in Anarki to declutter the root directory, and people weren't sure if news.arc objectively wasn't a library or if they just hadn't thought of how to use it as a library yet, so it went into lib/ and stayed in there like the rest of the less essential .arc files. :-p

reply

3 points by akkartik 29 days ago | link

https://github.com/arclanguage/anarki/commit/fe2c9eb2d6

I think I just thought of the top-level directory as the language, and lib/ as the standard library.

reply

3 points by krapp 29 days ago | link

The dependencies for news (srv.arc, app.arc, html.arc) should be libraries, but they still seem to bake in too many assumptions (in particular, around HTML generation and tables) and interdependencies to be useful as standalone libraries. It's hard to tell where the line is sometimes, and I honestly suspect news and the supporting files were written without considering there should be a line between "library" and "application" at all.

It's also difficult to find documentation on what's in /lib or to know how stable the code is, because no one seems to use most of it.

reply

4 points by akkartik 29 days ago | link

> It's also difficult to find documentation on what's in lib/

Can you give examples? If you give concrete examples we can try to improve matters.

Many libraries have a long header comment up top, like rocketnia's ns.arc.

Anarki comes with online help. Try saying `(help deftem)` at the commandline. Admittedly online help is patchy inside lib/ but make it a habit to check it if you aren't already.

Lastly, it's worth looking inside the CHANGES/ directory for major features.

> ..or to know how stable the code is, because no one seems to use most of it.

If by 'stable' you mean "we shouldn't change it", then nothing is stable, inside or out of the lib/ directory.

If by 'stable' you mean "working as intended", then tests are our proxy for intent. There's tons of tests under lib/ and I run the tests fairly often. If a library doesn't have tests then I have a lot less to say about it.

So "no one seems to use most of it" feels like an exaggeration. Most code under lib/ is constantly being monitored for bitrot.

> The dependencies for news should be libraries, but they still seem to bake in too many assumptions and interdependencies to be useful as standalone libraries.

I think here you're cargo-culting[1] notions of "good practice" without considering their costs. Not everything that other people use is a good idea for Arc. We have a tiny number of users, which makes it better to keep the community in a well-integrated codebase rather than fragment it across several "lines". Interfaces have a tendency to balkanize users on one side or other of them. We don't want that; our tiny community doesn't really benefit from the scaling benefits that interfaces provide.

If and when Arc grows 10x or something, and we have three different sets of html generation libraries, we can think about drawing better lines. Until then I suggest a different "best practice": YAGNI[2]

[1] https://en.wikipedia.org/wiki/Cargo_cult

[2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

reply

2 points by i4cu 29 days ago | link

> We don't want that; our tiny community doesn't really benefit from the scaling benefits that interfaces provide.

Are you sure? After all, these issues are being reported as problematic already [1,2].

[1] http://arclanguage.org/item?id=20490 [2] http://arclanguage.org/item?id=20524 "(cough (body) cough)"

> If and when Arc grows 10x or something...

This could also be a chicken and egg problem. Poor interfaces could be a good enough reason to stay away from Arc.

reply

3 points by akkartik 28 days ago | link

But those are comments from the same person I'm responding to?

Did you perhaps have a similar opinion as well? I certainly recall other people asking for a package manager.

To be clear, what I said is just my opinion, and I should have said "we don't need that" or "it's a bad idea" rather than "we don't want that", which sounds like I'm speaking for others. If a couple of us feel strongly about adding interfaces, you should feel free to do it and see how it goes. If I'm right then you'll eventually realize that it's only serving as bureaucracy. If you do enjoy it then I'll eventually realize that I'm wrong ^_^

reply

3 points by rocketnia 28 days ago | link

I think API boundaries arise naturally from syntax that doesn't fit on one screen. Edits to one piece of code can only be quick and easy if they manage to preserve the assumptions that make the rest of the code work. These assumptions form an API boundary, and at some point it becomes easier not to break the code if that boundary is documented and verified.

Currently, we break up the API boundaries in Anarki by function and by file. We document the function APIs with docstrings, and we write verified documentation for them with (examples ...). We verify the file APIs with "foo.arc.t" unit test files.

If we put more effort into documenting or verifying those boundaries, it would hardly be a big change in how we use the language. We could perhaps add a bunch of "foo.arc.doc" files or something which could compile into introductory guides to what foo.arc has to offer (whereas the docstrings still act as API documentation). And we could perhaps add an alternative to Anarki's (require ...) that would load a library in a mode that faster faster, abiding by an interface declared in a "foo.arc.i" file.

It seems like the most drastic change in philosophy would happen if we broke Anarki apart into sections where if someone's working on one section and discovers they're breaking something in another section, they don't feel like they can fix it themselves.

I suppose that happens whenever people put Arc libraries in their own separate GitHub repos. There are actually a number of those repos out there, including my own (Lathe). Even aw, who was a strong believer in avoiding unnecessary black-box interface boundaries, would still put things in various repositories, and the hackinator tool would collect them into one file tree.

It also happens naturally with poor knowledge sharing. Seems like despite my attempts at explaining ns.arc, I'm still the only one with a very clear idea of how it works and what it's good for, so other people can't necessarily fix it when it breaks.

(Come to think of it, that makes ns.arc a great test case for pulling out an Anarki library into its own repo. That'd save other Anarki maintainers the trouble of having to fix it to keep Anarki's tests running.)

Hmm, even if some libraries are maintained separately from the Anarki repo, Anarki's unit tests can still involve cloning some of those repos and running their tests. If Anarki maintainers frequently break a certain library and want to help maintain it, they can invite its developer to fold it into the Anarki repo. And if the developer wants to keep maintaining it in their own repo, the Anarki project can potentially use a hackinator-style approach to maintain patches that it applies to those libraries' code. We have a lot of options. :)

reply

2 points by akkartik 28 days ago | link

"Hmm, even if some libraries are maintained separately from the Anarki repo, Anarki's unit tests can still involve cloning some of those repos and running their tests. If Anarki maintainers frequently break a certain library and want to help maintain it, they can invite its developer to fold it into the Anarki repo. And if the developer wants to keep maintaining it in their own repo, the Anarki project can potentially use a hackinator-style approach to maintain patches that it applies to those libraries' code. We have a lot of options. :)"

This would be fine. Whether we consider something an API has nothing to do with how we divide code into repositories or sections. Perhaps the key is to know who is calling us. I'd be happy to provide a guarantee to anyone who "registers" their repository with Anarki: if it's easy for me to run your codebase, I'll check it everytime I make a change to Anarki, and ensure that it continues to pass all its tests. If I break an interface, I'll fix all its callers and either push my changes or send the author a PR.

I don't know yet how "registering" would work. But we can start with something informal.

reply

2 points by krapp 27 days ago | link

>I don't know yet how "registering" would work. But we can start with something informal.

Perhaps just the functionality to clone a repo into /lib under the requisite namespaces as a way to include remote dependencies, including pinning to branch and version? No need to "register" anything at first.

reply

2 points by akkartik 28 days ago | link

"It seems like the most drastic change in philosophy would happen if we broke Anarki apart into sections where if someone's working on one section and discovers they're breaking something in another section, they don't feel like they can fix it themselves."

Exactly! It's a huge problem in the programmer world today that we are indisciplined about this distinction. There's a major difference between making a boundary just to make edits easy and "APIs". APIs are basically signalling to most people that they shouldn't be crossing them, and guaranteeing that anybody calling them will be able to upgrade without modifying their code. That is worlds away from just not being able to see everything on a single screen.

Since we use words like "abstraction" and "interface" for both situations, it is easy to cross this line without any awareness that something big and irreversible has changed.

Currently nothing in Anarki is an API. I recommend we be restrained in using that term, and in introducing any APIs.

reply

2 points by rocketnia 27 days ago | link

"There's a major difference between making a boundary just to make edits easy and "APIs"."

Maybe there's a difference somewhere in what we mean by "API." There's a distinction to make, but I wouldn't make that one.

I'm saying APIs arise naturally at boundaries people already feel aren't worth the effort to cross for various plausible reasons. Recognizing an API boundary is a positive thing: Then we can talk about it and help people understand the ways in which it's worth it for them to cross the boundary. But talking about it also makes it something people form as a concept in their mind and form expectations around, so it can become a more imposing boundary that way if we're not careful. We should seek a sweet spot.

The important distinction is that sometimes the reasons people don't cross boundaries are good ones, and sometimes they're baloney.

I think what you and I want to avoid for Anarki is documentation that gives people baloney reasons to think it's not worth it for them to edit the Anarki code.

While we can try to minimize the good reasons that exist, and we can encourage people to try it before they knock it, there's no point in denying that the good reasons sometimes exist.

If you ask me, the reason we have to settle for a "sweet spot" is totally a consequence of the fact that Anarki is made of text. Text loves bureaucracies. Someone sees text, they ask for the Cliff's Notes, and then someone has to maintain the Cliff's Notes.... So you've gotta get rid of the text, or you'll have an API boundary.

Programming without bureaucracy would be like having a conversation without writing it down. I believe in this. I think conversational programming is exactly what we can do to simplify the situation of programming in the world, and Era's my name for that project, but Anarki is a more traditional language, and it takes a more traditional trajectory into APIs.

Our documentation can try to convey "This is all subject to change! Edit it yourself, open an issue, or drop by on Arc Forum for some help! We count on contributions like yours to make Anarki a good language. Since others are welcome to do the same thing, watch out for changes in this space." We could put an "unstable, just like everything else here" tag on the corner of every single documentation entry.

Anarki is far from the only unstable codebase people have ever seen. Being a Node.js user, my code has regularly been broken by upgrades, and Node.js isn't even a version 0.0.x project. I think only a certain number of people would mind if Anarki promised stability and then couldn't deliver on it, let alone mind if Anarki made it clear in the API documentation that there was nothing stable to find there in the first place.

---

"guaranteeing that anybody calling them will be able to upgrade without modifying their code"

You know me well. I probably said that pretty insistently in the past. It's something obsess over and a major requirement I have for code I write (and hence all its dependencies), even though things like Node.js show me it's not a current norm in software.

It's the 100-year language ideal. Spend a lot of time to get the axioms just right, and then the language is stable and nobody ever feels the need to change it since there's nothing to improve on! In 100 years, Arc is supposed to be the language that's too perfect to be anything but the stablest language around.

I still believe in that ideal, but not in quite the same way. People will come up with a reason to promote their alternative language, even if it's just to say they're different than their parents. But I do believe languages can be designed to be more compatible with their forks, even to the point where it's difficult to say where one language ends and another begins. The resulting unified "ecosystem of all languages" could have a much simpler design than the "ecosystem of all languages" we currently have.

That's also part of my approach in Era. I make decisions in those codebases with the goal of simplifying the ecosystem of all languages.

I don't think this is something I would pursue in Anarki. Arc was very far from the the 100-year language upon release, it was unstable, and it seems like Anarki has pretty much been maintained by and for people who could embrace that part of Arc's journey.

reply

More