4 ms·

I had a similar observation about haskell's pattern matching when I was learning haskell: " Built in pattern matching - it's very convenient about programming s

by kanak 16y ago

I had a similar observation about haskell's pattern matching when I was learning haskell: " Built in pattern matching - it's very convenient about programming sometimes. Unfortunately for someone who learned Prolog before Haskell, Haskells' pattern matching will look very limited.First it doesn't allows me to repeat a variable in a pattern , second compared with Prolog, it's one sided. Big issue for someone used to full power of unification." I much prefer unification.

silentbicycle 16y ago
Same here. Unification rocks, though I think to have full unification rather than just pattern matching, the language needs logic variables first. (Right?) "Just" pattern matching is still great, though. FWIW, I'm working on a pattern-matching library for Lua. (tamale: http://github.com/silentbicycle/tamale http://github.com/silentbicycle/tamale) It uses linear search and backtracking rather than compiled decision trees at the moment, though I have the latter mostly done - there are a few failing tests for variable corner cases, though. (Maybe I'll get to them this weekend.) It allows repeating variables in patterns, too.
- drunkpotato 16y ago
  I've worked through some example problems in Prolog, and find logic programming to be an interesting way to think about a problem. I have a problem switching thinking between Prolog clauses as logic relations and thinking of them as a problem solving process. The towers of Hanoi problem mystifies me, for example. I also have trouble seeing how to use logic programming in a larger system, to get more than example problems done. Can you recommend a good resource?
  - silentbicycle 16y ago
    First off, you generally want code to read as much like logically valid relations as possible. A major strength of Prolog is that "clean" Prolog code is extremely easy to reason about with only local context. Chcek out _Clause and Effect_ by Clocksin and _The Art of Prolog_ by Sterling and Shapiro. CAE is sort of like _The Little Schemer_ for Prolog, but has a couple larger case studies as well. TAoP is one of my absolute favorite programming books - it's got as much substance as SICP. The newer edition (1994) is more expensive (though $35 used on Amazon ATM, which is a steal; it's usually more like $85-100), but adds quite a bit of new material. _The Craft of Prolog_ by O'Keefe is also good, though disorganized. (I think it was written as commentary on something else, and without that, its structure seems a bit arbitrary.) I mostly use Prolog for prototyping and exploratory programming. It would probably be more generally useful as an embedded language library, like Lua (another favorite of mine). It's a bit awkward as a fully standalone language, since things like IO don't always mix with backtracking. It's great as a rule engine, though, and would probably also be brilliant as a query language for a document-oriented database.
    - kanak 16y ago
      > "It's a bit awkward as a fully standalone language, since things like IO don't always mix with backtracking. It's great as a rule engine, though, and would probably also be brilliant as a query language for a document-oriented database." Fully agree. I'm learning prolog too, and it's really fantastic for the types of problems it was designed (e.g. resolving constraints and expressing relations), but I didn't enjoy doing IO in Prolog. My solution is to use lisp as my primary language and use an implementation of prolog-in-lisp (e.g. racketlog for racket). This way I have the best of both worlds.
      - silentbicycle 16y ago
        I would love to write a Prolog dialect designed primarily for embedding, much like Lua. I just have a half dozen other serious projects I should wrap up first. :/

by kanak 16y ago

silentbicycle 16y ago

Same here. Unification rocks, though I think to have full unification rather than just pattern matching, the language needs logic variables first. (Right?) "Just" pattern matching is still great, though. FWIW, I'm working on a pattern-matching library for Lua. (tamale: http://github.com/silentbicycle/tamale http://github.com/silentbicycle/tamale) It uses linear search and backtracking rather than compiled decision trees at the moment, though I have the latter mostly done - there are a few failing tests for variable corner cases, though. (Maybe I'll get to them this weekend.) It allows repeating variables in patterns, too.

drunkpotato 16y ago
I've worked through some example problems in Prolog, and find logic programming to be an interesting way to think about a problem. I have a problem switching thinking between Prolog clauses as logic relations and thinking of them as a problem solving process. The towers of Hanoi problem mystifies me, for example. I also have trouble seeing how to use logic programming in a larger system, to get more than example problems done. Can you recommend a good resource?
- silentbicycle 16y ago
  First off, you generally want code to read as much like logically valid relations as possible. A major strength of Prolog is that "clean" Prolog code is extremely easy to reason about with only local context. Chcek out _Clause and Effect_ by Clocksin and _The Art of Prolog_ by Sterling and Shapiro. CAE is sort of like _The Little Schemer_ for Prolog, but has a couple larger case studies as well. TAoP is one of my absolute favorite programming books - it's got as much substance as SICP. The newer edition (1994) is more expensive (though $35 used on Amazon ATM, which is a steal; it's usually more like $85-100), but adds quite a bit of new material. _The Craft of Prolog_ by O'Keefe is also good, though disorganized. (I think it was written as commentary on something else, and without that, its structure seems a bit arbitrary.) I mostly use Prolog for prototyping and exploratory programming. It would probably be more generally useful as an embedded language library, like Lua (another favorite of mine). It's a bit awkward as a fully standalone language, since things like IO don't always mix with backtracking. It's great as a rule engine, though, and would probably also be brilliant as a query language for a document-oriented database.
  - kanak 16y ago
    > "It's a bit awkward as a fully standalone language, since things like IO don't always mix with backtracking. It's great as a rule engine, though, and would probably also be brilliant as a query language for a document-oriented database." Fully agree. I'm learning prolog too, and it's really fantastic for the types of problems it was designed (e.g. resolving constraints and expressing relations), but I didn't enjoy doing IO in Prolog. My solution is to use lisp as my primary language and use an implementation of prolog-in-lisp (e.g. racketlog for racket). This way I have the best of both worlds.
    - silentbicycle 16y ago
      I would love to write a Prolog dialect designed primarily for embedding, much like Lua. I just have a half dozen other serious projects I should wrap up first. :/