Version 0.1.0
Praxis is [supposed to become] an online-IDE for Visual Programming in the Prolog language.
This is the introductory post, where I for the first time try to introduce and present it to the Prolog community.
The version that is currently available, though still not super-stable, has most of the basic abilities that I think are needed to introduce the overall concept;
- Visual modeling of Prolog rules, using a few basic shapes
- The ability to edit tabular data (facts) in an excel-like interface
- Ability to arrange pages containing the two above source-types in a tree-structure
- Saving and loading to local file-system
- Execution of model in browser, using Tau-Prolog
Features that are still labeled as “experimental”:
- Visual modeling of DCG-rules
- Including and using externally defined Tau-Prolog modules in your model
Let’s just have a look at an example
This example is available to try directly in your browser, right here: The Family Example
[RMB] + wheel = zoom
[RMB] + drag = pan
PS – NOT MOBILE FRIENDLY!
Basic rules in Praxis are constructed like this: A Predicate shape with no incoming connections ( = from above) are seen as the heads of rules.
Although not visible in this image, every shape that can be connected will show gray connection-disks when the mouse is hovering near it. Drag connection-disks to other connection disks where you wish to make a connection.
If there are connections going down from a head-shape, those will constitute the body of the rule. In order for a rule head/other node to be true, it is first matched/ checked for truth, and then all the shapes connected to it and under it are recursively queried for truth.
If there is more than one child, they are always evaluated from left to right. This also goes for the rules themselves.
The meaning of the default connection can be seen as “if the above shape is true, also demand that the below content is true” (but we will soon se that there are other ways of connecting shapes)
The generated code of the above rule will look like this:
sibling(SiblingA, SiblingB):-
parent(Parent, SiblingA),
parent(Parent, SiblingB).
PS – one of the first things on my to-do-list is to start parsing all the shape-input properly, into Abstract Expression-Trees (probably through Pratt-parsing), so it becomes easy to catch things like the singleton variables above.
Praxis does its best to be helpful, so it’s remembered that there is a rule named sibling/2, and lets us choose this directly from the rule-name combo.
PS – there are still shapes and other feature that I haven’t demonstrated, but this should do as a short introduction of the main ideas behind Praxis. More of the features (in different stages of completion) will be explored in other posts.
What is the point of it?
(this is a question I regularly get when trying to explain why I’m doing this, so let’s do this once and for all :))
Visual Prolog modeling is great stuff, and I miss working with it
Well, I’ve (oddly enough) spent a bunch of years working with a kind of visually formulated Prolog, and I found it surprisingly nice and effective – especially when the IDE is good enough. We were all commited Prologists, but after getting a visual IDE we didn’t touch a text-editor unless we could help it.
We were doing big things – thousands of rules – mainly to do with serious product configuration, or handling loan and insurance issues. The IDE, with its specialized search-capability, error-checking, clear display of logic, and other helpful features, were what made it all feasible and enjoyable in the long run. (This system is still in heavy use, and getting more customers as you read this – I believe a noteworthy percentage of scandinavian banks/ credit institutes are currently using it)
-I think the concept has a huge amount of potential for the future, and I’ve missed working with visually formulated Prolog. As we can see in the rules drawn in the above example, and the generated source-code, the textual representation is of course more succinct, but briefness isn’t all.
We have plenty of space to store data – what we need more of is things that help us handle complicated things, so they don’t overwhelm our brains.
Visual programming, overall, is a happening place, for good reasons
Visual programming seems to be getting a goodly amount of attention right now, and from my experience I would say that Prolog is a language that seems unusually well suited for visual formulation. (why I think so.. well, that’s another series of posts)
Another exanding area – where views are also widely split, is the world of Low Code-systems…
Of course – it’s easy to get overly enthusiastic about the potential for this, like ..practically every proponent of low-code systems have gotten, over that last half-century or so 🙂
Still.. new ideas and systems for this are continually being developed and put into practical use. Systems like Observable and its ilk actually seem to be fufilling some of the promise of making programming more accessible, and though flowchart-tools have gotten a pretty stale reputation, new Visual Business Process-modeling systems seem to be gaining more and more access to the inner sanctums of corporations.
To me it seems that Prolog (in many ways) would be an excellent language for doing systems like this – especially with the increasing tolerance for heterogenous stacks, as long as the systems can talk REST or similar.
Potential applications for Praxis (even in the short term) in this area can be things like:
- Make a generic Javascript UI-page that can display flexible forms that automatically let you interact with your Prolog model though normal web-UI controls (this is also great for testing and development)
- Make a generic REST-server-component where you can just “publish” your models, and they automatically present their exported predicates as endpoints.
(PS – both these things will be well served by a system for modeling with structured data through imported schema-files, which is one of the most important future features on my inofficial roadmap)
There are So many interesting things to do with this kind of technology
A thing I’m aiming for, overall, is to make rules as easy to formulate, utilize, understand and navigate as possible. Formulations can vary; visual rules (in drawings), or visual facts (in tables) – the common denominator is that the simplest and most easily understandable way possible of presenting and editing things is used, and that we can model things in representations that are the correct ones for the task at hand.
Other ways of formulating knowledge that Praxis could (and probably will) use:
- Hierarchical decision tables, for cases where that kind of reasoning is practical
- Visual directed graphs; in this paradigm we could specify the parent/2 -facts with viual entities named “jay” or “mitchell”, having directed parent-connections between them
Things on my immidiate roadmap
- Parsing of all Prolog statements into Abstract Syntax Trees; currently nothing is checked – this will make it easy to add a lot of warnings and error-messages
- Handling structured data by importing schemas. – When integrating with the outside world we’ll want to be able to speak their language, and that means being able to work comfortably with any kind of DTO they can throw at us. -This means we need “classes” with defined fields- at least for organizing data.
- Match-connections: Connect different fields in different shapes and matching the connected data. Will make it possible to (for example) have a predicate shape calling findall/3, and linking argument #2 to a branch of code that will constitute the executed contents of the findall-call. If carried to extremes, would make it possible to dispense with named variables entirely.
Well, I think that’s it, for now. This post was probably too long already a few pages ago 🙂
Hope you find this interesting, and that you feel free to ask me any questions or tell me any ideas that happen to pop into your head!