9 ms·

2D Syntax

371 points by mr_tyzic 9y ago

jacobparker 9y ago
Nicely done! Different but similar joke for C++: http://www.eelis.net/C++/analogliterals.xhtml http://www.eelis.net/C++/analogliterals.xhtml
- tobyhinloopen 9y ago
  Oh god how is that possible
  - vidarh 9y ago
    Templates coupled with abusing operator overloading and escaping rules. Basically, the layout is a red herring to an extent. E.g. the "\" in the shapes is only there for visuals - it's allowed because it's escaping the following linefeed, but not necessary. If you strip out the "filler" it boils down to constructing an expression, using types and overloaded operators to represent an expression tree that is then evaluated by the C++ template processing to satisfy type constraints. The "asserts" of sorts works by using templates to create a type that accepts only the corresponding type generated by the "literal" shapes as argument to the constructor. It looks harder than it is because it's hard to "see" operators. Consider that e.g. "o---o" is "(o--) - o". and a rectangle boils down to "((o--) - o) | (!(!(!((o--)-o))))" or so (hope I got the parentheses right). Sort-of. I've not bothered deciphering the exact details of how it's processed. The overall mechanism of using types and operator overloading to represent expressions is pretty well established in C++ template meta-programming, though, and is also used elsewhere. E.g. a lot of Ruby ORM query building and other DSLs is often using similar methods.
- deleted 9y ago
  [deleted]
- fizixer 9y ago
  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).
  - jacobparker 9y ago
    I did, but I didn't mean it in a negative way! The Racket one is definitely more towards the "practical" side than the C++ one (C++ is more constrained when it comes to how it can embed DSLs) but for me it falls into a similar bucket with the label "interesting and quirky DSLs that probably aren't practically useful but make me very happy". You may disagree regarding practicality and that's okay by me but please don't take offense. :)
    - TeMPOraL 9y ago
      Folks over at JetBrains built a whole big tool to handle things like this[0], so there is some non-joke motivation. Still, it's nice that Racket can handle this perfectly well in plaintext. -- [0] - https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/
  - gus_massa 9y ago
    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 9y ago
      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.
    - deleted 9y ago
      [deleted]
- 0xcde4c3db 9y ago
  Another different but similar joke for C++: https://stackoverflow.com/questions/5508110/why-is-this-program-erroneously-rejected-by-three-c-compilers https://stackoverflow.com/questions/5508110/why-is-this-prog...
kv85s 9y ago
RacketFunge?
hyperion2010 9y ago
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/readtable.rkt https://github.com/racket/2d/blob/master/2d-lib/private/read... [1] https://docs.racket-lang.org/guide/hash-reader.html https://docs.racket-lang.org/guide/hash-reader.html
- gcr 9y ago
  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.
ooqr 9y ago
Surprisingly exactly what the title makes it sound like. Very cool!
sharpercoder 9y ago
Tables are generally a very good idea for languages. SpecFlow/cucumber as most notable example, but I can see others benefitting greatly as well.
ebbv 9y ago
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 9y ago
  What's illegible about it? I don't even know Racket, and I can see plainly what it does.
- eximius 9y ago
  Such as?
deleted 9y ago
[deleted]
oh_sigh 9y ago
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 9y ago
  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 9y ago
    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.racket-lang.org/2d/index.html https://web.archive.org/web/20160316083925/https://docs.rack...
  - simcop2387 9y ago
    From the looks of it, I bet you could make emacs' artist mode do it. https://emacs.stackexchange.com/questions/228/how-can-i-draw-in-unicode-with-artist-mode https://emacs.stackexchange.com/questions/228/how-can-i-draw...
- ez_white 9y ago
  I have a friend that works in the PL lab at Northeastern on a Racket Library. He uses emacs evil mode.
- ez_white 9y ago
  I have a friend that works in the PL lab at Northeastern on a Racket Library. He uses emacs evil mode.
glangdale 9y ago
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 9y ago
  > 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 9y ago
    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.
    - nikki93 9y ago
      I mean programming is already ASCII art. That's why we indent as opposed to directly writing minified JS and why { and } are mirrors of each other. Self-limiting beliefs like those expressed in the comment you are responding to are more a function of what timespan the author was born in than anything else.
b123400 9y ago
It reminds me of Funciton, https://esolangs.org/wiki/Funciton https://esolangs.org/wiki/Funciton
joshlemer 9y ago
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-composition.html#composing-complex-systems http://doc.akka.io/docs/akka/current/scala/stream/stream-com...)
fao_ 9y ago
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 9y ago
  "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 9y ago
    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.
- lallysingh 9y ago
  I think developers would figure this out in roughly 10 minutes. And they'd use it where it made more sense than a single cond.
vidarh 9y ago
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/
GregBuchholz 9y ago
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 9y ago
  This is an excellent idea!
nprescott 9y ago
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.html http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm....
kazinator 9y ago
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 9y ago
  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 9y ago
    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.
kovek 9y ago
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 9y ago
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.
shanavasm 9y ago
Amazing :)
nemoniac 9y ago
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.
agumonkey 9y ago
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-conditionals/ http://aigamedev.com/open/review/schematic-table-conditional...
ziotom78 9y ago
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
- deleted 9y ago
  [deleted]
hota_mazi 9y ago
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 9y ago
  > 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.
