Interesting, but I’m a bit overwhelmed by the presentation of three different languages at once. Suppose I have a scheduling problem; could I use fleng to obtain feasible schedules, and would it be the right tool for the job?
PaulHoule 9 hours ago [-]
I am excited to see that it can get customized over several dialects.
In the Japanese 5th generation project they thought they could parallelize Prolog but found out early on that Prolog could not be parallelized so they came up with KL1 which could be parallelized but is not as nice as Prolog.
I'd love to have a "language construction set" where I could trade off expressiveness and efficiency and such.
My take on facts and rules is that they are somewhat portable between different regimes. For instance the same set of rules can work well in a forward chained mode as in a RETE rules engine or in a backward chained mode using Prolog or even in an SMT solver for consistency checking.
I call it "rules and schemes" where you reuse the same rules with different execution strategies to solve different inference problems. In fact you want it to be easy to move work between build and run time.
sinuhe69 5 hours ago [-]
For scheduling and other classic constrained optimization problems, I think language like Zinc or Picat are the best. They are quick to learn and you can have the result in no time.
Avshalom 10 hours ago [-]
I think probably no, it seems to be more of a lowest-common-denominator/intermediate-language to be compiled-to. Strand or FGHC could be right-tools however (well except being extremely niche languages)
nikolay 13 hours ago [-]
[flagged]
atulvi 12 hours ago [-]
He's probably hosting this on a server written in assembly running on a boat in the Pacific ocean running on solar panels.
In the Japanese 5th generation project they thought they could parallelize Prolog but found out early on that Prolog could not be parallelized so they came up with KL1 which could be parallelized but is not as nice as Prolog.
I'd love to have a "language construction set" where I could trade off expressiveness and efficiency and such.
My take on facts and rules is that they are somewhat portable between different regimes. For instance the same set of rules can work well in a forward chained mode as in a RETE rules engine or in a backward chained mode using Prolog or even in an SMT solver for consistency checking.
I call it "rules and schemes" where you reuse the same rules with different execution strategies to solve different inference problems. In fact you want it to be easy to move work between build and run time.
Open link in incognito to avoid the comical HN referal block.