I'm not sure what you mean by "statements" in Prolog as it's not a term the language defines. If you're referring to clauses, it's not true that execution is unordered: the Prolog interpreter attempts to unify a goal with clauses from the knowledge base in the order they appear. This ordering is semantically significant for control flow.
If instead you're referring to goals within the body of a clause, this is also incorrect. Goals are evaluated strictly left-to-right, and each must succeed before the next is attempted. This evaluation order is likewise required and observable, especially in the presence of side effects.
> the Prolog interpreter attempts to unify a goal with clauses from the knowledge base in the order they appear.
I was under the impression that when plugging holes during unification, that these statements/clauses could happen in any order just as you would like solving a crossword puzzle
Having been inside earlier this year, you would be doing yourself a huge disservice not visiting this IRL. Yes, the visual fidelity of this is amazing, but there are a lot of intangibles missing (i.e., the sonic resonance).
I think what you're getting has truth. For myself, I would generalize what you're saying as any given formula/expression is embedded in some context/environment. If one continues to "step back" or go one meta (or repeatedly so), you'll find that at some point, you, the reader/interpreter, will need to fill in some implicit or unreified context. We could call these things (shared) assumptions or axioms. As you say, if I use a function `f` to form a term in my formula written in first-order logic, the definition of `f` is implied because it is expressed "somewhere else". The question is then "where is that expressed?". Since the definition of `f` is assumed from the point of view (semantics) of first-order logic, the definition of `f` could be interpreted as "variable" at a "higher" level.
Going to your parenthesis point, I agree that it is indicating the scope (i.e., the context/environment), and in that sense, I interpret parenthesis here as a kind of meta function, akin to how macros are "compile-time" functions rather than "run-time" functions.
I think first-order logic and relatedly most (all?) logic programming languages are missing a facility for "reasoning" about terms themselves. The reflexive answer to this is types, but this is largely wielded as a developer tool not as a means of expressing meaning. Adding constraints to logic programming is perhaps some of the way there and has the benefit (hope) that type-like ideas could be expressed compositionally as logical formulas rather than as declarations provided by the language.
My own pursuit of this subject is to see if these "levels", as you hint at, can be traversed and integrated into one logical formula language and notation. This all implies some kind of homoiconic metaprogramming, but easier said than done.
Indeed, I feel like I'm reaching towards a generalized understanding of context.
It seems to me that unless the logical languages are restricted from reasoing about themselves they become either incomplete or worse, inconsistent.
I have a sensation that on the computer science side of things, unless "reasoning about terms themselves" is somehow 'handled' (restricted) one can end up with undecidable systems, or worse...
But I still have questions about complexity so I cannot really undesrtand how completeness and soundness realte to decideability.
My instincts say that you're saying something revelatory/insightful here, at least to me, but I'm not quite sure. Would you mind expounding, either with more context or more examples?
I think this is a good write up, but I think the notation is still carrying some mental baggage. It's not necessary to have these open and closed brackets/parenthesis. They don't add anything, and if anything, they confuse the matter. An interval is just (1, 2) (or [1, 2] if preferred aesthetically). Since a base cannot be "on" either 1 or 2, it's not meaningful to have these open/closed interval notion. In other words, (1, 2) == [1, 2) == (1, 2] == [1, 2].
Open/closed intervals only come into play in continuous dimensions. DNA sequences, arrays in memory, et al are discrete.
Fact Labs | Founding Engineer | San Francisco and New York (NYC) | Onsite or Remote (US only) | Full Time
Building models in spreadsheets is broken. Spreadsheet models break down when you alter them, modularize them, or add more collaborators. Analysts in banking, investment management, and operations have gotten by with spreadsheets but not without enormous time and effort spent hacking around their many limitations. Fact Labs has developed a more powerful, more collaborative modeling paradigm that is inspired by logic programming and applied ontology yet is still accessible to sophisticated but non-programmer analysts. We are a small, funded, early-stage team with significant domain experience with our target customers.
You would be working on the core engine and the surrounding components that make up our application.
What we are looking for:
- Strong CS fundamentals (algorithms, data structures, networking)
- Prior experience building software systems (network game, game engine, Web browser, database engine, etc.)
Experience in any of the following is a plus:
- Language design and implementation (parsers, interpreters, virtual machines, compilers)
- Database design and implementation (query planning, database/storage engines)
- Logic programming / optimization
Language experience:
- C++ is required
- Typescript / Javascript / Lua are plus.
- Any logic/constraint language, such as Prolog, Datalog, SAT / SMT, is a plus
The modeling experience we’re building is unlike anything out there. If you believe that spreadsheets are not the last word in end-user programming, reach out (stephen [at] fac.tt) and tell us a little about yourself (bio, resume, or LinkedIn). We’d love to hear from you and show you what we’ve been up to!
Fact Labs | Founding Engineer | San Francisco and New York (NYC) | Onsite or Remote (US only) | Full Time
Building models in spreadsheets is broken. Spreadsheet models break down when you alter them, modularize them, or add more collaborators. Analysts in banking, investment management, and operations have gotten by with spreadsheets but not without enormous time and effort spent hacking around their many limitations. Fact Labs has developed a more powerful, more collaborative modeling paradigm that is inspired by logic programming and applied ontology yet is still accessible to sophisticated but non-programmer analysts. We are a small, funded, early-stage team with significant domain experience with our target customers. The team previously worked together on a distributed search and data management startup and sold the company a few years back.
What we are looking for:
Fast, deliberate learners eager to translate concept into practice OR experienced hands ready to take significant design ownership
Strong computer science fundamentals, including algorithms and data structures
Experience with one of the following through professional, academic, or personal work:
- Optimization (constraint satisfaction, combinatorial optimization, linear programming, etc.)
Experience in the following is a plus:
- Database design and implementation (query processing/planning, database/storage engines)
- Language design and implementation (parsers, interpreters, virtual machines, compilers)
Language experience: any logic/constraint language (required), C / C++ (plus)
Self-starting attitude with strong communication skills (especially written)
The modeling experience we’re building is unlike anything out there. If you believe that spreadsheets are not the last word in end-user programming, reach out to us (stephen [at] fac.tt) and tell us a little about yourself (bio, resume, or LinkedIn). We’d love to hear from you and show you what we’ve been up to!
Fact Labs | Founding Engineer | San Francisco and New York (NYC) | Onsite or Remote (US only) | Full Time
Building models in spreadsheets is broken. Spreadsheet models break down when you alter them, modularize them, or add more collaborators. Analysts in banking, investment management, and operations have gotten by with spreadsheets but not without enormous time and effort spent hacking around their many limitations. Fact Labs has developed a more powerful, more collaborative modeling paradigm that is inspired by logic programming and applied ontology yet is still accessible to sophisticated but non-programmer analysts. We are a small, funded, early-stage team with significant domain experience with our target customers. The team previously worked together on a distributed search and data management startup and sold the company a few years back.
What we are looking for:
Fast, deliberate learners eager to translate concept into practice OR experienced hands ready to take significant design ownership
Strong computer science fundamentals, including algorithms and data structures
Experience with one of the following through professional, academic, or personal work:
- Optimization (constraint satisfaction, combinatorial optimization, linear programming, etc.)
Experience in the following is a plus:
- Database design and implementation (query processing/planning, database/storage engines)
- Language design and implementation (parsers, interpreters, virtual machines, compilers)
Language experience: any logic/constraint language (required), C / C++ (plus)
Self-starting attitude with strong communication skills (especially written)
The modeling experience we’re building is unlike anything out there. If you believe that spreadsheets are not the last word in end-user programming, reach out to us (stephen [at] fac.tt) and tell us a little about yourself (bio, resume, or LinkedIn). We’d love to hear from you and show you what we’ve been up to!
Fact Labs | Founding Engineer | San Francisco and New York (NYC) | Onsite or Remote (US only) | Full Time
Building models in spreadsheets is broken. Spreadsheet models break down when you alter them, modularize them, or add more collaborators. Analysts in banking, investment management, and operations have gotten by with spreadsheets but not without enormous time and effort spent hacking around their many limitations. Fact Labs has developed a more powerful, more collaborative modeling paradigm that is inspired by logic programming and applied ontology yet is still accessible to sophisticated but non-programmer analysts. We are a small, funded, early-stage team with significant domain experience with our target customers. The team previously worked together on a distributed search and data management startup and sold the company a few years back.
What we are looking for:
Fast, deliberate learners eager to translate concept into practice OR experienced hands ready to take significant design ownership
Strong computer science fundamentals, including algorithms and data structures
Experience with one of the following through professional, academic, or personal work:
- Database design and implementation (query processing/planning, database/storage engines)
- Language design and implementation (parsers, interpreters, virtual machines, compilers)
- Optimization (constraint satisfaction, combinatorial optimization, linear programming, etc.)
Language experience: C / Rust
Self-starting attitude with strong communication skills (especially written)
The modeling experience we’re building is unlike anything out there. If you believe that spreadsheets are not the last word in end-user programming, reach out to us (stephen [at] fac.tt) and tell us a little about yourself (bio, resume, or LinkedIn). We’d love to hear from you and show you what we’ve been up to!
If instead you're referring to goals within the body of a clause, this is also incorrect. Goals are evaluated strictly left-to-right, and each must succeed before the next is attempted. This evaluation order is likewise required and observable, especially in the presence of side effects.