Deposing Dictators

[Dirck Blaskey]

"Steve Horne" <sh at ttsoftware.co.uk> wrote in message
news:n0r2mto4fv52lhqh4i2u8dl9ja44ad3uog at 4ax.com...
> ...
> 1.  A lot of the ideas turn out not to be for a programming language
> as such at all. Rather, it combines the ideas of literate programming
> with a kind of replacement for make. An XML notation would allow
> source code in a range of languages to be packaged in a linked set of
> XML files with documentation, detailed specification of the build
> process and explicit requirements for the run-time and build-time
> environment. It would allow you to specify, for instance, that the
> source code for this C++ module contains a constant structure derived
> according to xxx principles (for the documentation) and can be
> generated by running yyy script in zzz version of Python (or
> whatever).
>
> Definitely a case of going off at a tangent!
> ...

Unless you have compelling reasons for using XML, I would suggest
the alternative of using Python itself as the meta-language.

Maybe I don't fully understand your intended use of XML, but
it gives me a good opportunity to go off on a tangent, as well.
(Hmm...  Maybe it's time to change the subject: line?)

XML is a bit hard on the eyes (quite unlike Python).
I've been using Python as a meta-language, and it's kind of a neat twist.

For example, here is a piece of a script defining a database structure:
####################
from dbmodel import DBD
db = DBD('cmsmain')
table = db.table('Active Clients')
table.field('ClientID', 'COUNTER', nulls=1)
table.field('ClientName1', 'VARCHAR', size=50)
table.field('Address1', 'VARCHAR', size=50, nulls=1)
table.field('City', 'VARCHAR', size=25, nulls=1)
table.field('State', 'VARCHAR', size=2, nulls=1)
table.field('SalesPersonID', 'INTEGER', nulls=1)
table.primary('ClientID')
table.unique('ClientName1', name='ClientName1')
table.index('SalesPersonID', name='SalesID')

table = db.table('Active Contracts')
table.field('ContractID', 'COUNTER', nulls=1)
table.field('ContractNo', 'VARCHAR', size=15)
table.field('ClientID', 'INTEGER')
table.field('IntRate', 'FLOAT', nulls=1)
table.primary('ContractID')
table.unique('ContractNo', name='Active ContractsContractNo')
table.index('ClientID', name='ClientID')

db.onetomany('Active Clients', 'ClientID', 'Active Contracts', 'ClientID',
enforce=1, cascadeUpdates=1, cascadeDeletes=0)
####################
Python modules can load this and generate the
appropriate CREATE TABLE statements for the target platform
(it seems like all SQLs are different), or alternatively,
query a platform, and generate this Python code from an
existing SQL database, which can then in turn be loaded
and the structure reproduced on a different platform.

Maybe the point here is subtle, and I'm not sure exactly how to express it.

The code above isn't quite like normal code, exactly, because the code
itself is essentially the persistent data structure.
dbmodel doesn't _do_ anything, all the dbmodel classes can do are
be created, be queried for their structure, and write themselves out,
as Python code.

A dbmodel might be used somewhat like this:
====================
    import dbmodel
    db = dbmodel.Load("modelfile")
    for table in db:
        print table,
        for field in table:
                print field,
        print
====================
It occurred to me that it would be cool if they could also
call into another DBD-like class exactly as above, in essence,
reproduce, or reflect their structure onto another implementation,
which might have different purposes.

Something like this:
====================
    import dbmodel
    import dbgen

    g = dbgen.thingie()
    db = dbmodel.Load("modelfile")
    db.renderOn(g)
====================
which is subtly different from this:
====================
    import dbmodel
    import dbgen

    g = dbgen.thingie()
    db = dbmodel.Load("modelfile")
    g.buildFrom(db)
====================

Another example, from a Python build system (for C/C++) I use instead
of make (it has #include searches and dependency checking.)
Here's an example recipe '.bld' file:
########################

TARGET="application.exe"    # our target executable

BUILD=["../lib/framework.bld"]  # required subprojects: we're using this lib

SOURCES=["../util/*.cpp",  # sources to build and link
         "/thirdParty/xsrc/*.c",
         "main.cpp",]

DEFINES=["DEBUG_FRIPPERY", "NO_WIDGET_CHECKS"]      # some switches

INCLUDES=[".", "../util", "/thirdParty/stuff"]  # where to look for includes

LIBRARIES=["../lib/framework.lib"]    # libraries to link

##########################
So instead of futzing with Make rules and yet-another-obscure-syntax,
all I do is write little Python declarations for what I want.

You could also put conditionals in the recipe based on configuration
options.

Another example, a deliver recipe, from a tool that just copies files about:
##########################

SOURCE="../lts/cdoc/src"
TARGET='../ship/cdoc/src'

files=FileSet(base=SOURCE,
              files=['*/*', '*/*/*'],
              exclude=['*.obj',
                       '*.exe',
                       '*.pdb','*.idb','*.ilk'
                       'tools/*'])
files.copy(TARGET)

##########################

I've been thinking about another Python-Code-Model-Representation for
vector graphics documents.  Maybe something like this:

##########################
from picmodel import *
pic = PICTURE()
pic.dpi(72)
pic.extents(0,0,8.5*72,11.5*72)
pic.fill_color(red)
pic.frame_color(blue)
pic.frame_width(1)

pic.rectangle(0,0,100,100)

shape = pic.shape()
shape.line(10,10)
shape.line(15,0)
shape.line(20,10)
shape.arc2((15,15),(10,10))
pic.shape_fill(shape, (100,100))

##########################

Then you could do this:
=====================
import picmodel
import pslib
import pdflib

ps = pslib.target("file.ps")
pic = picmodel.Load("picturefile")
pic.renderOn(ps)

pdf = pdflib.target("file.pdf")
pic.renderOn(pdf)

=====================

Still thinking about that one.  Graphic models get pretty horrendous.

Hopefully this isn't too obscure, and maybe gives you some more ideas.

-off-on-still-yet-another-tangent-
d