Are we reading the same cKanren code? I'll give you that the matches
definition is declarative, but then read checko and subchecko. They
are all about (recursive) control flow. Where does the specification
say anything remotely close to the checko and subchecko relations? In
contrast to this, the Python set comprehensions have minimal control
flow. Yeah, the standard Python implementation has a certain order of
executing the comprehensions, but so does the cKanren implementation
when executing the predicates. My Python program doesn't depend on
this order: it just uses declarative descriptions of sets as set
comprehensions.
Just being written in cKanren doesn't make a program declarative. If
you write a C interpreter in cKanren and then write your actual
program in a literal string, that doesn't magically make the program
declarative even though it is a cKanren program. Similarly, checko and
subchecko don't describe the problem in a declarative way. Compare
this with the Python valid() function: the set of possible weights you
can make has to be a superset of {1..40}. Again, declarativeness is a
property of programs, not languages. Some languages make writing
declarative programs easier, of course. cKanren is supposed to be such
a language, so it would be neat to see a more declarative cKanren
program for this problem.
Also, I don't see how "one stone should weigh 1lbs" is part of the
specification. Now, it is true that the answer happens to have one
stone equal to 1, but how is that part of or trivially follows from
the specification? We might as well hard-code the whole solution.
Jules
On 12 nov, 00:49, Timothy Baldridge <tbaldri...@gmail.com> wrote:
> > My Python code is much more declarative than the given
> > cKanren code in that regard. Just
> > compare:http://dosync.posterous.com/another-taste-of-ckanren
>
> I don't think you understand what declarative programming is at its
> core. Declarative programming
>
> To borrow from the ever-present wikipedia:
> "declarative programming is a programming paradigm that expresses the
> logic of a computation without describing its control flow.[1] Many
> languages applying this style attempt to minimize or eliminate side
> effects by describing what the program should accomplish, rather than
> describing how to go about accomplishing it.[2] This is in contrast
> with imperative programming, which requires an explicitly provided
> algorithm." (see: Declarative Programming)
>
> This is where the cKanren code succeeds where the Python code fails.
> The Python code is all algorithm, and no facts. While the cKanren code
> is a direct implementation of the facts about the problem: one stone
> must be 1lb all stones should equal 40lb, etc. The cKanren code leaves
> the interpretation of these facts up to the logic engine, while the
> Python code sets strict guidelines that the compiler must follow. If,
> for instance, it was faster for a given computer to count down from
> instead of counting up, the Python code would run much slower, by
> defining the algorithm (by using range, and for loops), you're
> restricting the interpreter to your view of how to solve the problem.
> The cKanren compiler/interpreter/whatever is free to solve the problem
> in any way it pleases, as long as the requirements (facts) are met.
> The original problem states "find 4 numbers that equal 40 but a
> combination of any of which can be 1 through 40" it says nothing of
> range sequences, for loops, etc.
>
> Timothy
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
