Check out nim's irc channel, that's where the real hacks and tricks are
discussed.
If you only need one extra field, you could write the template like this:
template typeGen(tName, name, kind: untyped): untyped =
type
tName {.inject.} = object
fname: string
age: int
name: kind
typeGen(Employee, id, int)
@LeuGim That's bad. I'm using Nim 1.17.2 so it seems to imply the bug was
created between 1.17.1 and 1.17.2, I guess...
@Lando: Good point! thanks
Please help speedup with the following nim code taking five times longer than
python version: import os, sets, strutils
if paramCount() != 2:
echo "mydiff file1 file2" quit()
let file1 = open(paramStr(1)) let file2 = open(paramStr(2))
let old_lines = file1.readAll().splitLines() let
> Your syntax for macro's call is OK
Exactly.
@slimshady, @dataPulverizer: General tip: if a macro call is passed to
_dumpTree_ as a block argument and that compiles and prints the call as a
(pre-symbol-binding) AST, then the call syntax is ok:
import macros
dumpTree:
Welcome!
LeuGim: a side note: it's not an implicit conversion, with "var x: int8" Nim
treats your "3" literal as "int8" type
Regarding assignment, it doesn't have to depend on types being
indistinguishable. E.g.:
proc p(x: int) = echo "int"
proc p(x: int8) = echo "int8"
var x: int8
x=3 # implicit conversion
p x # int8
p 3 # int
overloading works here, while allowing literal's
You can try to search forum for if there were previous discussions... Just
> the situation when you can declare something that you cannot later call
seems to be not intended.
I can definitely report this on Github, but before doing this I'd like to
better understand this inconsistency.
It seems that for array initialization to work as expected, array types that
differ only in index boundaries should be treated as equal. Otherwise this:
var b: array[-1
Your syntax for macro's call is OK, your key-value pair is parsed as a call
(`id` being regarded as a proc name, and `int` as statement list (block),
passed to it). Now you need to write a macro, that can use it. In that macro
you first assign to `result` the constant part of your type, and
Report it as a bug on Github, if it's not there already, it's an old issue.
> No, parser cannot understand `extraCode` in an object declaration, in the
> template, which is there an invalid syntax.
I would like to substitute `id: int` for extra code in the template by doing:
typeGen(Employee):
id: int
I thought (incorrectly) that this is how
Two arrays of the same size and element type but with different index
boundaries seem to be distinct types for the purpose of (polymorphic) proc
definitions, so this compiles:
proc p(a: array[10, int]) = discard
proc p(a: array[-1 .. 8, int]) = discard
but they seem to
No, parser cannot understand `extraCode` in an object declaration, in the
template, which is there an invalid syntax.
@Udiknedormin, concerning Error: cannot use symbol of kind 'var' as a 'field':
that should be a bug, but I don't see such a behaviour with Nim 0.17.1.
Hey guys. Just learned about nim a few days ago from HN the lang. looks amazing
so hope I will get up to speed quickly and can be of help to the Nim community.
@dataPulverizer I think
typeGen(Employee):
id: int
is invalid syntax. You cant declare variables like id:int and templates expect
valid nim code.
18 matches
Mail list logo
