"Hello, World!"w

Hi Fatalize!

oh hi

so, yeah about that CLPFD inclusion

The main problems I have are on labelling and floating arithmetic

If I modify Brachylog so that everything uses CLP, I'm screwed on float arithmetic aren't I?

As for labelling the main problem I have is on the place where I need to call label/1

e.g. X #> 2, label([X]), X #< 5. doesn't work but X #> 2, X #< 5, label([X]). does

and I'm not sure I can easily find the proper point in a Brachylog program where one variable can be labelled

So I would have to use an explicit call to label things, which loses bytes

first, float would require different operators (which it also currently does: compare CLP(FD) and CLP(Q) syntax).

For labeling, you can simply label everything implicitly at the end!

I would do it like this: wrap the whole Brachylog execution into a call of call_residue_vars/2. This yields the list of variables that are still involved in constraints after the goal has finished.

Then, filter the CLP(FD) variables from that list, using include(fd_var, Ls0, Ls).

And then,simply label all remaining CLP(FD) variables automaticall. This is always a valid operation to do.

Hmm

Let's say a Brachylog program translates in Prolog to

X #> 2, X #< 5, write(X).

I would have to label X before printing

that would be doable I think. use an implicit labeling/2 before side effects.

you will certainly have to analyze the given program in some way, but I think it would be doable at least for a very useful subset of programs.

even better of course would be a way to integrate side-effects in a purer way, maybe you can come up with something very interesting for this.

hmm I'll see

in any case, there are several possible solutions for this. One is make an explicit labeling also avaiable. another is to have special primitives for writing.

the thing is the Java code I made sucks balls (I made up the grammar on the spot for Brachylog), I don't have much time available, and I'm not a Prolog programmer in the first place

so I might do it but it's a big might :p

But thank you anyway for the insightful answers

Java code sucks balls in any case, so one remaining recommendation I have: if possible, use Prolog to either translate or interpret the Brachylog code. A DCG might be useful for parsing the program and obtain a syntax tree, and once you have that available, further analysis is a lot easier to do in Prolog. So, I hope this helps, and I'm very interested in seeing what you will come up with. Enjoy!

well I thought about doing everything in Prolog initially

the main problem is I'm bad at Prolog :p

so that would take me ages

that's OK. everything that's worth learning takes ages.

well yeah but this on my free time so.... :p

that's OK ;-) one day you may be able to learn a living from these new abilities. So, have fun, and thank you for sharing many interesting snippets!