4 ms·
Yeah I've had the same questions for a while. What specific concrete problem can you solve with this, that does not have as-good solutions available in any lang
by giraffe_lady 4y ago
Yeah I've had the same questions for a while. What specific concrete problem can you solve with this, that does not have as-good solutions available in any language powerful enough to easily implement it?
I am kind of half-considering it for mud scripting? Each line from the mud represents a fact or relation so this could be used to query for specific information as needed.
For this case though, it doesn't really seem better than writing a regex-based DSL though, something I'm far more familiar with and that is better supported.
- ModernMech 4y agoLogic languages are great for expressing database queries, so you can treat your program like a database. And if your program is a database you can do database-y things on it like using transactions to "rewind" the program state. Or in the context of distributed programming, well... distributed databases are a thing, and we know how to handle updates to databases in that context, so writing your distributed logic program is as easy as forming a series of database queries, and you can let the DBMS do the magic of distributing it. I guess I think of logic languages as SQL but I actually want to write my whole program in it.
- rscho 4y agoConstraint programming. Everyone will tell you that C++ and Java solvers are so much faster. That's true, but prolog for example is incredibly easy to use in comparison, and in fact not that slow. So if you're prototyping or aiming for something exotic that doesn't easily fit into existing libs, LP will be miles ahead. Generally speaking, you'll see the same pattern for any problem involving searching a space of potential solutions. In a word, the strength of LP is flexibility when facing the unkown (future feature requirement). EDIT: you mention parsing. If you're planning anything context-sensitive, you have to check out eDCGs. You probably won't use them, but they'll give you an idea of what's possible.
- giraffe_lady 4y agoAhhhh this is extremely helpful, thank you. I've been puzzling at the mud parsing thing because while it's in the shape of natural language (and somewhat annotated in it eg there is spurious "decorative" information), it does represent a 1:1 mapping with computation already. This feels like a much better path than trying to get it into an AST with like yacc or whatever. But since it isn't actually natural language NLP didn't seem right either. I've got a lot of reading to do but this is very interesting.
- YeGoblynQueenne 4y agoI started a comment about DCGs also before seeing rscho's and mncharity's comments above which covered it. If you're going to do any parsing, I don't think there's any better tool than DCGs. It blows my mind that everyone is still trying to kludge their way around regexes instead, when there is such a better tool around. Your mud language is probably a "Controlled Natural Language", btw: https://en.wikipedia.org/wiki/Controlled_natural_language https://en.wikipedia.org/wiki/Controlled_natural_language Game languages often are.
- mncharity 4y ago> you have to check out eDCGs. https://github.com/kamahen/edcg https://github.com/kamahen/edcg , https://occasionallycogent.com/prolog_edcgs/index.html https://occasionallycogent.com/prolog_edcgs/index.html
- mncharity 4y ago> You probably won't use them, Curious - I fuzzily recall usually ending up manually threading state (eg, doing a Perl-Compatible Regular Expression engine (apropos "why LP?" - it was just a page of code, with good performance)), but I don't recall what drove that decision...
- deleted 4y ago[deleted]