parser-redesign.org 3.5 KB

Why?

Current Pipeline

Issues

Solution - New Pipeline

DONE 1. Fetching

DONE 2. Processing

What is a proper parameter alist?

Steps for Processing

Validating the Resulting List new

DONE 3. Overriding

Fetching All Parameters

Only keeping PLIST values whose car is in the ALL-PARAMETERS list

The remaining values are added at this step

Method for adding new

DONE 4. Funneling new

The Steps

DONE 5. Validation

DONE 6. Final Output

    The current parser design needs to be changed in a few places to accommodate enumerated parameters. Furthermore, the current processing pipeline is making mistakes while reading negated parameters. RESOLVE-PARAMETER-ALIST takes a PSPEC and a PLIST, then overrides the PLIST according to PSPEC after which the overridden PLIST is validated. Previously, we didn't have syntactic sugar in the form of "p!" and "_". This processing is happening in multiple places, which is causing problems. First, we will fetch the base parameter alist of the PSPEC. This will reuse the old functions with slight modification. Both the base parameter alist and the PLIST will be processed to convert syntactic sugar into a proper parameter alist. Again, the same function will be used with a few small changes. A proper parameter alist is one of the form ~'((PSYM VAL) (PSYM VAL) ...)~ where the ~PSYM~ is not of the form ~sym!~ and the ~VAL~ is not of the form ~_~ or ~!~.
  1. (CHANGED) PSYM of the form p! will throw an error if they are in a cell,
  2. return ~(p . %match-none)~ otherwise.
  3. PSYM are turned into cons cells of the form (PSYM . %match-any)
  4. (list PSYM VAL) are turned into (PSYM . VAL)
  5. Syntactic sugar in VAL is first converted to %match-any and %match-none.
  6. (NEW) Contraction: if many PSYM match, we will first remove duplicates.
  7. more than 2 remain: DUPLICATE error is thrown.
  8. 2 remain, one is ~%match-any~: the value becomes the other value
  9. 2 remain, none is %match-any~: ~DUPLICATE error is thrown.
  10. The resulting list will be validated at this phase itself. This is done at step 5 of processing through the contraction. The function fetching all parameters works fine. No changes are needed. In the future, it might be worth getting dependency parameters too.
  11. negation is supported: %match-none is added
  12. negation is NOT supported: %match-all is added
  13. This is a new step in the process where ~%match-any~ and ~%match-none~ values will be converted to proper values in steps.
  14. SUB-PLIST~: the sublist of ~PLIST with cons cells whose cdr is either %match-any or %match-none.
  15. %match-none~: all the ~%match-none are converted to the proper negated values. If negation is not supported
  16. REQUIRED~: first and foremost, the ~REQUIRED values are funneled.
  17. ~ONE-OF~: for the remaining values, the default (first) value is tried first.
  18. Binary types are put into an "inactive" list, while the remaining are permuted until a satisfactory value is reached.
  19. RE-COMBINATION~: ~PLIST* = SUB-PLIST* + SUB-PLIST'
  20. The final ~PLIST~ is checked for ~LOGIC~, ~DUPLICATION~ and ~COVERAGE~. The same procedures can be used but with some functionality removed. If the complete ~PLIST~ fails the final validation check, an error will be signaled and the base parameter alist will be returned. Otherwise, the final ~PLIST~ is returned.