[Python-ideas] Python as meta-language
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
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.
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
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
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.
More information about the Python-ideas