[m-dev.] Solver types paper didn't get in - referee's comments

[Ralph Becket]

The solver types paper didn't make it in.  Having read the reviewer's
comments, it's clear we need to rewrite the paper to be simpler, include
more explanation about Mercury, and focus more on issues such as purity
and reordering.  We also seem to have given the impression that solver
types are an evolution of HAL's approach, rather than a new method
arrived at in the light of the HAL experience.  And some of the
performance issues (many of them are fixed with the new Herbrand module)
need to be addressed.

I'll put it on my TODO list.

-- Ralph

----- Forwarded message from afelty at site.uottawa.ca -----

Subject: Your PPDP 2005 Submission (Number 25)
From: afelty at site.uottawa.ca
Date: Thu, 31 Mar 2005 07:57:45 -0800
To: rafe at cs.mu.OZ.AU
CC: afelty at site.uottawa.ca
X-Virus-Scanned: by amavisd-new at cs.mu.OZ.AU

Dear Dr. Ralph Becket:

I am sorry to inform you that the following submission 
was not selected by the program committee to appear at 
PPDP 2005: 

      Adding constraint solving to Mercury

The selection process was very competitive, and we could only
choose a small number of the submitted papers to appear in the
program.

Enclosed are comments from the reviewers of your paper, which 
we hope will explain their recommendation. 

Thank you for submitting your paper to PPDP. I hope that, with
the help of the reviewers' comments, you will be able to improve
your work for future submission.

Regards,
Amy Felty 
PPDP 2005 Program Chair

============================================================================ 
PPDP 2005 Reviews for Submission #25
============================================================================ 

Title: Adding constraint solving to Mercury

Authors: Ralph Becket, Maria Garcia de la Banda, Peter Stuckey, Kim Marriott, Mark Wallace
============================================================================
                            REVIEWER #1
============================================================================ 

                           Reviewer's Scores
                  -----------------------------------

                                 Ranking: B
                              Confidence: Y
                             Originality: 2
                      Technical Strength: 3
                            Presentation: 2
      Appropriateness to the conference:: 4


---------------------------------------------------------------------------
                          Detailed Comments
---------------------------------------------------------------------------

Abstract:
The paper adds constraints to the Mercury language and compare this solution
with the language HAL that was defined by some of the authors on top of
Mercury.
Some experiments and comparisons are given with HAL, prolog and the Mercury
with the defined extensions.

Comments:

The paper is complex and not easy to read. 
The paper is however elegant; the notions of memoing and references,
determinism, mode, module, construction/deconstruction, etc are used in the
paper and I really like it, but I'm not sure if all the audience would
appreciate the paper because of its complexity.

The other problem of the paper is that is not always clear what are 
the real improuvement to Mercury/HAL or what are the same ideas of HAL.
Sometimes we also wondering why HAL was not good enough to deal with constraint
in Mercury.
Why do not improuve HAL?

You use HAL syntax (and this is fine). It is not clear what is pure Mercury
language, what is the HAL extension and what is the extension of this paper to
Hal/mercury.

>From the performance point of view (tables 1 and 2) seems that your approach
is not so better than HAL ... 

page 5, 2nd column, row 11
of the the --> of the

Section 4
what are PARMA bindings? please explain

============================================================================
                            REVIEWER #2
============================================================================ 

                           Reviewer's Scores
                  -----------------------------------

                                 Ranking: B
                              Confidence: Y
                             Originality: 3
                      Technical Strength: 4
                            Presentation: 3
      Appropriateness to the conference:: 5


---------------------------------------------------------------------------
                          Detailed Comments
---------------------------------------------------------------------------

This paper presents the integration of constraint solving features
developed for the language HAL into the implementation of Mercury.
Since Mercury does not support unification or constraint solving
but requires variables to be ground or free at call time, partially
instantiated structures like in logic programming cannot be directly
represented. Therefore, the authors propose the integration of
constraint solving facilities into Mercury by defining two views
of constraints and constrained variables: an internal representation
in the form of ground terms that can be directly handled by the
Mercury compiler, and an external view visible to the user of
constraints that deals with variables and their constraints.
The main contribution of this paper is the introduction of this
concept and its integration with the Mercury compiler by casting
between these two representation so that it fits with the
Mercury concepts like reordering. Unfortunately, the problems
solved by the paper are very technical related to the
concepts of Mercury (pure, impure operations, promises etc)
that are not well explained in the paper. Thus, its contents
is only accessible to readers with a good background in the
specific features of Mercury and, thus, of limited value
to other declarative programming languages. The authors should
put more effort to make the paper accessible to a broad community,
since in its current form it is more suitable for a workshop
on Mercury where all participants are familiar with the specific
concepts of Mercury. On the positive side, the results might
be useful to turn Mercury into a real logic programming language
(in contrast to its current state as a functional language
with built-in backtracking).

Minor remarks:

P. 3: bewteen -> between

P. 3: "solution for a given input": Solutions make only sense for
predicates and constraints. Thus, you should use the word "value"
for the result of a function call.

P. 4: Explain the concept of impure and its consequence.

P. 5: Explain the concept of promise_pure and its consequence.

P. 5: Why is "get" a predicate and not a function?

P. 8, first paragraph of Sect. 4: Since the notion of "PARMA bindings"
is not standard, you should explain it or delete this discussion.

P. 11: What is the timing unit? sec, msec, minutes?

============================================================================
                            REVIEWER #3
============================================================================ 

                           Reviewer's Scores
                  -----------------------------------

                                 Ranking: D
                              Confidence: Y
                             Originality: 3
                      Technical Strength: 2
                            Presentation: 1
      Appropriateness to the conference:: 2


---------------------------------------------------------------------------
                          Detailed Comments
---------------------------------------------------------------------------

The paper describes an extension of Mercury logic programming language to
support CLP, and compares it to HAL, a CLP language compiled into Mercury.

I found the paper very hard to read, and its contribution is not clear
(although potentially interesting), which also complicates commenting. It seems
to be particularly hard to follow by readers who don't know Mercury or HAL
languages. For example, pure, impure and even semipure functions and predicates
are described throughout the paper, with no definitions of such notions. PARMA
bindings and other notions occur frequently with no explanations. Furthermore,
I did not find the code (omnipresent in the paper) declarative at all.

The 2 last (short) sections (results and conclusion), present some results that
are not better than others, and benchmarks are only given their names. Although
we can guess what most of them are, this is not always so. Also, the size and
iterations columns are not properly explained.

Strangely, table 2, which should show a comparison involving constraint solving
is composed of mathematical problems typically solved by known search-free
methods, not requiring constraint solvers.

----- End forwarded message -----
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------