Here go two examples of how to use VarLenList (defined in a previous
message of mine) and get the effect you seek:
fun {YourAll1 L P}
{FD.distribute naive [{VarLenList L}]}
{List.all L P}
end
proc {YourAll2 L Min Max P}
Len = {VarLenList L}
in
Min =<: Len
Len =<: Max
{FD.distribute naive [Len]}
{List.forAll L P}
end
Here you already see some Constraint Programming (CP) in play.
You'll greatly benefit from learning CP. As for parsing, it depends on
what you really mean to do with it: plain logic programming workout,
treating artificial or natural language, etc. For artificial
languages, consider using gump. Also remember that Oz allows for lazy
evaluation, so it must also be possible to implement parsing using
functional (parser) combinators (google "parsec Haskell").
Cheers,
Jorge.
2009/7/30 Гилмуллин Рушан <[email protected]>:
>>First of all, it is worth noticing that
>>it looks a bit strange to have this predicate return a boolean, as
>>more usual logic programming would simply fail when not all elements
>>satisfied the given predicate. This usual interpretation would very
>>straightforwardly be implemented as:
>
> The problem of using this predicates in clause is that it is not
> nondeterministik. For example it is not possible to find
> all variants of lists that has Predicate=true on his elements. Yes, the
> number of such lists are infinite, but if there
> are some other criteria, the system choose only some variants from infinte
> number of variants that match this criteria. I
> think. that the problem is in this moment: the enumerating of variants list
> match the All predicate take many time. I had
> no time to check this on this week, but today evening I check this
> supposition by limit the list length that match to All
> predicate by some small number (which will be small but enouth for right
> matching).
>
>>If (i) is not known, you might resort to the following:
>> <some coide skipped...>
>
> Thank for code. Today I don't understand this code, I must to think about it
> some time.
>
>>Well, maybe by now you are beginning to see why Mozart does not offer
>>a high-level logic library. That's because there are various ways to
>>get stuff done, usually better efficieny-wise than the plain Prolog
>>style.
>
> I begin doubt in full enumeration approach of calculation such Prolog. Peter
> Van Roy say that it is preferable to use
> constraint programming that don't enumerate the all possible solutions, but
> first cut don't possible solutions and only
> after cutting enumerate. This look very intresting, but ist's possible to use
> this mechanisme for parsing text? I think
> that this work only for integer inequalities.
>
> _________________________________________________________________________________
> mozart-users mailing list
> [email protected]
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
>
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
