Arc Forumnew | comments | leaders | submitlogin

Thanks for doing this. in particular really helps understand where you're going with this.

I've brought up an idea a couple of times here: If (quasiquote ...) and (unquote ...) match up and nest like parentheses, then what if we generalize that analogy to higher dimensions?

After years of going back to the drawing board over and over, I finally have a working, reasonably elegant (if slow), and most importantly, documented implementation of hypersnippets and hyperbrackets in Punctaffy. I'm really excited to be able to give examples of how these can be used for things other than quasiquotation.

The "Introduction to Punctaffy" section introduces the idea of degree-2 hyperbrackets. There are precious few examples where degree-3 hyperbrackets would come in handy (much less higher-degree ones), but the infrastructure is working for those as well.

There are still a number of directions I hope Punctaffy will take from here, but it's finally past the "sorry, I haven't written up good documentation, so I don't know how to explain" stage that it's been stuck in for quite a while. :) If you're interested, I've written up some in-depth discussion of those future ideas in the "Potential Applications" sections. One of those (the interaction between 'unsyntax and ellipses in the Racket syntax template DSL) would even be a practical application of degree-3 hyperbrackets.

This documentation totals to something like 30,000 words. Most of those words are the reference documentation of Punctaffy's hypersnippet-shaped data structures (hypertees and hypernests). Don't worry about reading through all of it, but I'd be very happy to see if anyone could make it through the introduction. After 4 years of not having much to show people, I really hope that introduction will help. :)

I would also recommend looking into moving to a GitLab repository; they offer CI and many other features for free.

I also generally like them more than Github for some reason, (maybe the fact that they're more open source friendly?), but that's just me.

1 point by akkartik 37 days ago | link | parent | on: Does Arc have a language reference?

Indeed, that looks wonderful!

Do you have any open questions?

2 points by codefined 38 days ago | link | parent | on: Does Arc have a language reference?

Started with the tutorial to understand basis of language, then reading `arc.arc` helped find out about new functions. If you're also starting out, have found making a cheat sheet to be incredibly helpful with quickly finding out what certain things do[0].


Oh, I see, you're right. I checked that settings page, but the big blank "social preview" image made me think I was at the end of the page, so I forgot I could scroll down. That's interesting.

Ok thanks.

Also, hey everybody, there's a project tab for the forum on the repo. Feel free to add to it, or whatever.

I'll get around to working on it again sooner or later.

Oh sorry, I cleaned up some tabs because I saw tabs overflowing into a menu on the right. I'll restore it.

This is a bit off topic but what happened to the projects tab for the repo? I had a vaguely organized project for the forum up there.

>I think it's also not super onerous to require people to manually update the docs when making changes.

It really isn't. I need to add documentation for a lot of things.

A few years ago GitHub added the ability to specify a branch for a project. See the GitHub pages section of

I have a site at but it's served directly from the main branch. There's no gh-pages branch at

I appreciate your frankness, lol. Anarki maintenance happens whenever we feel like it. :-p I have been feeling an inkling of an Arc urge lately, hence this post, but I have other priorities right now that this is basically procrastination from.

What do you mean by getting GitHub to build docs from the trunk branch? That's what that part of the CI script is there to simulate; I think there's still no actual way to configure GitHub Pages to build from anything but a `gh-pages` branch or a `<username>` repository.

Thanks for raising these questions! A few random thoughts that immediately occur to me:

My general bias is that CI infrastructure is uneconomic for this project[1], given the amount of effort I'm willing to put into Anarki at this point. But I have absolutely no objection to others continuing to maintain it.

I'd be fine with having a more complex set of instructions for contributors than newcomers. I'm totally willing to perform those commands for myself when I make changes to Anarki.

I'd also be ok with undoing some of this complexity if you want to do that, though I don't mean to push for that in any way.

I think it's also not super onerous to require people to manually update the docs when making changes. That way we can get rid of gh-pages, and configure Github to just rebuild docs from the trunk branch. That eliminates one use case for CI.

Your final proposal is also fine, though as you mentioned someone would have to implement it.. :)

[1] As context, I also plan to remove CI from the project I _do_ actively work on.

HN discussion:
2 points by old-lie 82 days ago | link | parent | on: [META] Finding My Old Posts

Having located the old account's link, it looks like I must point-and-click my way along, gently up the stream. :D

Did you build all these dialogue boxes yourself too? Very snazzy. :D

New 2-minute video: support for strings, arrays and file handles that starts to give this the feel of a shell language.

2 points by Mitranim 135 days ago | link | parent | on: Observations on homoiconicity

I might check it out later, but is there a gist in text form somewhere?
1 point by akkartik 136 days ago | link | parent | on: Observations on homoiconicity

You might enjoy this talk which mentions this equation:

    code = AST + formatting/comments
2 points by Mitranim 137 days ago | link | parent | on: Observations on homoiconicity

Should clarify something (follow-up to previous reply, see below or above).

Most macros don't want to deal with whitespace and comments. We also might want to _not let_ them, otherwise people will start using comments as code, like in Ruby. Macros just want expressions. So, we would define a second level of the AST and perform a second pass.

For the same base notation, there may be multiple languages defined in terms of it. If such a language has any form of prefix or infix, or uses the `outside_parens()` calling convention, the second pass would have to group nodes into expressions, in ways specific to that language. Furthermore, it should be addled with metadata about packages, types, and so on. The resulting AST is compiled, fed to macros, etc.

2 points by Mitranim 137 days ago | link | parent | on: Observations on homoiconicity

> Why do you care about emitting exactly the code that was parsed? What new apps does it enable?

Got a `gofmt` addiction, can't go back. Auto-formatting should ship with every language.

Briefly skimmed the Go implementation, and you seem to be right: it seems to lose whitespace and enforce its own formatting.

> Are you aware of any languages that perfectly reproduce input layout?

For now just my own. [1] The language isn't real yet, and might never be realized, but it has a base data notation (very Lisp-like), a parser, and I just started writing a formatter. Because the AST for the data notation preserves whitespace and comments, the formatter can print the code _exactly_ as is. This has interesting repercussions.

For a fully-implemented formatter for a fully-defined language, you wouldn't need whitespace; see Go. However, being able to print everything back means your formatter is usable from the start. It can support one or two simple rules, making only minor modifications, but you can use it on real code right away. Furthermore, this means we'll _always_ be able to choose which rules to enable or disable, which can be handy if the family of languages described in terms of this notation has different formatting preferences. I actually want the formatter shipped with the language, like `gofmt`, to be non-configurable, but this still seems like a useful quality.


1 point by akkartik 137 days ago | link | parent | on: Observations on homoiconicity

Thanks for sharing! It's been a while since I thought about this, but my conclusion a few years ago[1][2] was that homoiconicity was an ill-posed idea. A language only really needs two properties to make macros convenient:

* Everything is an expression, and

* Unambiguous parens.




That said:

* I like symbols. Having symbols and strings in a Lisp doesn't seem any more weird than having variables and string literals in Algol or Java. Even if I _could_ use one in place of the other, it seems useful to separate symbols as part of the program from strings as part of the environment/domain/data model. You could implement one with the other, sure, but I wouldn't question anyone who chose not to. After all, every attempt I've seen to support spaces in symbols has been quite ugly.

* Your other points seem to be in the context of building tools like code formatters where the output will be seen by humans. That's not really the context for Lisp macros. I haven't really thought much about how useful they would be. Since I believe in macros, I can probably be persuaded. So that might be an interesting post to write. Why do you care about emitting exactly the code that was parsed? What new apps does it enable?

Are you aware of any languages that perfectly reproduce input layout? Even Go supports gofmt only by tightly constraining how programs "should" be indented, and only outputting that layout.

2 points by Mitranim 138 days ago | link | parent | on: Observations on homoiconicity

While Lisp-style homoiconicity can simplify the initial implementation of a dynamic language, there are tradeoffs; the post lists a few.

New 2-minute video: defining functions in this postfix language.

Very interesting. This would have made learning Forth easier!

You're right that in general any such example can be refactored to reduce stack operations. That's even a fun game for many Forth programmers to play. (We lispers have our own equivalents.) But it usually makes the code less comprehensible, in my experience.

Yes, that is definitely simpler, although the formula is more esoteric. At least, for me, it triggers the "I was taught this in school and haven't used it since" filter.

Maybe something like:

  total-price cost-per-item number-of-items shipping-cost-per-item rush-cost = cost-per-item number-of-items * shipping-cost-per-item number-of-items * + rush-cost +
This doesn't seem super great; it could be refactored to use each thing once, but it's late and I can't think of any better example.

Yeah, some other polynomial might be a better example. The Pythagorean formula has a clean separation when it comes to which args each term uses. How about the roots of a quadratic equation when you start out with a, b and c on the stack?


Is it that you're trying to reduce stack juggling? That's hard to understand from simple examples (that you need to have to grok the syntax). Maybe compare something like finding the hypotenuse of a right triangle given the two other sides. Without naming arguments, you'd have to do something like:

  hypot = dup * swap dup * + sqrt
But with named arguments:

  hypot x y = x x * y y * + sqrt
That seems a little easier to read, but even the original isn't so complicated. Is there an example that makes it more obvious why it's better? Even your `square` example is more tokens than with stack juggling (without arguments, `square = dup *` is just four tokens, compared to six with named arguments). I'd say the with-arguments one is easier to read, but I've far less familiar with stack-based postfix programming.