Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How would you categorize STRING-CASE ? #456

Open
adlai opened this issue Nov 16, 2022 · 4 comments
Open

How would you categorize STRING-CASE ? #456

adlai opened this issue Nov 16, 2022 · 4 comments

Comments

@adlai
Copy link
Contributor

adlai commented Nov 16, 2022

Please note that I am not (yet!) nominating this library for inclusion, due to the lack of obvious categorisation.

It exports one symbol, similar to the cl:case macro, for matching string literals; and I must admit that it is quite a low-level library, and most folks these days would probably complain that it's not a complete reimplementation of the Glasgow Haskell Compiler.

@gwerbin
Copy link

gwerbin commented Nov 16, 2022

In my entirely non-authoritative opinion, it seems like it belongs in "Language extensions" alongside libraries like trivia.

"Language extensions" seems to be where control flow constructs are located, and this seems like it's intended to be a control flow construct (rather than a text processing routine).

I do wonder why they chose string literals and not keywords, but that's a different question entirely!

@vindarel
Copy link
Collaborator

it seems like it belongs in "Language extensions"

agreed.

But of course, we can create and re-arrange categories.

ps: for a simple version, see str:string-case

@adlai
Copy link
Contributor Author

adlai commented Nov 17, 2022

ps: for a simple version, see str:string-case

link (pinned to one specific commit, to avoid breaking when you update the repository)

@adlai
Copy link
Contributor Author

adlai commented Nov 17, 2022

I do wonder why they chose string literals and not keywords, but that's a different question entirely!

The more I've used it, the more it seems to me to simply be an intermediate primitive, similar to how implementors might lean upon cl:tagbody for implementing more complicated constructs; and for an intermediate, it's nice to avoid the extra code cruft of dealing with packages. I do realise that if it's an interface macro, then keywords are nice, because they save one character; and if you're really gone golfing, let any symbol get used, with some keyword options in the switch form [i.e., some keyword within the form immediately following the string-case symbol] to allow for optional including of qualified names instead of only the cl:symbol-name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants