Blockly in a browser allows web pages to include a visual code editor for any of Blockly's five supported programming languages, or your own.
Do you think Exp-log could be the final stage you're looking for?
Your next challenge will be to handle feature constraints. If you do it right, you will get semantic parsing for free. 8)
May I ask what are feature constraints?
https://en.wikipedia.org/wiki/Feature_structure (https://en.wikipedia.org/wiki/Feature_structure)
http://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node79.html (http://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node79.html)
You may recall that I implemented a very powerful GLR parser and some years ago I wrote a much more advanced version which can associate grammatical features with syntax rules. The result is that not only can much more be expressed with much simpler rules, the resulting parse trees are endowed with all the necessary semantic information as well. It is a very elegant and efficient way to solve a complex problem and now I am able to parse a sentence in plain English directly into an executable program.
Executable program? Sounds like NLP programming language.
Can feature constraints replace the need for variables?
Can feature constraints replace the need for variables?
That depends on what you're using variables for. I'm certainly not using any variables for parsing.
premises
------------
conclusion
--- --- --- --- --- --- --- --- ---
I J K L M N P Q R
----------------- ----------------- -----------------
A B C
-----------------------------------------------------------
X
( (~ 'true') -> 'false' ) /\
( (~ 'false') -> 'true' ) /\
( (@a /\ ~ @a ) -> 'false' ) /\
( (@a /\ 'true' ) -> @a ) /\
( (@a /\ 'false' ) -> 'false' ) /\
( (@a \/ ~ @a ) -> 'true' ) /\
( (@a \/ 'true' ) -> 'true' ) /\
( (@a \/ 'false' ) -> @a )
But, wouldn't you say that conjunction, disjunction, implication and negation of atoms are anyway implicitly "carrying" the notions of true/false/anyConstant? I mean, if we use some many-valued logic (https://en.wikipedia.org/wiki/Many-valued_logic), we need to rewrite the tables of these operators ok, but there are still tables, which hold "things" in their cells! How can we have operators without having constants?
You know, I have trouble handling negation as failure. I just can't get my head around it yet. A few days ago, I was working on... wait. Ok, done uploaded here (https://github.com/SimpleFriend/Jamie/blob/master/FRkr.md). It's a knowledge base-structure thing, in French sorry, but it doesn't matter. Here is the problem:
In the list, there is a "is an instance of" relation. It was super easy to represent in Prolog, no problem. Then, the plan was to also have a "is not an instance of" relation. Dang. I could never get it to work properly.
How do you say that something does not hold, in logic? How does this mind-skkkrrrr****ing negation as failure work? Can your current system handle this kind of... non-relation? The idea would be something like:
- If I say it is true, then it is true
- If I say it is false, then it is false
- If I say nothing about it, then we don't know yet, and we should be able to "work" with the fact that we don't know it
I know it's about open-world vs closed world assumption, but I just don't get it. :)
FACTS
_
_/ \_ D || /\
_/ \_/ \_ E || //\\
_/ \_/ \_/ \_ D || //||\\
_/ \ / \ / \ / \_ U || ||
/ \ C || ||
_ INPUT _ T || ||
_/ _ _ _ _ _ _ \_ I || ||
_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_ O || ||
_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_ N || ||
_/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \_ || ||
/ \ || ||
SEMANTICS || ||
\_ _/ || ||
\_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ || ||
\_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ || || A
\_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ || || B
\_ _/ || || D
OUTPUT || || U
\_ _/ || || C
\_/ \_/ \_/ \_/ || || T
\_/ \_/ \_/ \\||// || I
\_/ \_/ \\// || O
\_/ \/ || N
GOALS
introduction to intermezzo programming
[Intended audience]
Beginners in language parsing, term rewriting, and logic deduction
[Short description]
As an embodiment of general problem solving strategy related to term rewriting, Intermezzo aims to be a host for a variety of kinds of formal languages, exhibiting rule-based programming system. For each area of interest, one is able to define a custom domain specific language in a language oriented programming paradigm. Having clearly defined communication input and output forms, Intermezzo performs transition from input to output by additionally defining possibly Turing complete set of chaining production rules. This sort of arrangement also sheds light on Intermezzo from an angle of systems theory, thus broadening a possible range of use cases.
[References]
Wikipedia web site
That is beautifully presented and a subject area where I have done a lot of work. Code generation is a very useful technique and after completing a number of major projects with it I thought it would be useful to develop a generator for code generators. It took a lot of effort on and off over many years to build such a thing but I finally achieved it and experimented with some non-trivial applications of the technology. However in the end it seemed to have been not worth the effort because it was much more efficient to apply the meta-programming techniques that it took to get it to work directly to the problems that I was trying to solve.
If you are planning to pursue it further you should think in terms of graphs rather than acyclic graphs. Higher levels have to be able to introspect and summarise elements that are generated at lower levels. In other words, there needs to be feedback in the process.
(
COMPOSITE
(
INPUT
(
ELEMENTARY
TOP
<{"input": "start"}>
)
(
ELEMENTARY
TOP
<{"input": "less", "state": {"guess": "<Num>", "delta": "<Num>", "step": "<Num>"}}>
)
(
ELEMENTARY
TOP
<{"input": "more", "state": {"guess": "<Num>", "delta": "<Num>", "step": "<Num>"}}>
)
(
ELEMENTARY
TOP
<{"input": "equal", "state": {"guess": "<Num>", "delta": "<Num>", "step": "<Num>"}}>
)
(ELEMENTARY <Num> <1>)
(ELEMENTARY <Num> <2>)
(ELEMENTARY <Num> <3>)
(ELEMENTARY <Num> <4>)
(ELEMENTARY <Num> <5>)
(ELEMENTARY <Num> <6>)
(ELEMENTARY <Num> <7>)
(ELEMENTARY <Num> <8>)
)
(
CHAIN
// init
(
ELEMENTARY
<{"input": "start"}>
<{"output": "Imagine a number between 1 and 8. Is it 8?", "state": {"guess": "8", "delta": "8", "step": "1"}}>
)
// less
(
EQUALIZE
(ID (DOMAIN <Guess> <Num>) (DOMAIN <Delta> <Num>) (DOMAIN <Step> <Num>))
(
ELEMENTARY
<{"input": "less", "state": {"guess": "<Guess>", "delta": "<Delta>", "step": "<Step>"}}>
<{"output": "Is it <Guess> - <Delta> / 2?", "state": {"guess": "<Guess> - <Delta> / 2", "delta": "<Delta> / 2", "step": "<Step> + 1"}}>
)
// more
(
EQUALIZE
(ID (DOMAIN <Guess> <Num>) (DOMAIN <Delta> <Num>) (DOMAIN <Step> <Num>))
(
ELEMENTARY
<{"input": "more", "state": {"guess": "<Guess>", "delta": "<Delta>", "step": "<Step>"}}>
<{"output": "Is it <Guess> + <Delta> / 2?", "state": {"guess": "<Guess> + <Delta> / 2", "delta": "<Delta> / 2", "step": "<Step> + 1"}}>
)
// equal
(
EQUALIZE
(ID (DOMAIN <Step> <Num>))
(
ELEMENTARY
<{"input": "equal", "state": {"guess": "<Num>", "delta": "<Num>", "step": "<Step>"}}>
<{"output": "Got ya in <Step> steps!"}>
)
)
)
(
OUTPUT
(ELEMENTARY <1> <Num>)
(ELEMENTARY <2> <Num>)
(ELEMENTARY <3> <Num>)
(ELEMENTARY <4> <Num>)
(ELEMENTARY <5> <Num>)
(ELEMENTARY <6> <Num>)
(ELEMENTARY <7> <Num>)
(ELEMENTARY <8> <Num>)
(
ELEMENTARY
<{"output": "Imagine a number between <Num> and <Num>. Is it <Num>?", "state": {"guess": "<Num>", "delta": "<Num>", "step": "<Num>"}>
BOT
)
(
ELEMENTARY
<{"output": "Is it <Num> - <Num> / 2?", "state": {"guess": "<Num>", "delta": "<Num>", "step": "<Num>"}>
BOT
)
(
ELEMENTARY
<{"output": "Is it <Num> + <Num> / 2?", "state": {"guess": "<Num>", "delta": "<Num>", "step": "<Num>"}>
BOT
)
(
ELEMENTARY
<{"output": "Got ya in <Num> steps!"}>
BOT
)
)
)
I prefer ANNs or Direct hardware logic, to turing machines by a mile, heaps simpler, also universal.
2.2.1. semantic rhombus
Semantics of *Canon* is contained within composing two kinds of rules: forward and backward rules. The semantics of these rules may be described by a vertically split rhombus representing a complex forward rule as a whole on the left, and a complex backward rule as a whole on the right side. Complex rules are consisted of other complex or simple rules. Simple rules are made of two sides simply linked without any internal structure.Code: text---------------------------------- ----------------------------------
| | | |
| || BACK | | FORE /\ |
| || | | //\\ |
| || /| |\ //||\\ |
| || / \| |/ \ || |
| || / \ /| |\ / \ || |
| || / \ / \| |/ \ / \ || |
| || / | | \ || |
| || / FORWARD | | BACKWARD \ B || |
| || F / RULES | | RULES \ A || |
| D || O / | | \ C || A |
| E || R / \ / \ / \ / \ /| |\ / \ / \ / \ / \ K || B |
| D || W / \ / \ / \ / \ / \| |/ \ / \ / \ / \ / \ W || D |
| U || A / | | \ A || U |
| C || R CHAINING RULES | | CHAINING RULES R || C |
| T || D \ | | / D || T |
| I || \ / \ / \ / \ / \ /| |\ / \ / \ / \ / \ / || I |
| O || R \ / \ / \ / \ / \| |/ \ / \ / \ / \ / R || O |
| N || U \ | | / U || N |
| || L \ BACKWARD | | FORWARD / L || |
| || E \ RULES | | RULES / E || |
| || \ | | / || |
| || \ / \ /| |\ / \ / || |
| || \ / \| |/ \ / || |
| || \ /| |\ / || |
| \\||// \| |/ || |
| \\// | | || |
| \/ FORE | | BACK || |
| | | |
---------------------------------- ----------------------------------
The left side of the rhombus is depicting complex forward rule. It is containing arranged `forward rules`, `chaining rules`, and `backward rules`. The same side of rhombus is diverging branches from `BACK` node downwards, in a direction of forward rule, forming initial deduction tree. The same side of rhombus is also diverging branches from `FORE` node upwards, in a direction of backward rule, forming opposed abduction tree. The deduction and abduction branchings of the left side are required to be linked by the middle area of `chaining rules`, thus forming a complete inference system from `BACK` node to `FORE` node.
The right side of the rhombus is depicting complex backward rule. It is similar to the left side, only flipped upside-down.