code is data

[Ravi Teja]

Fredrik Lundh wrote:
> Ravi Teja wrote:
>
> > Web frameworks, which seem to be the rage now in Python community could
> > have benefited tremendously from Macro capabilities since they have a
> > lot of boiler plate.
>
> they do?  methinks you haven't done much web programming lately...
>
> </F>

You blogged on Django. Let's use that. Don't you think model creation
in Django can be represented better, given that it is done often
enough?

Let's take an example from the official tutorial
from
http://www.djangoproject.com/documentation/tutorial1/#creating-models

class Poll(models.Model):
    question = models.CharField(maxlength=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    poll = models.ForeignKey(Poll)
    choice = models.CharField(maxlength=200)
    votes = models.IntegerField()

I don't use Django and I made this up quickly, so please don't pick on
subtleties.

@Poll:
    question: char length 200
    pub_date('date published'): date

@Choice:
    poll -> Poll
    choice: char length 200
    votes: int

The following is my rationale. Annoted variables, symbols and code
layout visually cue more efficiently to the object nature than do
explicit text definitions. Of course, this is only sensible when there
aren't too many of any of those. In that case, the cognitive cost of
notation outweighs the representational cost of text.

Representational minimalism is troublesome in general code (ala Perl),
but not so in a DSL where the context is constrained.

I would also like to symbolize field types since they occur so commonly
in a definition file and only a few of them are commonly used. I admit
though that I find the code below a bit visually jarring and I might
use something else. But it serves to illustrate the point. I chose the
respective symbols based on their colloquial use and association with
the field types.

@Poll:
    $question: length 200
    %pub_date('date published')

@Choice:
    poll -> Poll
    $choice: length 200
    #votes

Since you are on thread and are a prominent and involved member of the
Python community, I would like it if you (or any such other) can
provide feedback on the rest of my previous post rather than be
dismissive by just a small portion of it. Perhaps, that will give me
some insight how these language design decisions are rationally made (I
am not strictly a programmer by profession, much less a language
designer).