code is data

[Ravi Teja]

> I don't think that distinction is very meaningful.  As a programmer I
> have to understand both.
> I understand the Python compiler well, and it gives me reasonably good feedback when I
> get things wrong, and it has a lot of flexibility along several
> orthogonal lines.
> We're talking about programming languages, so it's useless to consider
> a cognitive perspective without considering the compiler perspective.

As some one who has followed your excellent articles, posts and tools
over the last many years, I don't doubt your expertise at all.

I admit I am not be entirely looking at this as a programmer. I am
working in informatics for the last few years. At least in this domain,
it is useful to seperate the perspectives. Sort of like designing a
functional language based primarily on mathematical abstractions rather
than imperative realities. Yes! Once the implementation is underway,
the practical realities are unavoidable but they interfere in thinking,
otherwise.

> I understand you, but it's very unclear to me how you can make a thin
> layer that's not horribly leaky or stunted.  In my experience one or
> both are likely in DSLs, and the result is horrible and only useful as
> a toy.

I am not making this up out of thin air. There is already an
implementation, Logix, which allows you make thin layer DSLs on top of
itself (which in turn sits on top of Python). It did not fly but I
could not technically fault it (except maybe that it is not very
optimized at the moment). Maybe with your better understanding of
language implementations, you can.

> I understood the distinction you were making.  But you were also
> speaking generally about generally programmable syntax, and I don't
> think that's a good idea, and it's very unclear how that mixes with
> Python.  You can always do:
>
>   model = make_model("""
>   my funny syntax
>   """)
>
> And you actually get something that can be a close peer to normal
> Python code.  But if you are talking about Python and some novel syntax
> interleaved, then the details seem to matter a lot, because the
> implementation is substantial and potentially invasive.

NO! I have a feeling that you are interpreting me as a language
radical. I do not think that Python syntax should have too many
novelties. Currently Python feels a cohesive whole. A well designed
entity rather than something that evolved by accretion of features like
Perl. With active attempts to prune inconsistencies for that end
(Python 3000). And I value all that.

But Logix does not add ANY new syntactic constructs to Python. There is
a special import function that imports a macro supporting Python
language variant module where one can create special syntactic
constructs. I am quite satisfied with the macro capabilities of Logix.
But I am just grumbling that the Python community does not find macros
interesting. But without enough users, it simply dies away.