What sort of library support have you found wanting? While the Prolog ecosystem is admittedly tiny compared to mainstream languages, I have often been surprised by the amount of useful libraries available.
I love Prolog syntax. I do think there is room for improvement, but the language is also extremely flexible, and it is very easy to roll your own syntax. Funny enough, so far my many experiments with alternative syntax have mainly had the effect of convincing me of the elegance and power of standard Prolog syntax.
While there is no particular reason the '.' should be used to terminate statements (except the resonance with many natural languages in this regard), I think some sort of terminator is necessary to keep the syntax as flexible as possible. Like Lisp, Prolog syntax is isomorphic to its AST. Currently my main gripe with Prolog syntax is that it represents conjunction and delimitation of predicate arguments and list items with the same operator, `(,)/2`. However, that can be fixed in two lines:
:- op(1000, xfy, user:(&)).
A & B :- A, B.
But I'm not sure it really needs "fixing"...
Regarding, "batching up a bunch of attributes into one conceptual 'thing'": SWI-Prolog has implemented a special data structure it calls "dicts"[dicts] for this purpose, but I am not very fond of it (and there's a fair amount of concern over the way this implementation breaks compatibility with ISO standards). More traditional solutions are to use lists of "pairs"[pairs], option lists[option], or, for larger data structures and when performance and lookup time is an issue, association lists[assoc] or records[records]. Using the first of these techniques looks like this:
It might be the case that Prolog's flexible syntax leaves it spoiled for choices here... That being said, it would be straightforward to implement syntax similar to your description, which evaluates and replace attribute accessors in place, using `term_expansion/2` and `goal_expansion/2`. Then you could use `As.baz` in place of the value itself (I've done so before, and this is what the SWI-Prolog's dict expansion does). Even easier, you could use Michael Hendricks' func package[func] to make a function for this purpose. But I've increasingly come to think of Prolog's explicit evaluation as a unique strength rather than a problem to be solved.
I definitely agree that the terminator is a good idea, just that "." happened to be an unfortunately historical choice since other languages used that character for a very different meaning.
Thanks for the links! These look extremely helpful!
Am in my daipers. Could you point me in the right direction in learning about querying prolog through JavaScript. Av read some documentation on Pengines but wud love some more example code.
I love Prolog syntax. I do think there is room for improvement, but the language is also extremely flexible, and it is very easy to roll your own syntax. Funny enough, so far my many experiments with alternative syntax have mainly had the effect of convincing me of the elegance and power of standard Prolog syntax.
While there is no particular reason the '.' should be used to terminate statements (except the resonance with many natural languages in this regard), I think some sort of terminator is necessary to keep the syntax as flexible as possible. Like Lisp, Prolog syntax is isomorphic to its AST. Currently my main gripe with Prolog syntax is that it represents conjunction and delimitation of predicate arguments and list items with the same operator, `(,)/2`. However, that can be fixed in two lines:
But I'm not sure it really needs "fixing"...Regarding, "batching up a bunch of attributes into one conceptual 'thing'": SWI-Prolog has implemented a special data structure it calls "dicts"[dicts] for this purpose, but I am not very fond of it (and there's a fair amount of concern over the way this implementation breaks compatibility with ISO standards). More traditional solutions are to use lists of "pairs"[pairs], option lists[option], or, for larger data structures and when performance and lookup time is an issue, association lists[assoc] or records[records]. Using the first of these techniques looks like this:
It might be the case that Prolog's flexible syntax leaves it spoiled for choices here... That being said, it would be straightforward to implement syntax similar to your description, which evaluates and replace attribute accessors in place, using `term_expansion/2` and `goal_expansion/2`. Then you could use `As.baz` in place of the value itself (I've done so before, and this is what the SWI-Prolog's dict expansion does). Even easier, you could use Michael Hendricks' func package[func] to make a function for this purpose. But I've increasingly come to think of Prolog's explicit evaluation as a unique strength rather than a problem to be solved.[dicts]: http://www.swi-prolog.org/pldoc/man?section=dicts
[pairs]: http://www.swi-prolog.org/pldoc/man?section=pairs
[option]: http://www.swi-prolog.org/pldoc/man?section=option
[records]: http://www.swi-prolog.org/pldoc/man?section=record
[func]: http://www.swi-prolog.org/pack/list?p=func