nimforum mirror - [Karax] "include" statement doesn't work correctly inside karax DSL

veksha (orginal) [2022-04-01T13:23:39+02:00] view original

Hello. I don't know if it is a bug or my mistake. If it is a bug, then is it a Nim or Karax issue?

this works:

#test.nim
import karax/[karaxdsl,vdom]

let res = buildHtml(html):
    head:
        meta()
echo res
#<html><head><meta /></head></html>

this doesn't :

#test.nim
import karax/[karaxdsl,vdom]

let res = buildHtml(html):
    head:
        include test2    # <----- look at this line
echo res
#template/generic instantiation of `buildHtml` from here
#Error: attempting to call undeclared routine: 'meta'

#test2.nim
meta()

PMunch (orginal) [2022-04-01T13:32:49+02:00] view original

Definitely not how include is supposed to be used, and I'm guessing the reason that it fails is because buildHtml looks through all the nodes and converts stuff, things it can't convert it just outputs verbatim (or something similar). This means that include test2 would simply be added in between the HTML building steps and after buildHtml is done with its conversion meta doesn't exist any longer.

veksha (orginal) [2022-04-01T19:37:34+02:00] view original

I thought it just includes text at that position and then all other things will follow. but I guess macros kick in first. is there a reason for things to be like this? doesn't the include statement must have higher priority in preprocessor sequence?

xigoi (orginal) [2022-04-01T22:00:00+02:00] view original

If I'm not mistaken, Nim's metaprogramming features always work “outside in”. If you have a macro inside a macro, the outer macro gets expanded and the inner macro may end up getting transformed into something else. It wouldn't make sense the other way, because the argument of a macro may be complete gibberish on its own.

DeletedUser (orginal) [2022-04-02T09:09:12+02:00] view original

There is no preprocessor. include is just like any other statement and thus gets evaluated in the same order as any other statement, and is represented in the AST as its own statement. What is given to the macro is literally the AST of include test2, and the macro can't do any processing on anything inside test2 without specifically handling include statements, which isn't really something macros can exhaustively do and any attempt at it would just make the macro bloated.

ynfle (orginal) [2022-04-03T03:20:10+02:00] view original

This is true for untyped macros, but a macro (like the one below) does have the include statement expanded to the ast of the included file.

import macros

macro t(x: typed) =
  echo repr x

t:
  include tables

Araq (orginal) [2022-04-03T07:37:34+02:00] view original

FWIW I still think typed macros are Nim's future and untyped was a mistake. :-)

ynfle (orginal) [2022-04-03T16:03:04+02:00] view original

How a DSL be done then? Wouldn't everything be expanded?

Araq (orginal) [2022-04-04T13:35:17+02:00] view original

The DSL would need to be able to deal with expanded ASTs, yes. That's quite feasible, if only we had a specification of typed ASTs and a compiler that would implement it.

xigoi (orginal) [2022-04-04T17:10:10+02:00] view original

Wouldn't that make things like x.mapIt(it + 1) impossible, since it is not defined?

Araq (orginal) [2022-04-04T21:40:13+02:00] view original

Well it would need to stay nnkIdent inside a typed environment but that doesn't look like a big problem.

bpr (orginal) [2022-04-05T16:25:36+02:00] view original

The DSL would need to be able to deal with expanded ASTs, yes. That's quite feasible, if only we had a specification of typed ASTs and a compiler that would implement it.

Oh come on, after that "if only we had" set up, the follow up should be something like "And here is the spec, which is implemented in dev. Give it a spin and report any bugs in the issue tracker". You're just going to leave everyone hanging?

Mirror of forum.nim-lang.org

9066 :: [Karax] "include" statement doesn't work correctly inside karax DSL