Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Mar 03 2017 15:52
    @dom96 banned @Octopoda7
  • Feb 12 2017 23:57
    @dom96 banned @zzz125
  • Dec 23 2016 19:43
    @dom96 banned @Izrab
From IRC (bridge bot)
<disruptek> ~stream
<disbot> 9stream: (live video/audio) and mumble:// (live voice chat) -- 7disruptek
<disruptek> nim/compiler rants on demand.
From IRC (bridge bot)
<PMunch> dadada, do you have an example?
<PMunch> Because this doesn't work:
<dadada> PMunch: it looks close to the foo thing I sent you, but I use something like proc(a: int) = statements and the macro is macro foo(d: DObject, args: varargs[untyped]): untyped = ...
<axion> Hmm, I ran into an issue porting some Lisp code that uses a heterogenous varargs parameter on the stack. i don't see any way to do this without using the heap in Nim
From IRC (bridge bot)
<dadada> PMunch: like this
<PMunch> So something like this?
<PMunch> dadada ^
<PMunch> The thing is that using : or do: apparently requires stricter rules than without..
<dadada> it's funny that it even makes the extraction code looks closer to the thing that it should parse
<PMunch> Well that is the point ;⁠)
<dadada> ... all this special sauce should be documented
<PMunch> You make your extraction code what you want to extract
From IRC (bridge bot)
<PMunch> It probably is.. Somewhere..
<axion> I need to be able to do something like this (pseudo-code) foo(rot, x=1.0, y=2.0, z=3.0), or foo(rot, z=1.0, y=1.0, x=3.0), or even duplicated keys like foo(root, z=1.0, y=2.0, z=3.0), and the body iterating over them in order. Any ideas?
<dadada> I get that, but for quote do: the do is regarded as purely sugar AFAIK, so how would a random user know that in the case of extract, the do part is functional and what function it has?
<PMunch> Well it's not so much the do but rather the :
<dadada> thanks for leading the way :⁠-)
<PMunch> And IIRC there was a difference between : and do: before, but I'm not sure if that's the case any longer.
<PMunch> The : takes a block or statement list as its argument. But without you can pass a single NimNode
<PMunch> So in your example you couldn't put anything after the lambda, because the lambda is the only NimNode passed to the macro, and to extract
<PMunch> If you look at the treeRepr of what you get in you will see that with : you get a StmtList, possibly with a single element, and without you get whatever node type you passed in directly.
From IRC (bridge bot)
<dadada> PMunch: to know if extraction is successful I've to use exception as of now, is that correct? I'd prefer something like this pseudocode that code runs through dumpTree fine, so maybe it's possible to support it
Anybody know why I'm getting a type mismatch here?
From IRC (bridge bot)
<axion> Calling all smart Nimmers. I'm need help thinking about this problem please:
<dadada> PMunch: sometimes you've macros that can take in multiple possible asts, and so the extraction should be simultaneously a test and fail gracefully
submatrix should give a matrix that's equal in dimension now yet it gives the same dimensions :o
From IRC (bridge bot)
<PMunch> dadada, I was thinking one would use the sameTree macro first to check what the tree matched, then extract to get the nodes..
<PMunch> But that might be a bit clunky indeed
<dadada> PMunch: why type something twice, when you can do it in one go
<PMunch> Can you wrap it in a template that uses a try/finally?
<dadada> that could work, I might try it myself :⁠-) would that be efficient though? are exceptions in Nim fast?
<dadada> I assume they are... I'll try to come up with something
<PMunch> Well this is all in the VM, so performance is a bit peu à peu to begin with..
<dadada> true
From IRC (bridge bot)
<PMunch> Well, I've got to start making dinner before I starve to death
<dadada> good appetite
<clyybber> axion: I think foo would have to be a macro
<clyybber> With untyped arguments
<axion> Why? It has to expand to something right?
From IRC (bridge bot)
<clyybber> So as to support foo(x = 1, x = 2)
<clyybber> Because theres no way to make that work other than have foo be a macro or template
<axion> Well as mentioned, that is just pseudo code. Ignoring the syntax, I'm only interested in the semantics
<clyybber> I see
<clyybber> I think its still best if you start with foo being a macro
<clyybber> And work from that
<leorize> yea macro is the best bet