[Python-Dev] PEP202 -- glossary of terms

[Eric S. Raymond]

Jeremy Hylton <jeremy@beopen.com>:
> Seriously, I don't understand how to apply terms like "applicative
> sublanguage in functional style" or "procedural syntax" to a concept
> like list comprehensions.  The basic idea is to express the elements
> of list using a set-like notation similar to the one used by
> mathematicians.  I don't know whether to call that applicative,
> functional, or procedural; perhaps none of them applu.  Maybe it's
> just late, but I suspect that these high-level terms don't inform the
> debate much.

Partly this is my error; I should have said "conventional" or "infix"
where I said "procedural".  I was writing too fast -- procedural
languages are conventional in a different way, but I was referring to
conventional syntax.

More generally, I guess I have to apologize for excessive use of jargon 
without enough context.  The crowd on this list is so fearsomely 
competent that I tend to forget that most of you don't have a technical 
specialty in language design.

Here's a brief glossary of relevant language-designer jargon:

functional style: 

   Refers to a language in which everything is pure function calls, without
side-effects or variables.  Backus's F is one of the better-known 
examples.  LISP would be functional if there were no (setq ...).

   The advantage of functional language is the same as their disadvantage:
no side-effects.   Makes them easy to reason about, but you have to jump
through hoops to do statefulness.  

procedural style:

   A procedural language has procedures that operate on variables.  
Explicit statefulness and side-effects are basic to such languages.

applicative sublanguage:

   This is more about syntax. To say a syntax is applicative is to say
that it *looks* like cascaded function calls, as opposed (for example)
to using infix syntax or keywords.  (This is oversimplifying a little;
Haskell combines keywords with a syntax that could be called applicative,
but Haskell is weird by design that way.)

imperative vs. declarative:

   In an imperative language, you tell the machine to do stuff.  In 
a declarative language you specify a desired end state and let the
language implementation deduce how to generate it.  A good example
of a declarative sublanguage familiar to most Python programers 
is Tk widget layout.

   List comprehensions are declarative in style, even though they
analyze down to a series of imperative actions.  Most of Python is
much more straightforwardly imperative.  One of the heuristics of good
language design is that boundaries between imperative and declarative
sublanguages are always tricky -- users have a strong tendency to try
to port concepts across the boundary and get confused.  This is behind
some of the confusion about comprehensions.

conventional:

   Means different things in different contexts.  When speaking of
syntax, it means pseudo-algebraic syntax with infix notation and
keyords.  

   In other contexts, it can mean procedural rather than functional,
or manual memory management rather than garbage collection, or fixed-extent
vs. unlimited-extent.

   The archetypal conventional language is Algol-60.  For you young 'uns
out there, think Pascal.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>