Arc Forumnew | comments | leaders | submitlogin
Ask Arc: does code have to be text?
3 points by andreyf 4250 days ago | 18 comments
Why is it that code is always viewed as ASCII text? APL insanity aside, it would seem useful to replace appropriate function names with ≡, ¬, λ, and ≠ in an IDE (and have the language understand it). This would cut out some of the insanity with people arguing over (not ) versus (no ).

More generally, is there a particular reason language creators see IDE design as beyond their scope of work? It seems to me the two should be interwoven.

8 points by CatDancer 4250 days ago | link

If you'd like to use some symbols for particular functions, you don't need an IDE... or anyone's permission :-)

  arc> (= ¬ no)
  #<procedure: no>
  arc> (¬ t)


1 point by andreyf 4240 days ago | link

Precisely! Now, just make emacs replace "no" and "not" functions also, and you'll have what I was asking for.

However, my point is also that doing this kind of thing should be within the scope of PG's work - providing a "reference IDE" to show how he intends Arc code to be interacted with.


4 points by jonnytran 4239 days ago | link

andreyf, I completely agree with you. How people write code in a language is -- from a user experience perspective -- part of the language in a very real sense. I've written about this before.

Using symbols like ¬ and λ is a start. Paredit is even better. But I think programmers are stuck in the mindset that source code has to come from an ASCII text file. If you truly get the idea that code is just data, there's no reason why your "IDE" shouldn't be integrated with the language and provide a higher-level representation of the data you're editing. Also, depending on the task, you may want to view different aspects of your code. You can think of your source as the model in an MVC where multiple views and editing styles for the same data-structure are possible.

Once you view your code simply as data, all sorts of possibilities open up. The so-called Source Code In Database site has tons of examples of these features.

One very big inspiration for me has been Subtext. You just have to watch the demo; I can't explain it.


2 points by drcode 4249 days ago | link

I think the answer is simple: If you allow non-ascii characters in a lisp, it would only "feel" right if the characters were fully programmable, as opposed to just adding a handful of extra characters. Lisp users don't like new features if they aren't fully programmable- You should be able to declare a new symbol in lisp code somehow and then be able to use it, IMHO. This, however, is non-trivial to implement (though I've had some ideas about this that I've been wanting to code up for years but haven't had time to do yet...)


1 point by CatDancer 4249 days ago | link

What does "fully programmable" mean?


1 point by drcode 4248 days ago | link

By that I mean if you define a table library, you should be able to write code that allows the data of a table appear like a table, with a grid and everything, right within your code editor. That's what I would mean with "fully programmable"


1 point by CatDancer 4247 days ago | link

When you say you want "characters to be fully programmable" does this mean that if you had "fully programmable characters" you'd be able to edit tables in your code editor as you describe, or are you making an analogy saying that you'd want characters to be fully programmable like these tables are fully programmable?


2 points by drcode 4243 days ago | link

The former- I'm saying that if you're going to allow more characters, I'd want to go all the way and have an editor that is part of the "language definition" that supports arbitrary graphics and ui elements that is controllable through the language in a "lisp like" way and would allow code appearance to be 100% customizable right inside the code.


1 point by zitterbewegung 4240 days ago | link

You mean redefine the reader and have reader macros?


1 point by jonnytran 4239 days ago | link

No, I think what people are getting at is... why does program source have to be represented by only ASCII text? After all, if code is data, an IDE is just a data editor, where that data happens to be code.

I think it has been shown many times throughout history that notation matters. In fact, the entire concept of Arc is based on this principle. Otherwise, Common Lisp would be suitable.


1 point by justsomeone 4234 days ago | link

Why does it have to be ASCII? No reason, The simplest answer may just be that the language writer feels that adding UTF-8, or UTF-16, support would be a waste of their time, or is below them. As for programming IN the language, it becomes a matter of what is easy for the programmer to type. In a way, this whole thing is a matter of deciding what is the lowest common denominator that one wants to support.


1 point by CatDancer 4242 days ago | link

"allow"? ^_^


3 points by sammyo 4234 days ago | link

Certainly not, any symbol can be translated into code or another symbol. A 3D language in a virtual haptic programming environment with dynamic force feedback... that bug is represented by... a bug, your world shakes when the code crashes!

There are bits of library calls I always seem to need to lookup, I'm sure if I found it by reaching way back to the left and twisting, it would always be 'at hand'. I want to dance my code!

Pragmatically tho, the significant convenience of the common denominator of common keyboard symbols trumps most attempts so far.


2 points by cchooper 4249 days ago | link

Isn't Squeak an example of a language interwoven with its IDE?


1 point by cchooper 4249 days ago | link

Another example: Mathematica is well integrated with its environment and uses much more than plain ASCII. Not only does it have all kinds of mathematical symbols but you can even paste pictures into Mathematica code to do image processing.

Something like that for a Lisp language would be very cool.


2 points by eds 4249 days ago | link

I think you can already use images in PLT Scheme source code...


1 point by shader 4209 days ago | link

Interesting. Code as data -> Data as Code. Pictures as data; pictures as code? That reminds me of some "graphical" programming language I saw a while ago. It used blocks of color to control the interpreter much like a Turing tape. The head would "move" up down, left or right depending on color, and perform various other operations.

How would you use images as code?


1 point by cchooper 4248 days ago | link

That is very cool. I wonder if that works for input too.