Atoms, Identifiers, and Primaries

[Mark Janssen]

On Tue, Apr 16, 2013 at 8:55 PM, rusi <rustompmody at gmail.com> wrote:
> On Apr 17, 7:57 am, Bruce McGoveran <bruce.mcgove... at gmail.com> wrote:
>> 3.  Section 5.3.1 offers this definition of an attributeref:
>>     attributeref ::= primary "." identifier
>>
>
> One general comment I will make is regarding your distress at what you
> call 'circular'
> Circular just means recursive and recursion is the bedrock for
> language-design.

Rercursion the "bedrock" of language-design.  I don't think so.  From
what I know, a well-defined language ends at its symbols.  It makes no
use of "infinities".

> You cannot hope to define an infinite object such as the python
> language (there are an infinite number of python programs) with a
> finite specification

You've committed two grave sins in C.S.:  Conflating a programming
language ("an infinite object such as python language") with a program
written in that language ("there are an infinite number of python
programs").   These two are entirely separate (at least anything
implemented on a real computer).  Further, you've made a silly
description of python "an infinite object such as the python
language".  A programming language that is well defined has complete,
finite, specification.  The fact that there are an endless number of
programs that can be made from such is irrelevant to the language
itself.

> -- a useful language definition must start and
> end and preferably fit in one's pocket!

Likewise, a language specification must end in its symbols.

> The trick is to find ways of making an inifinite object finitely
> generated.

There is no trick involved.

> So much of language design is a generalization of Peano's
> method of defining (designing?) natural numbers:
> a. 0 is a natural number
> b. If x is a natural number then the successor of x (informally x+1)
> is a natural number

Well now you're getting to the root of the confusion and what I'm
arguing within the C.S. community:  there must be clear distinction
between lambda calculii and programming languages rooted in actual
hardware implementations.  While, traditionally, the field has not
made much of a distinction, in practice the computational architecture
is different.  One of these has a connection to reality and the other
not as much ;^).

In any case, talking about the mathematical realm *as a realm of
Platonic thought* is irrelevant to the discussion of program spaces
where *things actually get done*.

This is what this list (python) has not figured out yet, because they
look up to the theoretical C.S. field and it hasn't yet been
published.

-- 
MarkJ
Tacoma, Washington