- rrobukef 9y ago
  Imagine you're using excel. Or something with HTML & javascript. `Click for a new match subtable...`
lispm 9y ago
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.
igravious 9y ago
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)

371 points by mr_tyzic 9y ago

Nicely done! Different but similar joke for C++: http://www.eelis.net/C++/analogliterals.xhtml http://www.eelis.net/C++/analogliterals.xhtml

tobyhinloopen 9y ago
Oh god how is that possible
- vidarh 9y ago
  Templates coupled with abusing operator overloading and escaping rules. Basically, the layout is a red herring to an extent. E.g. the "\" in the shapes is only there for visuals - it's allowed because it's escaping the following linefeed, but not necessary. If you strip out the "filler" it boils down to constructing an expression, using types and overloaded operators to represent an expression tree that is then evaluated by the C++ template processing to satisfy type constraints. The "asserts" of sorts works by using templates to create a type that accepts only the corresponding type generated by the "literal" shapes as argument to the constructor. It looks harder than it is because it's hard to "see" operators. Consider that e.g. "o---o" is "(o--) - o". and a rectangle boils down to "((o--) - o) | (!(!(!((o--)-o))))" or so (hope I got the parentheses right). Sort-of. I've not bothered deciphering the exact details of how it's processed. The overall mechanism of using types and operator overloading to represent expressions is pretty well established in C++ template meta-programming, though, and is also used elsewhere. E.g. a lot of Ruby ORM query building and other DSLs is often using similar methods.
deleted 9y ago
[deleted]
fizixer 9y ago
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).
- jacobparker 9y ago
  I did, but I didn't mean it in a negative way! The Racket one is definitely more towards the "practical" side than the C++ one (C++ is more constrained when it comes to how it can embed DSLs) but for me it falls into a similar bucket with the label "interesting and quirky DSLs that probably aren't practically useful but make me very happy". You may disagree regarding practicality and that's okay by me but please don't take offense. :)
  - TeMPOraL 9y ago
    Folks over at JetBrains built a whole big tool to handle things like this[0], so there is some non-joke motivation. Still, it's nice that Racket can handle this perfectly well in plaintext. -- [0] - https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/
- gus_massa 9y ago
  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 9y ago
    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.
  - deleted 9y ago
    [deleted]
0xcde4c3db 9y ago
Another different but similar joke for C++: https://stackoverflow.com/questions/5508110/why-is-this-program-erroneously-rejected-by-three-c-compilers https://stackoverflow.com/questions/5508110/why-is-this-prog...

kv85s 9y ago

RacketFunge?

hyperion2010 9y ago

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/readtable.rkt https://github.com/racket/2d/blob/master/2d-lib/private/read... [1] https://docs.racket-lang.org/guide/hash-reader.html https://docs.racket-lang.org/guide/hash-reader.html

gcr 9y ago
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.

ooqr 9y ago

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

sharpercoder 9y ago

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

ebbv 9y ago

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 9y ago
What's illegible about it? I don't even know Racket, and I can see plainly what it does.
eximius 9y ago
Such as?

deleted 9y ago

[deleted]

oh_sigh 9y ago

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 9y ago
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 9y ago
  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.racket-lang.org/2d/index.html https://web.archive.org/web/20160316083925/https://docs.rack...
- simcop2387 9y ago
  From the looks of it, I bet you could make emacs' artist mode do it. https://emacs.stackexchange.com/questions/228/how-can-i-draw-in-unicode-with-artist-mode https://emacs.stackexchange.com/questions/228/how-can-i-draw...
ez_white 9y ago
I have a friend that works in the PL lab at Northeastern on a Racket Library. He uses emacs evil mode.
ez_white 9y ago
I have a friend that works in the PL lab at Northeastern on a Racket Library. He uses emacs evil mode.

glangdale 9y ago

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 9y ago
> 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 9y ago
  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.
  - nikki93 9y ago
    I mean programming is already ASCII art. That's why we indent as opposed to directly writing minified JS and why { and } are mirrors of each other. Self-limiting beliefs like those expressed in the comment you are responding to are more a function of what timespan the author was born in than anything else.

b123400 9y ago

It reminds me of Funciton, https://esolangs.org/wiki/Funciton https://esolangs.org/wiki/Funciton

joshlemer 9y ago

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-composition.html#composing-complex-systems http://doc.akka.io/docs/akka/current/scala/stream/stream-com...)

fao_ 9y ago

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 9y ago
"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 9y ago
  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.
lallysingh 9y ago
I think developers would figure this out in roughly 10 minutes. And they'd use it where it made more sense than a single cond.

vidarh 9y ago

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/

GregBuchholz 9y ago

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 9y ago
This is an excellent idea!

nprescott 9y ago

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.html http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm....

kazinator 9y ago

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 9y ago
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 9y ago
  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.

kovek 9y ago

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 9y ago

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.

shanavasm 9y ago

Amazing :)

nemoniac 9y ago

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.

agumonkey 9y ago

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-conditionals/ http://aigamedev.com/open/review/schematic-table-conditional...

ziotom78 9y ago

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

deleted 9y ago
[deleted]

hota_mazi 9y ago

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 9y ago
> 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.
rrobukef 9y ago
Imagine you're using excel. Or something with HTML & javascript. `Click for a new match subtable...`

lispm 9y ago

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.

igravious 9y ago

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)