Re: static macro
Why would it not be useful? Someone might google something similar and land here. I added your original question to my answer.
Re: static macro
Static is not a macro, it's a language feature, so it will be implemented in the compiler, not the standard library. evalStaticExpr/Stmt in compiler/vm.nim sound reasonable.
Re: static macro
alright thank you, that narrows my search
static macro
Just a quick question, I have been looking for where the static macro is defined so I can look at how it is implemented does anyone have an idea of where that would be?
Re: Looking for efficient API for regexp library
True, it does not support UTF-8, just as the original Lua patterns do not. I guess having proper support for UTF-8 would probably include supporting Unicode as well and would complicate things a lot- for example, matching any unicode upper case character with %u would not be trivial. BTW: YEs, I've seen nim-regex, which is also very nice. The lua pattern port is mainly for my personal use, because I'm leaving Lua more then 10 years of Lua behind, but I dearly miss the patterns. The advantage is that they are much more simple then regular expressions, which often result in something that I can read and understand a year after I wrote it - which is often not the case with full fledged PCRE regular expressions. (Personally, I'd prefer pure Nim regex handing in the Nim stdlib over a PCRE based solution which requires external libs, would nim-regex not be a nice candidate?)
Re: Looking for efficient API for regexp library
@zevv, your library doesn't support utf-8. IMO, this is a big disadvantage. BTW, have you seen [nim-regex](https://github.com/nitely/nim-regex) library?
Re: Command-line Parsing Preferences
cligen looks very cool, I'll need to look into it. I'm also curious how other people feel about the args situation. In my personal projects I've been using parseopt and having a user type ":" like the Nim Compiler...
Re: Looking for efficient API for regexp library
For gmatch definition, how about if you make it generic? You define it like `iterator gmatch[R: seq | array | tuple](src, pat: string): R` Of course you need to match the result based on the type given, not sure how to proceed for that
Re: Looking for efficient API for regexp library
This is also usable, although it requires the variables to receive the captures
to be declared ahead of time:
proc match(src: string, pat: string, c0: var string): bool =
let caps = src.match(pat)
if caps.len == 1:
c0 = caps[0]
return true
proc match(src: string, pat: string, c0, c1: var string): bool =
let caps = src.match(pat)
if caps.len == 2:
c0 = caps[0]
c1 = caps[1]
return true
proc match(src: string, pat: string, c0, c1, c2: var string): bool =
let caps = src.match(pat)
if caps.len == 3:
c0 = caps[0]
c1 = caps[1]
c2 = caps[1]
return true
let src = "3 foxes: 0x1234"
var a, b: string
if src.match("(%a+).*0x(%x+)", a, b):
echo "a = " & a
echo "b = " & b
Re: Looking for efficient API for regexp library
Yeah, I guess providing multiple functions would work, since in practice patterns are usually limited to a handful of captures. Thanks,
Re: How is the compiler so clever, and how clever does it get?
I wasn't making analogies to C, and I don't see what difference it makes in this case. If the macro has no side-effects, and the macro definition hasn't changed, and the module where the macro is used hasn't changed (both can be deduced from comparing modification dates with the cache), then the result of macro expansion will not have changed from the last time the module was compiled, so there is no reason to call the macro except for side-effects. As for what happens when the macro breaks referential transparency in some fishy way, it'd be nice if you could flag it to be treated as if it was pure anyway, and then add whatever external data the expansion depends on as a dependency to the module containing a macro.
Re: How is the compiler so clever, and how clever does it get?
@StasB, the macro wouldn't be evaluated if not used, evaluated if used. If not used, you won't get the transformed/generated code @Udiknedorm, yes, some operations just cannot be evaluated during compile time, but macro in Nim still evaluating what it can for compile-time operations.
Re: [RFC] Cyclic imports and symbol dependencies
@Araq Thanks for replying, I guess it makes sense that that people who use class macros would want cyclic imports the most, since it's hardest to separate everything out. Well, I think combining macros (especially macros with potentially unlimited side effects) with cyclic dependencies in Nim would be difficult. The only language I'm aware of that combines circular dependencies and macros is Nemerle, where it allows macros to participate in multiple passes of the compilation process. Something like that would add quite a bit of complexity to the Nim compiler, and it's probably not worth it.
Command-line Parsing Preferences
So, there have been various on again/off again conversations on github about how the stdlib parseopt could/should behave. Those conversations seemed to have a pretty narrow audience..basically participants on these github issue threads: [4620](https://github.com/nim-lang/Nim/issues/4620) [6818](https://github.com/nim-lang/Nim/issues/6818) . It made sense to me to raise this topic in the forum where a wider audience might weigh in before 0.18/1.0/whatever stabilizing might happen. The basic issue is whether command users have to separate option keys from option values (e.g. with a ':' as the current code does). In order to avoid that requirement, command authors need to update a list of option keys whenever they change them which is a hassle. So, there is a tension between convenience to CLI authors and CLI users. As a user, I often forget to type the ':' and would be delighted if more people chose the symbol table route. Myself, I think having an **optional** symbol table is the most programmer and user-friendly solution. That 's what I did in parseopt3 in [cligen](https://github.com/c-blake/cligen). If the programmer wants to provide more POSIX-like command syntax then that's easy. OTOH, if like Araq they very understandably prefer not to have to update a symbol table when they add new option keys then they can just ignore that feature and make their users provide a ':' to separate option keys and option values. To me this kind of optional symbol table seems both backward compatible and forward looking and strikes a good balance for a stdlib. I'm just one person, though, and that's just my opinion. The point of this thread is to solicit other opinions/perspectives/input to help figure out the best resolution of [6818](https://github.com/nim-lang/Nim/issues/6818) .
