`member` usage about julog.jl

[hiiroo]

I just check the tests/lists, and member defined there as follows;

clauses = @julog [
    member(X, [X | Y]) <<= true,
    member(X, [Y | YS]) <<= member(X, YS),
    append([], L, L) <<= true,
    append([X | XS], YS, [X | ZS]) <<= append(XS, YS, ZS),
    reverse(X, Y) <<= reverse(X, [], Y),
    reverse([], YS, YS) <<= true,
    reverse([X | XS], Accu, YS) <<= reverse(XS, [X | Accu], YS)
]

and, a test case as follows;
resolve(@julog(member(banana, [avocado, banana, coconut])), clauses)[1] == true

It only works when member explicitly defined in the clauses. I thought it was a default feature?

[ztangent]

I believe member is a default feature of most variants of Prolog, but it's not implemented that way in Julog! Currently the only built-in predicates that Julog supports are those that can't really be defined as clauses (cut, apply, etc.). This could change in the future, but I would like to have a more modular and performant way for users to load libraries of clause definitions (as is done in Prolog), rather than building everything in.

[hiiroo]

I see, that's a good design approach. Actually, I was confused by the docs, where I read "member(b, [a, b, c]), are parsed in the same way as Prolog." I though member is there by default. I believe stating it explicitly could be better.

Other than that, loading user defined types could also be good. Such as units from Unitful.jl. So that constant can be defined with a generic type such as Constant{T} ?

using Unitful
using Julog
w = @julog [ meter(1u"m") ]

[ztangent]

Happy to change the README to make that more clear!

As for user-defined types like units, this is definitely possible if you manually construct constants using Const. However, the parser defined by the @julog macro doesn't really support calling other macros within it, and supporting this would take a fair amount of work. You're welcome to try and make that change if you would like!

(Note that making Const a parametric types seems to slow things down for some reason, so it's something I haven't done in this library.)

[ztangent]

Added the clarification to the README in 07bb2f1. I'm marking this issue as closed -- feel free to open a separate issue or PR to extend the parser to support user-defined types!