[Python-ideas] Python as meta-language

Ron Adam rrr at ronadam.com
Mon Dec 25 07:42:35 CET 2006


Ron Adam wrote:
> Talin wrote:
>> What I'd be interested in doing, in this python-ideas list, is 
>> brainstorming some ideas for how we can improve Python's ability to 
>> 'host' other kinds of mini-languages within the Python syntax. We can 
>> start perhaps by examining some of the use cases I listed in the first 
>> paragraph - particle systems, etc - and see how one would want to 
>> represent those kinds of semantic structures within Python.
> 
> 
> Another (possibly related?) idea I think might be useful is to incorporate the 
> concept of responsibility, authorization, delegation into the language more 
> directly.  In a (well run) business responsibility and authority are delegated 
> in a way that gives the employee the ability to succeed, while also protecting 
> the interests of the business owners(s) by not giving too much power to any one 
> employee.  These are good business practices and I think they could be useful 
> concepts if implemented in a computer language in a more formal way.


I wanted to expand on this a bit since I do think it's related to several 
discussions that have taken place on the python-3000 list.  In general, I get a 
feeling that there is an effort to reach for that next thing.  So far that next 
thing has centered around efforts to extend generators, the with statement, 
generic functions, and improved threading/multiprocessing.  And now your desire 
for mini-language support could be included in that.  So how are these all 
related and is there a common theme that can organize these ideas in a way that 
is not brain exploding, as one respected individual here abouts would put it.  I 
think so.

I mentioned above the business concepts of responsibility, authorization and 
delegation.  But without describing how those concept would relate to a computer 
languages in general and also python, it probably doesn't mean a whole lot.  So 
I'll try to give an outline of how this might work.


Most business's are pretty boring in that there are no (or few) surprises. 
Everything is planned out.  There is usually a manual of procedures to follow 
that is used to train new workers.  Those procedures are usually based on sound 
and well tried business practices.  The biggest problem most business's have is 
hiring dependable workers to actually do the work.  In most cases workers are 
expected to do more than one job.  Also there are times or situations where 
workers join together to do one larger job.  These are also relationships that 
would be good to emulate in software.  So lets look at some of these 
relationships and how they might be organized in a software program.

A brief outline to help picture things:

     Data base -  The inventory

     Skill base - The procedures, (a collection of routines)

     Knowledge base - How to combine skills and data to achieve desired results.

     Worker objects:
        Responsibility - the objectives the worker must achieve
        Authorization - limits of what data, skills, and knowledge, can be used

     Delegation - The assignment of responsibility and authority to a worker.

A Skill base might just be another name for generic functions.  It's really just 
a collection of routines to do standardized things to data.  These could be 
tests to check quality or values, or routines to combine, split or alter a unit 
of data.

A knowledge base is a bit more, it's the instructions of how to combine skills 
to achieve specific objectives.

Workers would be something new.  They would be sort of be like an object, but 
instead of having limited skills (methods) in them, they might have 
responsibilities and authorizations. Each responsibility would represent a 
different activity which would be defined by the knowledge base.  And 
authorizations would specify what knowledge and skills can be used.  This would 
be needed to insure a worker object doesn't get used in an abusive way.  For 
example if you have a worker object assigned to processing input you may want to 
limit this particular worker to this one activity so there is little chance it 
can be hacked and used for other things.

In other less critical places you may have a group (pool) of worker objects that 
can fill multiple needs.

These worker objects could be run on different threads.  Groups of workers might 
be run on different CPU's.  Possibly, this would be something that is determined 
by the interpreter (manager) and not something the programmer has to think about.


These are just seeds of ideas right now, but I think there is a lot of potential 
in going in this direction. I would place this in between artificial 
intelligence and objective programming.  This would be a higher level of 
abstraction with the goal of using both software and the underlying hardware 
more efficiently.

How this translates to different programming models depends on how you 
distribute and organize the work between worker objects.

A series of worker with each a single responsibility would be a procedural 
structure.  (an assembly line)

A group of  workers with many shared responsibilities would be a parallel (or as 
close as the hardware allows) structure.  These would be used to simulate models 
with many object and specifications.


Ok it's late and I'm starting to loose my focus.  Hopefully you can see how this 
might be related to either emulating mini-languages, or how it might be a 
mini-language in it self.  And also hopefully there isn't too many typos or 
mistakes due to me being tired.

Cheers,
    Ron






























More information about the Python-ideas mailing list