
2D Syntax - mr_tyzic
https://docs.racket-lang.org/2d/index.html
======
glangdale
I just love this. For some reason, our ways of specifying what we want a
computer to do (I don't want to say 'language') remain mired the same
territory we started in with punched cards (which I actually got to use as a
10 year old, which was fun).

I'm not sure if this particular cut is the right idea, but it's good to see
experimentation. A bias I have here is that I think these ideas should be
rigorously separated from the concept that some sort of WYSIWYG editor will
allow non-programmers to code.

~~~
ilaksh
> WYSIWYG...non-programmers

That touches on the reason these type of ideas haven't gone further.
Programming is definitionally limited to cryptic text. Anything that deviates
from that, especially if it makes it non-cryptic or easy, is no longer a
programming tool; it becomes a tool for lowly users. This detracts from the
identity of programmers because that is tied to producing and consuming
cryptic text.

~~~
glangdale
I don't agree. I think there are two things conflated here and trying to
unpick them both in the same system is a recipe for disaster. The two things
are: (1) programming should be an exercise in linear-text 1970s ASCII art
(arguably) and (2) programming should be easy and the hard decisions
programmers have to make are all just intentional obfuscation to keep their
jobs (not true).

I think a system build along lines to violate assumption #1 will fail if it
has the goal of making assumption #2 go away as well. The complexity of many
things we manage in text will either appear somewhere else, or bubble up in
even worse ways (missing functionality or a system that is broken by design).
I would really like to see work that is focused on attacking assumption #1.
I'm not going to try to dictate that no-one should work on #2, I just think
it's been tried without much success so many times.

~~~
mcbits
Looking at it from the other direction, we can start with the premise that
applications like Excel, Max, Nuke, and Blender are already visual DSLs. The
users are "programmers" of a sort, but not "coders" because they don't type
code. Then the question is whether such a DSL can be extended to general-
purpose computation with any advantages over text-based coding languages.

~~~
stuaxo
None of these integrate very well with a programmers existing tools, if they
did I am sure programmers wouldn't mind so much.

~~~
lallysingh
Huh? Excel talks .Net, Blender's a python app. I remember manipulating an
excel table in vb 20+ years ago.

------
nprescott
Very neat, I really appreciate the Racket community's willingness to
experiment with syntax.

Looking at the examples reminds me of Julian Noble's "Elegant Finite State
Machine" in Forth[0], which takes a different approach to the same problem of
creating a language to better specify a problem (in both cases graphically).

[0]:
[http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm....](http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html)

------
hyperion2010
It looks like this (e.g. `#2dcond`) implements a way to directly embed other
languages in a racket file [0] and avoids the problems encountered when trying
to do it using the `#reader` syntax [1] in a source file. Essentially letting
you have multiple readtables in a file (probably not nestable though). I could
be wrong about this (need to look more carefully when I have more time), but
nonetheless could allow direct embedding of completely alternate syntax with
the right setup.

[0]
[https://github.com/racket/2d/blob/master/2d-lib/private/read...](https://github.com/racket/2d/blob/master/2d-lib/private/readtable.rkt)
[1] [https://docs.racket-lang.org/guide/hash-reader.html](https://docs.racket-
lang.org/guide/hash-reader.html)

~~~
gcr
This seems similar to the way the at-exp language is implemented.

at-exp adds support for S-expressions based on braces, and is the foundation
of the Scribble markup language.

------
ziotom78
I find this extremely interesting! In the last weeks one of my colleagues had
to work to some legacy application that was developed using National
Instrument's LabView [1]. For those who do not know it, it is a visual
language to develop interfaces to scientific instruments. Everything is done
visually, including «if»s and «for» loops.

My colleague, which has large experience with languages like C# and Assembly,
is extremely frustrated by this way of working. Everything must be done using
a mouse, and even the simplest tasks require some thought in order to be
implemented properly. (Although I must say that he praises LabView's hardware
support and its Visual Basic-like easiness in developing GUIs.)

I find Racket's 2D syntax to be far more promising than LabView's approach:

1\. You can code it using a text editor: unlike LabView, no mouse is required;

2\. Only a few classes of statements are affected by this (LabView forces you
to do _everything_ visually, even function definitions and mathematical
operations);

3\. You use this feature only if you think it helps; otherwise, plain text
syntax is always available.

As a side note, I would like to give kudos to the Racket developers for this
kind of gems. Racket really seems to be a language which makes language
experiments easy to implement and try!

[1] [http://www.ni.com/en-us/shop/labview.html](http://www.ni.com/en-
us/shop/labview.html)

------
kazinator
I have some reservations about how this is designed.

All we need are columns labeled with conditions. We don't need rows. And the
matrix can just have true/false/don't-care entries, with code assigned to
rows.

Concretely, say we have these conditions:

    
    
       (> x y)  (stringp foo) (oddp n)
    

Right? Okay, so now we can identify the combinations of these and assign them
to code like this:

    
    
       (> x y)  (stringp foo) (oddp n)
          #t                     #t       (whatever)
                    #t           #t       (other-thing)
          #t        #f                    (etc)
    

There could be a way to mark some of the rows as having "fall through"
behavior. If they match, the expression is evaluated (for its side effects,
obviously), but then subsequent rows can still match.

This could be worked into a straightforward S-exp syntax without any
diagramming shennanigans:

    
    
       (table-cond
          (> x y) (stringp foo) (oddp n)
          #t      ()            #t       (let [...]
                                           (whatever))
          ()      #t            #t       (other-thing)
          #t      #f            ()       (etc))
    

Here, don't cares are denoted using (). Something else could be chosen.

A #f entry means "must be explicitly false". A blank column entry is a "don't
care"; that condition is not taken into account for that row.

~~~
porges
At that point aren't you just doing normal Racket pattern matching?

    
    
        (match
          (list (> x y) (stringp foo) (oddp n))
          [(list #t     _             #t      ) (whatever)]
          [(list _      #t            _       ) (other-thing)]
          [(list #t     #f            _       ) (etc)])
    

... or is that the joke :)

~~~
kazinator
There you go. That just needs a very light syntactic sugar and it's there. The
elements of the lists are constants, so you want to use a literal, and the
quoting of that can all be hidden. The (list ...) around the incoming
expressions can be trivially hidden also.

The one thing I suspect _match_ probably doesn't do is feature a fall-through
mechanism that I alluded to; say we want (other-thing) for its side-effect,
and then still evaluate (etc) if (> x y).

(Under no circumstances do we want fall-through to be opt-out, like in the C
switch statement with its forgotten break bugs, but opt-in.)

Also, this mechanism could be optimized. Since the pattern lists must only
contain #t, #f and _, they can be validated to contain nothing else.
Accordingly, they can be arithmetically encoded (two bits per symbol), and
subject to a numeric dispatch. '(#f _ #t) is a six bit number; '(_ #f #f) is
another six-bit number and so on. Arguably, _match_ itself could do that, but
it's rather specialized.

------
jacobparker
Nicely done!

Different but similar joke for C++:
[http://www.eelis.net/C++/analogliterals.xhtml](http://www.eelis.net/C++/analogliterals.xhtml)

~~~
fizixer
I assume you didn't mean the Racket implementation being a joke (only the C++
one).

Personally, the Racket idea is good except for the hassle of typing in the
borders (emacs-orgmode could help with that though).

~~~
gus_massa
To confirm that it's not only a joke, you can try the examples online in
PasteRack
[http://pasterack.org/pastes/72418](http://pasterack.org/pastes/72418)

~~~
Someone
That it compiles and does what the page says doesn’t rule out that it is
intended as a joke. The C++ code compiles and runs, too.

------
hota_mazi
While I appreciate and respect Racket's willingness to experiment and
innovate, I'm a bit puzzled by this.

Tables are neat to read but pretty annoying to write, especially in ASCII
form. It's true that code is read much more often than written, but still, I
wonder how useful this really is.

~~~
exDM69
> Tables are neat to read but pretty annoying to write, especially in ASCII
> form

They sure are annoying to write in a text editor, but the article does mention
built-in support for them in the Dr. Racket IDE/repl.

Dr. Racket does seem like a very nice educational environment to learn some
fundamentals of programming. In addition to text it can show images and
tables, etc.

I'm under the impression that it is used in some universities in conjunction
with SICP or HTDP.

------
fao_
The reason why I think that this will not thrive, as other projects have not
thrived, is because (at least initially) it adds to the mental burden.
Scanning a cond for me is almost instantaneous. It took me a couple of very
long seconds for me to figure out what was happening within that table, and
even though I recognized it as a truth table, it was not easy to read. The
information was too separate on screen to easily compare.

I think that were programming initially presented as such, this would not be a
problem, but I expect that many developers are so finely attuned and
specialized to text that other methods will not take off purely because of the
learning curve.

~~~
ppog
"Scanning a cond for me is almost instantaneous." This is a very subjective
concern though. Consider the subtype example. For me, reading that 3x3 table,
especially with the grouping of blocks, was a lot easier than mentally parsing
a big pile of 'and/or' expressions, or nested switches, etc. And my impression
is that a lot of programmers _do_ initially visualise some parts of their work
as tables or diagrams.

Our _tools_ on the other hand _are_ indeed 'so finely attuned and specialised
to text' that other methods of representation have and will struggle to get
traction...

~~~
asdfaoeu
I feel like most of these complicated if else statements can generally be
written much better for example.

    
    
        SUPERTYPES = {'Real': ['Integer'],
                      'Complex': ['Real'],
                      'Integer': []}
                
        def is_subtype(a, b):
            if a == b:
                return True
            return any(is_subtype(x, b) for x in SUPERTYPES[a])
    

Which better expresses the intention of the code and is more flexible.

------
sharpercoder
Tables are generally a very good idea for languages. SpecFlow/cucumber as most
notable example, but I can see others benefitting greatly as well.

------
b123400
It reminds me of Funciton,
[https://esolangs.org/wiki/Funciton](https://esolangs.org/wiki/Funciton)

------
ooqr
Surprisingly exactly what the title makes it sound like. Very cool!

------
igravious
Nobody has mentioned the dependently type prog-lang Epigram† yet?

“Epigram uses a two-dimensional, natural deduction style syntax, with a LaTeX
version and an ASCII version. Here are some examples from The Epigram
Tutorial:

Examples

The natural numbers

The following declaration defines the natural numbers:”

    
    
             (         !       (          !   (  n : Nat  !
        data !---------! where !----------! ; !-----------!
             ! Nat : * )       !zero : Nat)   !suc n : Nat)
    

“The declaration says that Nat is a type with kind * (i.e., it is a simple
type) and two constructors: zero and suc. The constructor suc takes a single
Nat argument and returns a Nat. This is equivalent to the Haskell declaration
"data Nat = Zero | Suc Nat".”

Project lives here:
[https://code.google.com/archive/p/epigram/](https://code.google.com/archive/p/epigram/)
and the last commit on
[https://github.com/mietek/epigram2](https://github.com/mietek/epigram2) is
five years ago which leads me to believe that the project is abandon-ware.

†
[https://en.wikipedia.org/wiki/Epigram_(programming_language)](https://en.wikipedia.org/wiki/Epigram_\(programming_language\))

------
oh_sigh
What editor do racketeers commonly use? I like the idea, but this seems like a
burden for code editing in most normal editors except for perhaps emacs
picture mode.

~~~
dragonwriter
It's good for reading (certain) code. Without the syntax actually be
functional, there's no reason to build editor support for it; editor support
that makes it cobvenient to write should be expected to be a trailing, rather
than leading, feature.

EDIT: incidentally, the documentation for the syntax also refers to the built-
in support for it in DrRacket.

~~~
oh_sigh
Makes sense - but I should note that this syntax is from at least Mar 2016[1],
so I'm guessing people haven't been clamoring for editor support if it's not
available.

[1][https://web.archive.org/web/20160316083925/https://docs.rack...](https://web.archive.org/web/20160316083925/https://docs.racket-
lang.org/2d/index.html)

------
joshlemer
If anyone wants to see some ascii-art in Scala, they just need to look at the
Akka Streams-graph api
([http://doc.akka.io/docs/akka/current/scala/stream/stream-
com...](http://doc.akka.io/docs/akka/current/scala/stream/stream-
composition.html#composing-complex-systems))

------
agumonkey
Reminds me (again) of Jonathan Edwards research. He did many editors with
tables as first class so that you can avoid boolean nestings, and simplify
verification / closure of your boolean mappings.

He published a video, sadly in flash [http://www.subtext-
lang.org/subtext2.html](http://www.subtext-lang.org/subtext2.html)

Here's an article about "schematic tables"
[http://aigamedev.com/open/review/schematic-table-
conditional...](http://aigamedev.com/open/review/schematic-table-
conditionals/)

------
vidarh
I love attempts at visual programming. As a kid I used to pour over the then-
fashionable ads for CASE (Compater-Aided Software-Engineering) tools in DDJ
and elsewhere and imagined them to do far more than they actually did... Also
attempts like Amiga Vision [1]

One of the software engineers I like to go a bit fanboy-ish about is Wouter
van Oortmerssen, who I first got familiar with because of Amiga E, but who has
a number of interesting language experiments [2], one of which includes a
visual language named Aardappel [3] that also used to fascinate me.

There are a number of problems with these that have proven incredibly hard to
solve (that this Racket example does tolerably well on, probably because it
doesn't go very far):

1\. Reproduction. Note how the Amiga Vision example is presented as a video -
there is not even a simple way of representing a program in screenshots, like
what you see for the examples of Aardappel, which at least has a linear, 2D
representation. That made Amiga Vision work as a tool, but totally fail as a
language. This is even a problem for more conventional languages on the
fringe, like APL, which uses extra symbols that most people won't know how to
type. The Racket example does much better in that it can be reproduced in
normal text easily.

2\. Communication. We talk (and write) about code all the time. Turns out it's
really hard to effectively communicate about code if you can't read it out
loud easily, or if drawing is necessary to communicate the concepts.
Ironically, if you can't read the code out easily, it becomes hard for people
to visualise it too, even if the original representation is entirely visual.
This example does ok in that respect - communicating a grid is on the easier
end of the spectrum.

3\. Tools. If it needs special tools for you to be effective, it's a non-
starter. This Racket example is right on the fringes of that. You could do it,
but it might get tedious to draw without tooling (be it macros or more). On
the other hand the "tool" you'd need to be effective is limited enough that
you could probably implement it as macros for most decent editors.

I spent years experimenting with ways around these, and the "best" I achieved
was a few principles to make it easier to design around those constraints:

A visual language needs a concise, readable textual representation. You need
to be able to round-trip between the textual representation and whatever
visual representation you prefer. This is a severe limitation - it's easy to
create a textual representation (I had prototypes serialising to XML; my
excuse is it was at the height of the XML hype train; I'm glad I gave that
up), but far easier to make one that is readable enough, as people need to be
able to use it as a "fallback" when visual tools are unavailable, or in
contexts where they don't work (e.g. imagine trying to read diffs on Github
while your new language is fringe enough for Github to have no interest in
writing custom code to visualise it; which also brings up the issue of
ensuring the language can easily be diffed).

To do that in a way people will be willing to work with, I think you need to
specify the language down to how comments "attaches" to language constructs,
because you'll need to be able to "round-trip" comments between a visual and
textual representation reliably.

It also needs to be transparent how the visual representation maps to the
textual representation in all other aspects, so that you can pick one or the
other and switch between the two reasonably seamlessly, so that you are able
to edit the code when you do not have access to the visual tool, without
surprises. This makes e.g. storing additional information, such as e.g.
allowing manual tweaks to visual layout that'd require lots of state in the
textual representation that people can't easily visualise very tricky.

Ideally, a visual tool like this will not be language specific (or programming
specific) - one of the challenges we face with visual programming, or even
languages like APL that uses extra symbols, is that the communications aspect
is hard if we can not e.g. quickly outline a piece of code in an e-mail, for
example.

While having a purely textual representation would help with that, it's a
crutch. To "fix" that, we need better ways of embedding augmented, not-purely-
textual content in text without resorting to images. But that in itself is an
incredibly hard problem, to the extent that e.g. vector graphics supports in
terminals was largely "forgotten" for many years before people started
experimenting with it again, and it's still an oddity that you can't depend on
being supported.

Note that the one successful example in visually augmenting programming
languages over the last 20-30 years, has been a success not by changing the
languages, but by working within these constraints and partially extracting
visual cues by incremental parsing: syntax highlighting.

I think that is a lesson for visual language experiments - even if you change
or design a language with visual programming in mind, it needs to be sort-of
like syntax highlighting, in that all the necessary semantic information is
there even when tool support is stripped away. We can try to improve the
tools, but then we need to lift the entire toolchain starting with basic
terminal applications.

[1]
[https://www.youtube.com/watch?v=u7KIZQzYSls](https://www.youtube.com/watch?v=u7KIZQzYSls)

[2] [http://strlen.com/programming-languages/](http://strlen.com/programming-
languages/)

[3] [http://strlen.com/aardappel-language/](http://strlen.com/aardappel-
language/)

------
kovek
I wonder how nesting of tables would be like? I guess if you had function
calls inside, it would look nicer than drawing a table inside a table.

------
niuzeta
Okay. I love this and everything about this.

> This notation works in two stages: reading, and parsing (just as in Racket
> in general). The reading stage converts anything that begins with #2d into a
> parenthesized expression (possibly signaling errors if the ═ and ║ and ╬
> characters do not line up in the right places).

I'm cracking up, oh my god.

------
lispm
Adding tabular display to Lisp is useful, IMHO. I was thinking about using
something similar, but mostly where code looks like data or specifically for
Lisp data. I would not be very interested to use tables for control
structures, but would like more support for auto-aligned layout for control
structures.

------
nemoniac
Neat idea. It draws directly from the approach to learning functions of
multiple complex arguments in www.htdp.org

Looking forward to 3D syntax for functions of 3 arguments.

------
GregBuchholz
Yes, and next I'd love to see big parentheses:

    
    
        ⎛if ⎛> (+ a b)⎞ ⎛case x      ⎞ ⎛cond              ⎞⎞
        ⎜   ⎝  (- c d)⎠ ⎜    (1 'foo)⎟ ⎜  ((> y 2) 'quux) ⎟⎟
        ⎜               ⎜    (2 'bar)⎟ ⎝  (t       'error)⎠⎟
        ⎝              ⎝    (3 'baz)⎠                   ⎠
    

(([http://imgur.com/oI0zVm3](http://imgur.com/oI0zVm3)) if that isn't
rendering for your setup)

~~~
sitkack
This is an excellent idea!

------
kv85s
RacketFunge?

------
ebbv
This is not a good idea. That code is gross and illegible. There's definitely
better ways to handle anything where you think this is the solution.

~~~
Retra
What's illegible about it? I don't even know Racket, and I can see plainly
what it does.

