libera/#sicl - IRC Chatlog
Search
8:56:27
hayley
There are some situations which obviously should lead to an error or warning, but then there are some that aren't so clear. Should, say, DO-MATCHES with an incorrect number of bindings (and a constant regular expression, so that we can actually do analysis at compile-time) produce a compile-time error, or warning, or something else? It will certainly lead to a runtime error, and the programmer cannot do anything other than rewrite the DO-MATCHES
8:56:28
hayley
form to fix it. But Common Lisp systems can only signal a warning, when static analysis shows that some code will always lead to a runtime error, and so signalling a compile-time error could be seen as inconsistent.
9:32:15
splittist
hayley: so DO-MATCHES does linting as it generates code? Could you have a keyword argument for LINTING-LEVEL? Or even a HAYLEYS-COOL-REGEXPS:*LINTING-OPTIONS* alist/plist/object?
9:33:22
hayley
The linting is done by the DO-MATCHES macro, and additionally by compiler macros for each matching function (which also optimise the case of a constant regular expression argument). A keyword argument could work, sure.
9:39:25
splittist
The professional (TM) way of doing it would be to have a json dotfile in the project root directory whose format would vary with every new point release, but because it would be undocumented, the only way to properly edit it would be using a clunky menu system with inconsistent terminology. (Can you tell I've used vs code?)
11:22:20
scymtym
hayley: i think this is mostly what you already said, but my take would be: if a DO-MATCHES form will definitely lead to an error at runtime, signaling a full warning at compile-time (possibly using WITH-CURRENT-SOURCE-FORM to indicate which part of the form is the problem) seems appropriate. if the form /may/ lead to an error at runtime or has mere style issues, a style warning (also possibly using WITH-CURRENT-SOURCE-FORM) seems