search

nikodemus / esrap

OLD REPOSITORY: Please go to:
https://github.com/scymtym/esrap
81 stars 25 forks source link

add EXPRESSION-CASE; simplify expression processing #18

Closed scymtym closed 11 years ago

scymtym commented 11 years ago

In the "grammar object" branch, I forgot to handle the new CHARACTER-RANGES in VALIDATE-EXPRESSION . Rather than just fixing that, I tried to address the problem of changing expression constructors more generally. The idea is using the EXPRESSION-CASE macro whenever dispatch based on expression constructors is needed. This way, we can check that all constructors are handled. It also simplifies the code.

Commit message:

add EXPRESSION-CASE; simplify expression processing

* EXPRESSION-CASE is a bit like CL:TYPECASE but clauses correspond to
  Esrap expression constructors. EXPRESSION-CASE ensures that all
  expression constructors are handled (unless there is a
  catch-all-clause) and that processed expressions are valid.

* INVALID-EXPRESSION-ERROR is a new error condition which is signaled
  when an invalid expression is encountered.

* CHARACTER-RANGE is a new type which simplifies validation of
  CHARACTER-RANGES expressions.

* *EXPRESSION-KINDS* is a new global variable which stores all
   available expression constructors and the corresponding types.

* Rename VALIDATE-EXPRESSION -> CHECK-EXPRESSION since it acts like
  CL:CHECK-TYPE. Unused function VALIDATE-CHARACTER-RANGE has
  been removed.

* In addition, use EXPRESSION-CASE in %EXPRESSION-DEPENDENCIES,
  %EXPRESSION-DIRECT-DEPENDENCIES, EVAL-EXPRESSION and
  COMPILE-EXPRESSION

* New tests: DEFRULE.CHECK-EXPRESSION, PARSE.STRING and
  PARSE.CASE-INSENSITIVE
nikodemus commented 11 years ago

Merged.

scymtym commented 11 years ago

Unfortunately, I improved EXPRESSION-CASE since the initial pull request and failed to update the pull request, sorry.

As I wrote to @kisp, this improvement and others are in scymtym/esrap@master. I'm not sure how we should proceed from here to resolve the situation.

nikodemus commented 11 years ago

One option would be declaring your repo the canonical one. :)

Alternatively, if you tell me which one I should merge instead I'll revert this and sort it out.

On 22 June 2013 16:21, Jan Moringen notifications@github.com wrote:

Unfortunately, I improved EXPRESSION-CASE since the initial pull request and failed to update the pull request, sorry.

As I wrote to @kisp https://github.com/kisp, this improvement and others are in scymtym/esrap@master. I'm not sure how we should proceed from here to resolve the situation.

— Reply to this email directly or view it on GitHubhttps://github.com/nikodemus/esrap/pull/18#issuecomment-19856691 .