Hello finally,
I see that there is a section in the Mozart-Oz documentation on
finite domain constraint programming. The natural language website
mentioned previously may offer a different slant. Finally, there is the CTM
book. Are there any other sources of information?
Also, the previous problem definition sounds like it entails some (in
my terminology) "composition" of choices and constraints. For example,
take the following production rules:
NEGATIVE := ~
DIGIT := 0|1|2|3|4|5|6|7|8|9
NZDIGIT := 1|2|3|4|5|6|7|8|9
INTEGER := (BEGATIVE)? NZDIGIT DIGIT*
There needs to be choices in the case of DIGIT and NZDIGIT. In INTEGER,
there needs to be a choice of whether to include the ~ and the number of
DIGITS that need to be supplied. The quantifiers for terminals and
nonterminals could be considered constraints in themselves. For example,
the zero or one quantifier would contain at least zero and at the most one
terminal or nonterminal, the one or more quantifier would contain at the
least one of either, and the zero or more quantifier would contain at least
zero of either. The upper limits for the zero or more quantifier and the
one or more quantifier could be set at some fixed amount.
INTEGER may then be used in an "upper level" production rule such that
an expression compiles. The compilation of the upper level production rule
places a constraint on what types of INTEGER need to be created. Similarly,
the INTEGER rule places a constraint on what combinations of NEGATIVE,
DIGIT, and NZDIGIT can be formed based upon whether it compiles. Could each
production rule involving nonterminals be viewed as a computation space,
creating a "tree" of computation spaces? To cut down the size of the
domain, the process could stopped at the first production rule with
nonterminals with examples supplied for that production rule. For example,
INTEGER could be restricted to ~1, ~23, 56, and 78.
The above loosely specifies the definition of the problem I am trying
to solve. I don't necessarily expect someone to provide a solution for me
since this problem is a lot of work, but any hints would be appreciated. I
think these comments sum up the postings I have been sending the mailing
list thus far.
Sincerely,
Craig
On 3/19/07, Craig Ugoretz <[EMAIL PROTECTED]> wrote:
Hello again,
I meant nonterminal instead of terminal in the discussion below. I
also meant 'production grammar' instead of 'function grammars'.
Additionally, I will investigating if Compiler.evalExpression can be used
to test whether "pieces" of a production grammar can be parsed as an
optimization instead of parsing the result at the end. I apologize for the
multiple posting - these ideas came to me over time.
Craig
On 3/19/07, Craig Ugoretz <[EMAIL PROTECTED]> wrote:
>
> Hello again,
>
> With more reflection, I think that I may be able to get the ideas
> I need strictly from the CTM book. Basically, using choice statements in
> functions I can generate a production grammar, using subsets of the values
> that the terminals can take on. Then, I can use whether those function
> grammars parse or not as a binary constraint. Finally, I can add an
> additional constraint that the generated programs be concise as possible.
> If I can not find any programs, it may be necessary to increase the number
> of values in each "terminal set".
>
>
> Craig
>
>
> On 3/19/07, Craig Ugoretz <[EMAIL PROTECTED] > wrote:
> >
> > Hello,
> >
> > I must say that I have skimmed the CTM chapters on relational
> > programming and constraint programming and I was just beginning to try to
> > understand the sample programs. However, I just located on the internet the
> > following website:
http://www.ps.uni-sb.de/~niehren/Web/Vorlesungen/Oz-NL-SS01/vorlesung/
> > . I am wondering at this point if the material contained within this
> > website could help me create what are termed "production grammars",
> > i.e. a scheme for creating combinations of terminals based on
> > production rules. In the case of what I want to do, I would want
> > combinations of terminals in the Oz grammar that compile into Oz programs.
> > I would, in particular, be looking for the shortest possible program (or set
> > of programs) that exercises all "paths" in the production rules of the Oz
> > grammar in order to test an external parser.
> >
> >
> > Sincerely,
> > Craig
> >
> >
> > On 3/19/07, Craig Ugoretz <[EMAIL PROTECTED] > wrote:
> > >
> > > Hello,
> > >
> > > I have an idea how to generate test data for a parser that I
> > > may need to create for a Java based parser generator. This process
> > > would involve using what I have learned about relational programming in
the
> > > CTM book. However, I am running into a problem with the program blocking
on
> > > the {Solve F} construct in a sample program that I have created. The
> > > program should print out the following strings: ab, ac, ba, bc, ca, cb.
> > > The code for the program is given below:
> > >
> > >
> > > declare
> > > fun {Pick} choice a [] b [] c end end
> > >
> > > fun {DiffPair}
> > > P1 P2
> > > in
> > > P1 = {Pick}
> > > P2 = {Pick}
> > > if P1==P2 then fail else P1#P2 end
> > > end
> > >
> > > fun {SolveAll F}
> > > L={Solve F}
> > > proc {TouchAll L}
> > > if L==nil then skip else {TouchAll L.2} end
> > > end
> > > in
> > > {TouchAll L}
> > > L
> > > end
> > >
> > > {Browse {SolveAll DiffPair}}
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Craig
> > >
> >
> >
>
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
