Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to get changes in scryer's fork? #28

Open
jeshan opened this issue Jan 20, 2024 · 7 comments
Open

How to get changes in scryer's fork? #28

jeshan opened this issue Jan 20, 2024 · 7 comments

Comments

@jeshan
Copy link

jeshan commented Jan 20, 2024

Currently, I'm using clpz with sicstus and not scryer. I see that there are many enhancements being done in the scryer fork but not in this repo.
https://github.com/mthom/scryer-prolog/pulls?q=is%3Apr+clpz

I understood that it's because of the differences in sicstus and scryer implementations. Is there anything the community/ @triska can do to align both versions?

@triska
Copy link
Owner

triska commented Feb 3, 2024

@jeshan: Yes, I would greatly appreciate your help with porting newer developments from Scryer Prolog to the SICStus version!

I think a good way to do this would be a series of commits that correspond to the ones available in Scryer Prolog, and maybe even reference them. You can do this for example for the commits you find most relevant or interesting and which can easily be ported in this way. I think this would be a good starting point.

Another good approach would be to reduce the existing differences between the versions in a way that can be easily seen to be correct. For instance, one could start with lines that are comments in both files, and have one commit that reduces the differences between these comments in the source code.

Yet another approach could be useful for differences that arose only due to early limitations in Scryer Prolog that now no longer exist. For instance, at some point during its development, Scryer Prolog did not yet support the discontiguous/1 directive, and so I had to move clauses around to make them contiguous. Obviously, Scryer Prolog has now far surpassed this stage, and such a difference between the two versions is now no longer needed. This is an example where maybe the Scryer version could more closely follow the SICStus version again, if it is indeed preferable to keep the clauses discontiguous in the source code.

Thank you a lot to everyone who is interested in helping with this! If you have any questions, please let me know any time!

@UWN
Copy link

UWN commented Feb 4, 2024

This particular PR does not include all the improvements that happened in Scryer so far. As an exemple:

| ?- X #= sign(-10).
! Domain error in argument 1 of user:unknown/1
! expected clpz_expression, but found sign(-10)
! goal:  unknown(sign(-10))

whereas in Scryer:

?- X #= sign(-10).
   X = -1.

@triska
Copy link
Owner

triska commented Feb 4, 2024

No PR is being filed here, this issue is the discussion about how to best synchronize the versions. A PR could be a result of this discussion.

@jeshan
Copy link
Author

jeshan commented Feb 5, 2024

Understood. I guess it will have to be manual changes for a long while: I'm hoping that someday we'll have only 1 file to change!

@UWN did you intend to comment on issue #27 and not issue #28 ? Even so, I think #27 is for a different subject. Let me know so I look into it.

@UWN
Copy link

UWN commented Feb 5, 2024

See my other comment. To me, it all looks the same...

@triska
Copy link
Owner

triska commented Feb 5, 2024

I have one general comment for porting changes: The focus should be on the commits that went into Scryer Prolog, not the PRs! That is: To port a commit that went into Scryer Prolog, it would be best to reference the commits by their hash and/or copy their descriptions, and maybe optionally also reference the PR (if there is one), because it may contain interesting discussion etc. But the commits are what counts because they are permanent, whereas PRs only make sense as long as Github exists.

@triska
Copy link
Owner

triska commented Feb 5, 2024

(It is OK to reference multiple commits in a single commit, if it makes sense to port the commits as a unit!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants