Arc Forumnew | comments | leaders | submitlogin
3 points by rocketnia 4011 days ago | link | parent

It sounds like what you like to see are s-expressions that fit these patterns:

  homogeneous list of any number of X
  fixed-length heterogeneous list of (X Y Z)
  expression... which fits one of these patterns:
    atom
    call to X with args Y
Arc and Clojure make this more complicated by adding more cases, and I'll highlight Clojure's cases here:

  map from X to Y
  homogeneous vector of any number of X
  vector alternating between X and Y, with no excess (like a map)
  call to 'cond with args alternating between (expression) and
    (expression), with no excess
  call to 'case with args starting with (expression), followed by
    alternations between (anything) and (expression), perhaps with
    (expression) as excess
  function body which might begin with a docstring and/or a metadata map
  destructuring syntaxes
  ...
Between Arc and Clojure, I'm pretty sure Arc is intrinsically harder to auto-indent, because it doesn't distinguish between different cases using different kinds of brackets. Racket's a great example of what I mean; parens are used when the subsequent lines should be indented like function arguments, and square brackets are used otherwise.

For structured editing -- what you pursue -- we probably want even more static structure than what we want for auto-indentation.

I don't want to prod you to spend your time writing tools for niche languages or designing niche languages of your own, if that's not what you already want to do, but I'd like to ask what kinds of hypothetical languages you would like best....

Would you be eager to work with a lisp-like language where the AST has a few built-in notions of homogeneous lists, heterogeneous tuples, function calls, etc.? For instance, Lark defines an alternative to s-expressions that's more tailored to the ways the syntax is actually used (https://github.com/munificent/lark).

On the other hand, would you be eager to work with a language where the AST has an endless variety of possible cases, which can be extended by any programmer who wants to write an editor widget? Racket does something related to this, because it has an expressive pattern language for writing macros, and macros written this way generate good parse errors automatically (http://docs.racket-lang.org/syntax/Parsing_Syntax.html).

Personally, I've been kinda dreaming about both of these approaches to structured editing for a long time, but I'm still working on the run-time and link-time semantics of my language designs, so I've been unambitious when it comes to editing-time semantics. :)