https://futureofcoding.org/ logo
Join SlackCommunities
Powered by
I've been working on tackling the chicken-egg prob...
# of-logic-programming
n
I've been working on tackling the chicken-egg problems of semantics, syntax, compilation, and system concerns (graphics APIs in a logic language!) by doing explorations in each of these areas in a cyclical fashion over the last year or so. I haven't really built much yet, because I haven't had a full picture of what needs to be built! I'm currently working on this project full time, on my own dime.
p
Sounds really interesting. Would love to have a look if you have written something in long form about what you are driving towards.
n
I haven’t written anything long-form, but I will eventually 🙂. I need to validate my ideas further first.
s
I'm really curious about what a graphics API might look like in a logic programming language. If I was going to do this I'd start with a software renderer that uses the logic programming language to fill a frame buffer, and maybe port a subset of it to run on a GPU (maybe generate a compute shader?). It seems hard to apply traditional graphics APIs (Vulkan, Direct X, OpenGL, Metal, etc) to logic programming. They are basically big state machines with imperative command execution. I'm not familiar enough with logic programming to know if I'm missing something though
n
@Scott Anderson My plan is to expose a declarative vector graphics API as the canonical API for 2D graphics. That should be pretty easy in a logic language: every line/shape is a fact. For 3D, we’ll need a different model.
Perhaps there is a more general solution than vectors, but declarative pixel-level rendering that compiles to GPU shaders seems unrealistic in the medium term.
s
Oh yeah I agree that it'd be a big undertaking and a bad idea to start with
Mostly speculating about what future evolution might look like, how you get more functionality while still keeping a declarative core
👍 1
w
If it's a graphics API that naturally fits with logic programming, the question for me becomes how to match logic programming constructs to the API naturally. Say, for illustration, we use predicates with the same expressive power as a SVG document:
Copy code
<!DOCTYPE html>
<html>
<body>

<svg height="100" width="100">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
  Sorry, your browser does not support inline SVG.  
</svg> 
 
</body>
</html>
Becomes something like this:
Copy code
svg(document).
height(document, 100).
width(document, 100).
in(document, c).
circle(c).
cx(c, 50).
cy(c, 50).
r(c, 40).
stroke(c, black).
stroke-width(c, 3).
fill(c, red).
Is this natural? Do the things you want to do with the document correspond to the constructs that the Logic language have?
Copy code
fill(S, red) :- bold-red(S).
stroke(S, black) :- bold-red(S).
stroke-width(S, 3) :- bold-red(S).
Maybe. That's promising. What would this mean?
Copy code
bold-red(c).
fill(c, blue).
Keep following this and you might discover some new features you want in your logic programming language.
💯 2
4 Views
Open in Slack
PreviousNext
Powered by