Norm-driven software development (NDSD) - automated business software generation in industrial programming languages - syntax tree manipulation

[Alex]

I have completed successfully OpenCog build and now I am about to start my real project - Norm-Driven Software Development (NDSD): 

1) formalization of law, norms, software industry best practices, software elements and components;

2) software generation (and maintenance) using formalized norms.

OpenCog is very appropriate for the first task (although I need yet to understand how to represent modalities (obligations, permissions) in PLN and rules), because it smoothly integrates logic/reasoning with representation of the real-world/commonsense knowledge (which is taken into account in almost any legal reasoning task).

However I am researching how to do the second task - I have only vague ideas how to do this generally or with OpenCog particularly. My idea is to create layers of repositories: one level can consist of UML style set of business classes, of view classes and services classes and another level is the syntax tree representation of the software code from which the final code can be read and sent for the compilation and production of deliverables.

I am still thinking how to do syntax tree manipulation in OpenCog and I just wanted to know are there floating some similar ideas around - not to rediscover already known things.

I am aware of MOSES and procedural knowledge representation (using Combo programs) but MOSES is program search using genetic programming and Combo is not industrial programming language.

I feel that extensive set of norms can create detailed enough specification (or put constraints on the search space) to speedup genetic search or even fully replace it.

I feel that there is need for the manipulation of procedural knowledge that is represented in the industrial programming languages because:

1) such knowledge can be reviewed and maintained by human beings (as the last resort);

2) already existing code should be included in such knowledge, maintained and the knowledge extraction from the existing code should be possible;

3) large parts of OpenCog is still written in the industrial programming language - therefore ability to work with industrial programming languages is necessary for the enabling self modification and self-understanding of the system.

Every program can be represented as abstract syntax tree and therefore I should start with enabling syntax tree manipulation in OpenCog...

Alex

[Ben Goertzel]

Well, the language used by the Pattern Matcher is a sort of
probabilistic logic programming language for the Atomspace, and is
appropriate for the task you're describing...

I would say to make it industrial quality we need

-- to clean up the syntax a bit, to make it more concise to specify
programs/patterns

-- to scale up the internal engine, so it can run more flexibly across
multiple machines, and better leverage multiple processors, etc.

but that it's good for experimentation and for some practical applications now

-- ben

> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/171290fa-603a-4179-880f-bf31d311746c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Ben Goertzel, PhD
http://goertzel.org

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

[Alex]

By "industrial programming language" I meant (as this term is used by our professor) languages that are used for the business software development, i.e. languages like Java, JavaScript, SQL, C++, C#, Python, COBOL, FORTRAN, etc. and there is no direct connection with the quality of the language or its tools. E.g. there are very good Prolog, Haskell etc. implementations but I don't call then "industrial programming languages", because they are rarely used for business programming.

[Nil Geisweiller]

Hi Alex,

we haven't experimented with reasoning-based language generation. I can
see how this would be possibly once the the Backward Chainer is
completed (I hope to be done today, as I've been saying to myself for
the past 4 months). Either we could support dependent types, put the
specification in the variable type, and use this variable as a target
for the Backward Chainer, then translate the generated atomese program
to an industrial language. Or directly formalize an industrial language
in the atomspace. We would then invoke the backward chainer on the
following target

Evaluation
Predicate "meet-c++-specification"
List
<specification>
Variable "$prog"

which would fill up $prog with programs that meet the given
specification. The tedious part is to describe "c++-meet-specification",
etc. Of course it would rapidly explode in complexity, but for very
simple programs it should work. Making this scalable is the next
challenge that we'll eventually attempt to address via meta-learning.

Nil

> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com

> <mailto:opencog+u...@googlegroups.com>.

> To post to this group, send email to ope...@googlegroups.com

> <mailto:ope...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/8a893437-096d-4477-9c19-e8098d1a9b8f%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/8a893437-096d-4477-9c19-e8098d1a9b8f%40googlegroups.com?utm_medium=email&utm_source=footer>.