Syntactic Abstraction

The syntax of a language is the primary interface to that language. SyntacticAbstraction allows the programmer to make the syntax easier to use, in the same way that data abstraction makes data easier to use.

Languages supporting programmer extensible syntax:

LispLanguage family, exemplified by CommonLisp, SchemeLanguage and DylanLanguage. For some examples, see LispMacros. "OnLisp" might address this.
ForthLanguage (including PostScript) - all control constructs are "just" words that manipulate the stack and machine state in special ways. You can define your own "words" that offer alternative control constructs.
SmalltalkLanguage - you can pass blocks to functions and invoke them in arbitrary ways.
EDS "OWL" (an internal proprietary language; similar to Smalltalk) - all language statements were simply instances of particular kinds of objects, so you could extend the syntax by defining and using new classes. Also, strategies for a class' response to messages (IE: methods and properties) were extensible: The release version of OWL included several "expert system" method strategies that used a rule-based approach to respond to method calls, rather than procedural code.
C++ allows you to redefine operators, but is otherwise very limited in the "extensible syntax" dimension.

Examples of where SyntacticAbstraction is useful:

To concisely express how to read or write data. E.g. ErlangBitSyntax
To express iteration constructs. E.g. ListComprehensions or foreach loops
To provide new control structures E.g. aif below

Ok, here's a question for the SmalltalkerLanguage? programmers. In OnLisp one of the common idioms is to have a function return false on non-fatal error and some other value otherwise. So a common idiom to deal with this sort of function is

  (let ((result (function-that-can-return-#f)))
    (if result  
(do-something-useful result)
      (carry-on)))

In C-ish pseudo code:

  result = function_that_can_return_#f
  if (result) {
do_something_useful(result);
  } else {
carry_on();
  }

One of Paul Grahams macros in OnLisp is called aif. It simplifies this idiom by getting rid of the let. You can write

  (aif (function...)
(do-something-useful it)
(carry-on))

However, its real power is because it creates a new variable in the current scope, so you can refer to other variables in the current scope:

  (let ((variable a-value))
    (aif (function...)
  (do-something-useful it variable)
  (carry-on)))

This is useful in many languages. For example, in Java when one reads from a file you have to check for null. Say you are processing each line with a regexp:

Regexp csv = new Regexp("((.*),)*");
String line = bufferedReader.readLine();
if (line != null) {
    getValues(regexp, line) 
} else {
    carryOn();
}

You can write this easily with aif:

Regexp csv = new Regexp("((.*),)*");
aif (bufferedReader.readLine()) {
    getValues(regexp, it)
} else {
    carryOn();
}

This is something you can't do with blocks. It's not emulating LazyEvaluation but introducing a new binding in the existing scope. However, I have a feeling that this idiom isn't appropriate for SmalltalkLanguage as lexical scoping isn't such a widely used feature of the language. Thoughts? Is this an example of a SyntacticAbstraction that isn't applicable across all languages?

I'm not sure I understand the usage or that I've encountered the desire to do it in Smalltalk. In general I've come to feel that language extension as commonly done in Lisp is less appropriate in most other languages. But for this one, why not something like

  function: arg onSuccess: aBlock
(function: arg) ifTrue: [aBlock value]

used as in

  someone 
function: foo 
onSuccess: [self doSomethingUseful]

This isn't the same. I've expanded the example above to show how adding the binding to the current scope is useful

How about this? (I don't know any Smalltalk worth mentioning, so the details may be wrong.)

  try: funcBlock whenResultSatisfies: aPredicateBlock do: aBlock
|result|
result := funcBlock value.
(aPredicateBlock result) ifTrue: [aBlock result]

  bufferedReader
try: [self readline]
whenResultSatisfies: [:it | it isOK]
do: [:it | getValues from: it matching: regexp]

-- GarethMcCaughan (a fan of Lisp macros but not terribly excited by anaphora)

I'm trying to get a discussion on the uses of syntactic abstraction and where it is appropriate rather than how to do it in any particular language. So what excites you about Lisp macros? --NoelWelsh

Two things, mostly

The fact that they allow control of the time, and number of times, ov evaluation of their arguments, thus allowing you to write control structures on equal footing to those provided by the language designer
The possibility of performing arbitrary computation at read (usually compile) time. This allows you to decide how the macroexpansion rewrites itself as a function of its arguments (i.e. more than a simple textual transformation).

e.g. One often sees this sort of things in macros:

(defmacro foo (arg1 arg2)
`(progn
,@(some-complex-calculation arg1)
,@(another-complex-calculation arg2)))

(defmacro foo (list)
`(progn (foo-something (mapcar #'blah ,list))))

Does that help, or am I still being too abstract? --AlainPicard

So you do this to avoid runtime computation, in the same way some C++ templates try to do computation at compile time via template expansion?

Does the ability in PerlLanguage to have source-code filtering through another perl program, used to approximate in perl5 some of the syntax of perl6, or to implement (effectively) a compiler for a new language to perl, count as an instance of SyntacticAbstraction? -- MartinRudat

I dunno, but PerliGata seems pretty darned impressive. -- JonathanTang

CategoryAbstraction