Some ideas for the Future

If logic programming is the future then what is the future of that future? Here are some things that weren’t included in Cosmos due to it being a prototype.

Objects

An object system that allows tables to be used as prototype-based or class-based objects and have the type system recognize them, aswell as defining interfaces. This is planned for the next version of Cosmos.

Modes

Cosmos could have a mode system. The mode system would be highly simplified in comparison to Mercury (another functional logic language). It would be consist of void, bool, rel and fun.

The BOOL annotation is for relations that have no output parameters. One might call them to check whether they are true or false. VOID relations are only used for side-effect; they have no output parameters either. FUN relations are meant to be used as regular functions (such as the ones in imperative and functional languages). They could have checks to ensure that it’s being used as a function (only BOOLs are inside IFs, the last parameter is output and the others are inputs etc). REL is the most general one; it would allow anything.

Negation

Negation in Prolog doesn’t act as one would expect. They do what is called negation-by-failure. A not keyword would ideally (1) Act “logically”. (2) Do what a programmer from an imperative/functional background would expect.

A proposed solution for Cosmos is to turn NOT into a syntax sugar… that is only allowed inside of IFs.

if(not p())
 z()

See that code? A naive solution would be to give in to side effects and use negation-as-failure. We could instead turn it into the pure logical code below.

if(p())
 true
else
 z()

Similarly…

if(not p() or q())
 A()
else
 B()
 
// … could be translated to …

if(p())
 if(q())
  A()
 else
  B()
else
 A()

+=

It is a widely known fact that what really makes functional and logic programming different from imperative programming is the += keyword. Adding that, perhaps along other syntax sugars, will finally unify logic, functional and imperative programming.

rel update(Table o, Table o2)
 o.x += 1
 o2 = o

What makes this declarative is that the above code doesn’t modify o. That is the reason we needed the parameter o2. The dot and += are syntax sugars, and by removing them we get this:

rel update(Table o, Table o2)
 table.set(o, ‘x’, o.get(o, ‘x’) + 1, temp)
 o2 = temp