rvirding / erlog Goto Github PK

We've got one for LFE and Luerl -- why not Erlog, too? 😉

@rvirding This page may prove useful: http://www.csplib.org/ it contains a library of 57 or so problems for constraint solvers, when you get started on the solver it might prove a useful refrence

It would be nice if we had a way to support JSON data, If you decode a json with JSX you get a data structure like this [{<<"test">>, 12345}], the problem is that if you try to pass that to prolog it thinks that the first element of the tuple is callable. When I ran this test https://gist.github.com/zkessin/52c96f8d5e6285497e8f I get this error:

json_test: json_test (module 'json_test')...*failed*
in function json_test:'-json_test/0-fun-0-'/1 (test/json_test.erl, line 10)
**error:{assertMatch_failed,[{module,json_test},
                     {line,10},
                     {expression,"erlog : prove ( ERLOG_STATE , { length , Data , { 'Len' } } )"},
                     {pattern,"{ { succeed , _ } , _ }"},
                     {value,{{error,{type_error,callable,{<<"test">>,12345}}},
                             {est,[],[],[],0,{db,erlog_db_dict,...}}}}]}

If you have a file like this example where there is not a trailing newline erlog will give you a compile time error about "Operator expected" when what it really wants is a \n at the end of the last line of code. We should make it ether just compile it without the \n or at least provide a more useful error message

%-*-prolog-*-

sum_to(1,1) :- !.
sum_to(N, Res) :-
    N1 is N - 1,
    sum_to(N1, Res1),
    Res is Res1 + N.

test(_File) :-
    sum_to(5,15).

Should we have a 2nd repo for contributions of code that use erlog and that might be useful but that are not part of erlog itself?

It might be a very useful way to boost erlog's use if we can have a library of things that are built with it and show cool ways in which it can be used

Provide a way for erlog to send and receive messages

It would be really nice to have an easy way create access to erlang records based on parsing a .hrl file. So you could take a record, and create accessor functions for it in prolog automatically.

Something like

include("my_header.hrl").

which will then take all the records from my_header and provide fuctors that can unify on specific fields.

To facilitate discussions about Erlog I have created a Google group https://groups.google.com/forum/?hl=en#!forum/erlog . Please join if you are interested in Erlog's future.

If people are going to write code we should provide a way to test it. As such we should have a unit test framework.

Ideally this would resemble the the test framework of swi as much as possible http://www.swi-prolog.org/pldoc/package/plunit.html

In order to make erlog really useful we need to make it so that it is easy to use erlog from erlang. What I am thinking is that what we want is to have a gen_server that can be called from erlang that implements prolog in that server.

What would be nice is that if given a prolog source file we could create this automatically (say with a rebar plugin)
The syntax here is similar to the export syntax of swi prolog
http://www.swi-prolog.org/pldoc/man?section=altmoduleapi

Here is my basic idea of what I am thinking, the problem is that if you want to do a query, where you put in a key and get out a value you need to tell the export which param is the input and which is the output, so that query/2 in prolog becomes query/1 in erlang

export_erl([add_to_model/2, query/2])

query(Key,Value) ->
      model(Key,Value).

add_to_model(Key, Value) :-
    retract(model(Key, _)),
    asserta(model(Key, Value)).

We should create an Erlog StdLib, with various useful things in it.

We should support maps as a data structure. SWI Prolog has a syntax for something similar (Dicts) http://www.swi-prolog.org/pldoc/man?section=dicts I think adapting it wholesale might be a good place to start, but lets talk about it

@rvirding

The functor arg/3 fails if the position argument is a 1, this works in SWI.

We should be able to do a consult/1 vs a path, so that things like standard libs can be put in central locations

We should create a halt/1 (or exit/1) predicate that will cause the current process to exit. So that an erlog program can be allowed to "let it crash"

halt(Reason).

There has been some discussion on how to develop erlog. Two issues have arisen:

• The basic API and whether to have a server interface or not, and if so what should it look like.
• The interface to the database.

My views on these are:

Erlog should only contain a basic local functional interface and no server interface. Users can write their own servers when necessary and choose which interface they want/need. The erlog interface should work at the erlang data level; users can build other interfaces on top of this, for example using the erlog parser to build a string interface.

The database interface should be abstracted out of the interpreter. My current idea is that there is a predefined function interface to the database and when you start the interpreter you give the name of the callback module to access the database. This would work in much the same way as OTP behaviours. This would allow using dict (the default) or ETS directly, or in a server, or a more complex system where different types of procedures are stored in different ways.

My reason for keeping both interfaces very basic is to make it easier for users to plug in specific code. There is no way that erlog can cater to all the different ways users may want to interface it so I feel it is better to keep it basic and provide support to extend it. Hopefully by keeping it basic we can make something everyone can use and specialise for their own needs.

(Should we have the discussion in the mailing list instead?)

We should have a web page for erlog!

Not sure, what is up, I was trying to write a simple test using this code

split(Head, Tail, HeadLength, FullList) :-
   length(Head, HeadLength),
   append(Head, Tail, FullList).

When I run it in SWI I get this, but in erlog it fails

?- split(H,T, 3, [a,b,c,d,e,f,g,h,i,j,k,l]).
H = [a, b, c],
T = [d, e, f, g, h, i, j, k, l].

We should have some form of module system for erlog

It would be nice to be able to have a prolog predicate listing/1 which will allow you to see the listing of a prolog predicate.

See Clocksin and Mellish p 125

Add ability to create user defined operations, part of the ISO standard

After executing a findall/3 then all the variables in the template are bound to the value they got in the last instantiation. They should be unbound afterwards.

I created an organization @erlog-core (@erlog was taken) it currently contains a clone of @rvirding 's erlog repo, I may add my readme file and turn on travis-ci for it later today

I would like to change the argument order in some of the functions in the erlog module, specifically move the state argument to last:

prove(State, Goal)  ==>  prove(Goal, State)
consult(State, File)  ==>  consult(File, State)
reconsult(State, File)  ==>  reconsult(File, State)
load(State, Mod)  ==>  load(Mod, State)
set_db(State, [Mod, ] Ref)  ==>  set_db([Mod, ] Ref, State)

This is more consistent with how state is handle in arguments in the rest of erlang. It is however not backwards compatible so I was wondering what people would think and react.

it would be nice to have a way of sending pragmas and directives to the parser

I just found a bug that cause erlog repl fail which the following error:

| ?- write('Hello World').
*** ERROR: Shell process terminated! (^G to start new job) ***
=ERROR REPORT==== 16-Oct-2019::15:00:00.684960 ===
                                                  Error in process <0.77.0> with exit value:
            {{case_clause,{error,tokens}},
                                           [{erlog_io,read,2,[{file,"src/erlog_io.erl"},{line,101}]},
                       {erlog_shell,server_loop,1,[{file,"src/erlog_shell.erl"},{line,42}]}]}