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

I use Vim as you know, but hopefully somebody else here uses Emacs.

Do you have any Arc-specific configuration in your .emacs? It may be helpful to share that in case somebody spots something wrong with it.


3 points by gruseom 22 days ago | link

Pretty simple:

  (push '("\\.arc$" . lisp-mode) auto-mode-alist)
  (modify-coding-system-alist 'file "\\.arc$" 'utf-8)
There's some other stuff related to running a REPL but I'm pretty sure it's unrelated.


1 point by akkartik 22 days ago | link

Thanks! Sorry I can't be more help, but I can indeed reproduce your issue.


This later post by the author may be relevant:

Though it's hard once again to understand. When are two nodes coincident? By definition you can only have one character in one place on the screen. Is he talking about indentation, that the same level of indentation can mean different things? That seems true of ETN as well, from what I can tell.

The pencil scratchings on the screenshots don't help either.


1 point by breck 25 days ago | link

Sorry, the lines in the geometric mapping of the source code are coincident. In drawing B) in the visual proof, the edges which connect the child nodes to their parents intersect and/or are coincident. So when you put Lisp source code onto graph paper, and draw boxes around the nodes, and line segments for edges, it shows why Lisp source is not a geometric language (I define a geometric language as one where there are no intersecting or coincident line segments).

Now, figure A) shows the same Lisp code, formatted differently, in a way that is a geometric language. But as you can see, that code is standard TN/ETN. Or perhaps another way to put it is ETNs are just Lisps with a whitespace syntax and no parentheses. Another reader on HN pointed me to I expressions (, which I hadn't seen before and is 90% of the way there to TN and ETNs. The creator of I-Expressions have communicated briefly over email now and are going to be talking soon.

Anyway, perhaps another term for Tree Notation/ETNs is "Geometric Lisp", or "2-Dimensional Lisp". I'm not wedded to the terms TN/ETNs, although I do think it's better to have new terms, because I think these will come to dominate the usage of Lisp.

Still working on more updates and evidence on why I think these will be so big.


HN discussion on this post:

I thought all the emphasis of how great it was made it harder for people to understand _what_ "it" was. Probably a good idea to keep an initial post like this matter-of-fact. Motivate it with just one simple strength that's easiest to communicate. Describe the broader context and implications in a separate post, later, after people understand what it is.


2 points by breck 25 days ago | link

I totally agree. Although perhaps I wouldn't have gotten as much feedback had I taken a more modest approach? Hard to say. I still haven't done a good job communicating the benefits of ETNs yet, stemming from their 2D/geometric nature. Almost got version 1.1 of Ohayo done which makes another step toward that.


5 points by akkartik 25 days ago | link

That motivation makes sense. Bear in mind, though, that the "less modest" approach has a limited amount of gas. It will stop working at some point.

I can relate with having these questions and considering the different strategies as well. If you really think that this is going to be your life's work, it's reasonable to burn some 'reputation' to get the word out. However, I've often been wrong before. Now I tend to err on the side of playing a long game.

Over time I've gained respect for the essential wisdom of this quote:

"We knew that Google was going to get better every single day as we worked on it, and we knew that sooner or later everyone was going to try it. So our feeling was that the later you tried it, the better it was for us because we’d make a better impression with better technology. So we were never in a big hurry to get you to use it today. Tomorrow would be better." -- Sergey Brin, as retold by Seth Godin in "The Dip"

Applicable to ideas like here just as much as products.


2 points by breck 24 days ago | link

Wow, what a quote! That's exactly how I feel about Ohayo. That seems like a better approach--not to be in a big hurry to get people to use it today. Thank you akkartik. Really appreciate that advice!

My only concern pre-launch and announcement, was that I was going to get hit by a bus and the world would have to wait longer for someone else to stumble upon (and popularize) TN and ETNs. Now that it's out there and a few thousand people have seen it, I can take this more sensible approach. Fantastic advice.

Btw, just pushed version 1.1.0 if anyone's interested.

UX still needs work, but I rushed adding a "3D block" to the flow language, (using the vis.js library), so you can start to see what "3D" code looks like.

I need to rev that a bit (I see some immediate bugs) but gives the basic idea and I have to run out for a little while.


I meant to submit this post when I first saw it, but forgot :)


2 points by akkartik 56 days ago | link | parent | on: Nice work, malisper!

I don't think we can :) This forum seems slow enough that I figured we had time to discuss something off-topic.


3 points by jsgrahamus 56 days ago | link

Well, that is certainly true; although I was surprised at the recent post where all those other folks showed up.


3 points by jsgrahamus 56 days ago | link


3 points by akkartik 58 days ago | link | parent | on: At-sign in string

Yes, the atstrings feature is turned off by default in Arc 3.1 (and also in Anarki's official/stable branches). I think I'll turn off the default in Anarki as well, and just let news.arc continue to make use of it.

Edit 1 hour later: This is now done. Turns out Anarki never meant to turn on atstrings by default. This was a side effect of loading news.arc by default (mea culpa). I've changed things so we load news.arc by default but only use atstrings in news.arc by default. Keep an eye out for subtle bugs introduced by atstrings being turned off when functions in news.arc are called. If we see any I'll probably take out the ability to turn it on and off and just decide to keep it everywhere or take it out entirely.


5 points by akkartik 59 days ago | link | parent | on: How many people still lurk here?

Great idea, mikhail. Thanks for doing this. I now know of two readers that I wasn't at all aware of before! ^_^


1. Oh, the clean implementation of classic Lambda Calculus syntax is awesome.

2. Your string interpolation implementation is just begging for an injection attack proof of concept :)

3. Why bother with continuations?!! Them's fighting words :)


4 points by conanite 66 days ago | link

1. Thank you! I figured arc could have gone a lot further with special-syntax, by making it configurable inside arc code.

2. this "open source" has had only two eyeballs on it so far ... attacks welcome :)

3. The execution stack is entirely plagiarised from rainbow so it should not be hard to re-implement continuations in the same manner ... the need hasn't arisen yet though ...


3 points by akkartik 67 days ago | link | parent | on: 2D syntax in Racket

Oh, this is cute.


3 points by rocketnia 67 days ago | link

I don't know if I'd ever want to use this 2D syntax directly, but I'll probably "use" it as a thought experiment for non-hierarchical syntaxes, along with cellular automata and spreadsheets. :)

Can you imagine an 'unquote-splicing operation for this tabuleau syntax? Between lists, 'unquote-splicing can insert any list into any other, but the cells of these tables have externally imposed sizes and shapes, so for an 'unquote-splicing in a table (if we wanted one at all), we'd probably want to enforce that the sizes and shapes match up in a way that makes sense. What might make more sense is to do 'unquote-splicing in a full row or column at once, because at least we get one dimension of freedom that way. If the splice takes up a full row, then it can splice in any number of rows (of any height) to that location.

I'm probably a little obsessed with quasiquotation lately. I've been trying to write an implementation of a macro system where the meanings of notations like 'unquote, 'unquote-splicing, and parentheses themselves can be treated as user-defined macros, and where syntax-bound concepts like source locations and syntax highlighting are mostly managed automatically in the macroexpander rather than something every macro must deal with (except for the macros that do something unusual with them).


Welcome back, conanite! I was coincidentally just thinking about you yesterday when I ran across your bug report at Too bad that bug is still open in both Arc 3.1 and Anarki. I think I will try to fix it now that I've spotted it.