Data type `LanguageTag`

[lscharmer]

This PR introduces a new data type LanguageTag. The language tag is validated by the RFC as it is defined here: https://www.ietf.org/rfc/bcp/bcp47.txt.

This will be used in: https://github.com/ILIAS-eLearning/ILIAS/pull/4082

[klees]

Hi everyone,

just to keep interested people in the loop: This PR was discussed via various personal channels. Besides the announced addition regarding the "lang"-RFC, this also contains some parsing framework that is used to implement the specification from the RFC.

Since I deem this (or something like this) to be a super valuable addition to ILIAS that should be used in various places, I though we should give more room to that code then it currently receives via this PR. If other devs don't know about the parsing framework and didn't have time and space to discuss and communicate ideas and requirements it would be very likely, from my experience, that this parsing framework simply won't be used again any time soon.

So I'm happy that we'll meet at 2022-07-21 from 11:00 to 12:00 to discuss the parsing framework included here.

Thanks @lscharmer and @mjansenDatabay for taking the time and proposing the code.

Best regards!

[klees]

Hi @lscharmer,

as noted above: I will be super happy if we have a parsing framework in ILIAS. Thanks for proposing this. To allow you to prepare for the workshop (or maybe even answer this before), I just want to write down my questions, for information and discussion:

• Why is this named Brick? Did you consider other names? Is this something that evokes the "correct" idea in other devs? In short: Is this a good name?
• Would we want to move (parts of) the documentation from the class to a separate README (or something)?
• This seems to be an implementation of the Parser Combinator approach to parsing. Is this correct? Shall we point this out in the comments?
• Is there some role model (maybe in Haskell ;-p) that you used to implement this? Some paper? Are there any known characteristics of this implementation, e.g. for performance, memory usage, stack sizes, that would limit the applicability of the code? Can we point to some resources regarding these questions?
• Is this really a "parser"? It seems to be missing the structure building part. Instead it seems to be matching the given string to a supplied pattern without building more structured data from it. Am I missing something?
• Is src/Data really the place to put this? From the general functionality it seems to fit into src/Refinery much better. Did you have any considerations regarding the location in our code?

This is it for the moment, cannot promise that there won't be more at some point, though =)

Best regards!

[lscharmer]

Hi @klees, thank you for your questions.

This is it for the moment, cannot promise that there won't be more at some point, though =)

Please add any questions that will come up, they indeed help me to prepare for the workshop.

I will refrain from calling this a framework, because this was just build to validate the language tag RFC in a sane and readable way (just as a means to an end). I fear that this might develop into a bigger thing than necessary. The core code is less than 200 LOC and to keep it as small as possible, links to external documentation, corresponding papers etc. should note that this implementation is only oriented by them, to prevent that people assume that this is a complete implementation of these. This is also the reason why the documentation states that the Brick class does not provide a complete ABNF defintion.

Keeping this in mind I'm happy for input and discussion about better names (Brick, parser etc.), where to put the files and what the intend for the future will be (e.g. to actually transform the input: without type hints in Intermediate this is already possible xD), as I'm unsatisfied / unsure about them as well. I think it's also important to discuss for what problems this should not be used and where the limits of this implementation are.

This is the role model: http://wiki.call-cc.org/eggref/5/comparse :wink: So yes it's a parser combinator.

Best regards Lukas

[Amstutz]

Hi to everybody involved,

This PR seems somewhat stuck in the discussion. Is there a way to move this forward. I ask, since there is a dep. where I am assigned to: https://github.com/ILIAS-eLearning/ILIAS/pull/4082

Thx for some feedback.

[mjansenDatabay]

@Amstutz This PR is not stuck. @lscharmer and I had a community workshop with @klees and @kergomard . @lscharmer is currently working (just now) on the feedback of this workshop. He will provide the changes soon. Furtheremore he will apply for a presentation at the upcoming development confererence, which was also a decision made in the workshop.

[lscharmer]

See PR: #4975