Almost a year ago, I announced my Prolog HTTP2 client; however, it has an API very different from that of the standard http_open/3.
I finally had some time to come back to this, so I’ve tried to make a wrapper to make it act a little more like the standard library. I would love some comments/feedback on this; either on the design of the wrapper, or the library itself.
I would love for this to be able to be part of the standard library too, but it uses some libraries, particular pack(delay), pack(list_util) and the reif library, so I’m not sure how feasible that would be without re-writing all that stuff.
This opens an old topic: how do the packs relate to the core system? As is, many of the packs build a parallel universe to the core libraries. In some parts this universe overlaps. In some parts it provides similar predicates with using different (naming) conventions, I assume often inherited from older traditions and quite a few provide a more pure approach using lots of attributed variables based functionality.
How should this work? Should the pack world remain a separate world? Should we establish some sort of mechanism to migrate popular basic extensions to the core system?
Just adding my thoughts here in case others have the same but are hesitant to say so.
Currently I view the packs as something that might be nice to use, but that have to be used with extreme caution as the creator(s) may no longer be supporting the code and the documentation may be very thin to non-existent. Also as Jan W. notes, many of the packs build a parallel universe to the core libraries.
When I pull in a library I tend to believe that it has more support and documentation form the creators or Jan W. if needed and that if I were to use it there is a good chance if I run into a problem it can be fixed or explained.
If that understanding is not true please correct me.
As example of one package I am interested in using but am unable to get a response from one of the authors is Package “type_check”.
I guess it depends on the pack (author). But yes, one of the (many) reasons for introducing packs was to have a place for stuff that is poorly documented, non-portable and/or for which sustained support was deemed needed but not guaranteed.
With regards to this particular package, I think I could re-write it without other dependencies – I’m just using delay and reif in the HTTP2 frame-parsing code, to let me write one DCG for each frame type that works in either mode…mostly as a challenge for myself, but honestly it might make more sense & would be much simpler if there were just two DCGs per frame, one for each direction.
My understanding is that the protocol itself is almost the same, the difference between mainly that HTTP2 is over TCP and QUIC/HTTP3 are over UDP, so this library should serve well for that as well.
I’ve not seen many good real life examples for bi-directional DCGs. It it really hard to control non-determinism and doing so it typically crucial for performance and resource management.
Yeah…I know I should re-write it at some point, it was really just an exercise for me to figure out how to do so. I just find the bidirectional DCGs aesthetically pleasing. I can try doing that over the next little while & see if I can get it all working without any pack dependencies.
A feel the need to rant about the tendency of programming languages to create a Tower of Babel of duplicate web application development libraries. What brought this about was my struggling to learn how to do this in Erlang, and not understanding how the inets package in its standard library fitted in with third-party packages like cowboy.
Anyways, my view is that cluttering languages with lots of synonyms creates lots of confusion, and the more minimal a language, the better.
Inevitably the traditional ways of doing things may be wrong, and get replaced by something better, with the old way kept for backward compatibility. The SWI Prolog documentation is good in that these cases are usually clearly marked with deprecated.
Ideally, one should be able to improve things using the existing interface – the problem in the web application development world is nobody seems to standardise their interfaces and keep them from version to version.