KappaTools icon indicating copy to clipboard operation
KappaTools copied to clipboard

%def: "syntaxVersion" "X" is not documented

Open hmedina opened this issue 7 years ago • 4 comments

The user manual, table 5.1, contains no mention of this user-defined parameter.

E.g. are the quote marks mandatory 4 vs "4"? Can one use lowercase v3 rather than uppercase V3? Is there a 4.1-beta syntax yet?

hmedina avatar Jan 16 '18 20:01 hmedina

Addendum, this option was present in KaSim3, but does not seem to be present in KaSim4. Have we abandoned its use in favor of the command line specification? If so, why don't we allow models to specify what syntax they were written in?

hmedina avatar Jan 16 '18 20:01 hmedina

%def: "syntaxVersion" "X" has indeed disappeared.

In the early days of Kappa 4 syntax syntax 3 and syntax 4 symbols were close enough so that you wrote one parser to recognise both and 2 symbol interpreters. That allowed to look inside the recognised-not-yet-interpreted symbols for a "syntaxVersion" parameter and choose the symbol-interpreter accordingly. Syntax have now diverges way too much to allow to write a symbol recogniser for the union of them. Therefore, I had to write 2 completely independent parsing chain. The drawback is that when it starts to read the input files, it has already choose in which version it read sand it is too late to read that information in the file!

pirbo avatar Jan 17 '18 09:01 pirbo

Would it be possible to try syntax 4, and then apply syntax 3 if syntax 4 has failed?

Cheers. Jérôme.

Le 17 janv. 2018 à 10:51, Pierre Boutillier [email protected] a écrit :

%def: "syntaxVersion" "X" has indeed disappeared.

In the early days of Kappa 4 syntax syntax 3 and syntax 4 symbols were close enough so that you wrote one parser to recognise both and 2 symbol interpreters. That allowed to look inside the recognised-not-yet-interpreted symbols for a "syntaxVersion" parameter and choose the symbol-interpreter accordingly. Syntax have now diverges way too much to allow to write a symbol recogniser for the union of them. Therefore, I had to write 2 completely independent parsing chain. The drawback is that when it starts to read the input files, it has already choose in which version it read sand it is too late to read that information in the file!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KaSim/issues/482#issuecomment-358252681, or mute the thread https://github.com/notifications/unsubscribe-auth/AARts0S3_lZRgOLHTVpkw6JA4nlgTxCRks5tLcKhgaJpZM4RgXDq.

feret avatar Jan 17 '18 12:01 feret

I strongly argue that KaSim4, as well as future KaSims, need to be able to read old kappa syntax, without the user knowing a priori what command line parameter to invoke and with what argument. The raison d'être of the archive file inputs.ka is to provide a one-click reproducible run, without having to decorate the command line invocation.

My first thought would be to have a syntax-version decider who's only job is to determine what kappa syntax the file is in. If it finds an explicit syntax definition, we're all set. If it doesn't, then it defaults to trying V4, if that fails then try with V3. With proper messages (e.g. "Explicit syntax detected, parsing as V4", "No explicit syntax declared, trying to parse as V4 ...", "No explicit syntax declared, parsing as V4 failed on line X, characters Y, now trying to parse as V3..."), the user would still be able to tell if there is a true syntax error, or just a deprecated-syntax error.

If that is too costly in dev-time, then @feret 's option would be fine. The archive files of KaSim3 all begin with a pound sign and an UUID string, which will fail V4 parsing at the very first line and character (i.e. fail as early as possible), thus minimizing the time spent futilely trying to parse a V3 file as a V4.

Of course, if (and when) KaSim5 appears, syntax versioning might come back to bite if we don't have an extendable solution.

hmedina avatar Jan 17 '18 21:01 hmedina