Ravi Teja wrote:
> > Or... maybe to be more specific, the hard work later on goes into
> > *code*. If you are enhancing your model, you do so with methods on the
> > model classes, and those methods don't effect the DSL, they are just
> > "code". You create some raw XML in the beginning, but quickly it's
> > just a matter of gluing those pieces together, using functions instead
> > of DSLs, and that's just "code".
>
> > That doesn't look that much better. How do you create it
> > programmatically? I know how to pass a variable to
> > CharField(maxlength=200); can I pass a variable to "char length 200"
> > just as easily? Can I use **kw? Can I read it from a CSV file and
> > construct the class that way? Maybe, but only by recreating all the
> > native patterns that I can infer easily looking at the Django class.
>
> I am looking at it from the cognitive perspective. You are looking at
> it from the compiler perspective.
I don't think that distinction is very meaningful. As a programmer I
have to understand both. I have to be able to synthesize correct
expressions. I need to understand the compiler. 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.
> I think you are talking about full blown DSLs like SQL which try to be
> self contained for a given domain. The ones I am referring are only
> thin layers on Python.
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.
If you are really serious about the implementation, sure. But DSL
almost screams out that it lacks seriousness, and a long-term
commitment to debuggability, generality, and documentation.
> However I think that you are seeing my sample differently than I meant
> it. I did not mean to create a special syntax file that would be parsed
> as a text file such that it would loose all the benefits of Python. It
> is just a thin layer over Python code for specific representational
> benefits. Kay Schluehr does a good job of identifying it as such in his
> reply.
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.
There are also very *specific* things that can be discussed that are
more conventional, and driven as much by the ease of implementation as
expressiveness. I think that is much more productive, because I think
the general case is a bad idea. The 'make' syntax is an example of
this.
Ian
--
http://mail.python.org/mailman/listinfo/python-list
