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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4