Weird(?) thought about programming languages

ruby-talk
1

This thought isn’t necessarily about Ruby specifically, though the
occasional wish expressed here that Ruby have Lisp-like macros added to
it resonates with it.

I’ve been reading Paul Graham’s On Lisp to finally learn what all this
talk of Lisp macros is about, and I’ve read enough (I’m into chapter 15
so far) to understand a lot of it, generally speaking. I spent some
time trying to understand how it might be possible to use macros to give
Lisp (or Scheme) a syntax that’s easier for me to read (for instance, I
find most of the function names I’ve encountered in Common Lisp to be
pretty incomprehensible). I even came across a USENET posting from
about 1991 from a guy who had done that with Scheme, but I couldn’t find
any more references or a way to contact him. Further searches of the
Web turned up another discussion about making Scheme need fewer
parentheses that finally taught me what I think is a core lesson about
language syntax: it’s difficult, if not impossible, to change the
punctuation of a programming language using its own mechanisms. By
punctuation I mean how tokens are delimited/defined.

The discussion about making a less-parenthesized version of Scheme
concluded that you’d have to write a special-purpose reader (basically
parser, IIRC) to accomplish the task. Thus you can write as highly
abstracted and domain-specific a language as you like on top of
Lisp/Scheme, as long as you adhere to the way these parent languages
uses parentheses, whitespace, and alphanumeric characters to define
language tokens. Adding words (and even language constructs, in a
language that has macros) to a language’s vocabulary is easy, but
redefining how to define words is impossible without stepping outside
the language. Of course, you could write a parser for your extended
language in the language you’re extending, but my point is there’s no
way to make a parser for the original language work with the extended
language if you violate the parent language’s punctuation rules.

Whew, just wanted to say that somewhere that someone would understand
it. Comments welcome, but not necessary.

Al

···

–
Albert Davidson Chou, QA Manager
TeaLeaf Technology, Inc.
(415) 932-5031
AChou@TeaLeaf.com | http://www.TeaLeaf.com/

2

Albert Chou wrote:

This thought isn’t necessarily about Ruby specifically, though the
occasional wish expressed here that Ruby have Lisp-like macros added to
it resonates with it.

I’ve been reading Paul Graham’s On Lisp to finally learn what all this
talk of Lisp macros is about, and I’ve read enough (I’m into chapter 15
so far) to understand a lot of it, generally speaking.

I tried reading that, but after about three or four chapters I decided I
didn’t know enough Lisp to follow along. :slight_smile:

But I was motivated by the same reason, to better understand macros.

I spent some

time trying to understand how it might be possible to use macros to give
Lisp (or Scheme) a syntax that’s easier for me to read (for instance, I
find most of the function names I’ve encountered in Common Lisp to be
pretty incomprehensible). I even came across a USENET posting from
about 1991 from a guy who had done that with Scheme, but I couldn’t find
any more references or a way to contact him. Further searches of the
Web turned up another discussion about making Scheme need fewer
parentheses that finally taught me what I think is a core lesson about
language syntax: it’s difficult, if not impossible, to change the
punctuation of a programming language using its own mechanisms. By
punctuation I mean how tokens are delimited/defined.

There was some similar discussion here about implementing a syntax in
Ruby that would allow one to manipulate XML using near-literal XPath
syntax (along the lines of ECMAScript and E4X).

The discussion about making a less-parenthesized version of Scheme
concluded that you’d have to write a special-purpose reader (basically
parser, IIRC) to accomplish the task. Thus you can write as highly
abstracted and domain-specific a language as you like on top of
Lisp/Scheme, as long as you adhere to the way these parent languages
uses parentheses, whitespace, and alphanumeric characters to define
language tokens. Adding words (and even language constructs, in a
language that has macros) to a language’s vocabulary is easy, but
redefining how to define words is impossible without stepping outside
the language. Of course, you could write a parser for your extended
language in the language you’re extending, but my point is there’s no
way to make a parser for the original language work with the extended
language if you violate the parent language’s punctuation rules.

I believe Phil Thomson has done some work creating a meta-language in
Ruby to allow QA/testers to write and run scripts that are, techincally,
Ruby, but do not require any profound understanding of Ruby’s nuts and
bolts. (And Ruby itself is a meta-language on top of C.)

That sort of thing, as well as Graham’s On Lisp macro stuff, is along
the lines of “build a language, not an application.”[0]

James

[0] http://www.pragmaticprogrammer.com/ppllc/papers/1998_03.html

3

If a language included its own parser as an object in the language, then you
could do it… in a way, I think.

As far as I know, no language goes that far, yet.

Chris

4

Smalltalk has late-bound mutable classes, and the class responsible for
parsing is written in Smalltalk.

–Aaron

···

On 2003-10-22, Chris Pine cpine@hellotree.com wrote:

If a language included its own parser as an object in the language, then you
could do it… in a way, I think.

As far as I know, no language goes that far, yet.