> If the devs don't have even a basic level of intellectual inquisitiveness
> (pride?) to understand why this phenomena exists (and would have to
> ultimately fix it ), I don't know what more data, motivation, or incentive,
> is needed.
_Shrug_ I 'm sorry I know so much about problems like
Mr jzakiya,
this is indeed an interesting observation, and in your last post you gave a
very good description of it.
But your attitude is still a bit strange. As you already found out, Nim
generates fully valid C code, similar code as a C programmer may write. So it
is more a problem of C
I'm not a fan of exceptions but the alternatives that are usually suggested are
worse reinventions of exceptions.
Error handling is really not that hard to analyse: In case of an error you can
only do a couple of different things:
* Let it "bubble up" the call stack.
* Retry the operation.
In order to be taken `super, suPER, SUPER` seriously, let me be hermetically
sealed, and scientifically rigorous, in presenting this `problem`.
Base Hardware:
System76 laptop with Intel I7 6700HQ cpu, 2.6-3.5 GHz clock, 4 cores, 8
threads, 16GB of memory, and 128GB SSD.
Base OS:
Linux kernel
How do you feel about exceptions? I always disliked exceptions in C++ and found
comfort in C, which lacks them.
Yet, when I found Nim I realized that exceptions aren't so tricky. Perhaps this
is because of 2 really important features:
* The GC: In C++ you must take extra care to write
On the topic of `method`: I like the flexibility that it provides. I am not a
die-hard OOP programmer - e.g. I prefer a Rust or C style where one uses either
custom structures or uses composition.
However, without `method` OOP support in Nim would be quite fundamentally
limited
I understand that in Nim, you can call a proc without using brackets. Indeed,
the following works fine:
write stdout, "a" #== write(stdout, "a")
#=>a
However, the followings fail.
import strutils
discard split "A,B,C" ',' #=> Error: invalid
I work in games middleware and we mostly use float32, that doesn't mean we care
about what is the default of an unspecified type.
The game industry really dislikes unspecified sizes, and therefore will
systematically use an explicitly sized type, which means, Nim's float32. And
typedef it to
Change the code:
template create(x: int, T: typedesc): untyped = T(age: x)
to:
template create(x: int, T: untyped): untyped = T(age: x)
All the code of above works!
Now here is problem how to pass typedesc to template:
template create(x: int, T: typedesc): untyped = T(age: x)
macro m2(T: typedesc): untyped =
let nT = quote do: `T` #Sym "User"
let t1 = T.getType()[1] #Sym "User"
let t2 =
The following code is ok:
result = newCall("stepTwo", ident("User")) # OK!
result = newCall("stepTwo", T.getType) # OK!
Now, I know how to pass User as typedesc, but still it is a little confusion
about typedesc to me.
That's a very good idea but it's not universally applicable, a feature needs to
justify its implementation complexity and the training/documentation aspects (a
bigger language is harder to teach etc). Also, when I say something like "I
want to remove X from Nim" I generally mean to provide a
When a proc call a macro with typedesc parameter, we can just user the type
name, but when we call another macro in the macro and pass the typedesc
parameter to it, something is strange, look at the code:
type
User = object
id: int
name: string
One more idea.
Can it be more federated decision? For example: if we have a volunteering
maintainer to support a feature and to resolve its reported issues then it will
remain. So people instead of theoretical discussion will vote with their time
(real asset) instead? I think you will likely
Not sure if this was ever discussed so I will throw this idea here:
The Nim compiler has very complicated built in type rules for int types
handling, to make int, int16, uint types mixable without explicit type
conversions. Is is possible move out this logic from compiler into a set of
First version 500ms
LBB0_1: # =>This Inner Loop Header: Depth=1
movdqa xmm3, xmm5
movdqa xmm6, xmm5
paddd xmm5, xmmword ptr [__xmm@0008000800080008]
add esi, -8
pcmpeqd xmm3, xmm0
pcmpeqd xmm6,
Please, leave exceptions there, there are other methods to handle errors, but
they are often cumbersome in an imperative language. Bitsets are also really
nice, and they play well with the c pattern of using integers for options and
combining them with masks, just in a more readabe way.
That
Hlaaftana, thanks for confirming. I was really tired yesterday and though I was
doing something wrong.
cdome, your message makes not too much sense for me currently.
Indeed I tried using unlikely() for this test, which made no difference, as
expected, as automatic branch prediction should work
Focusing on the stdlib: hopefully already intended, but removing deprecated
modules and procs, as well as `md5` and `asyncftpclient`. `md5` is just an
attractive nuisance of a cryptographic hashing algorithm, good enough to look
appealing but horridly insecure, and to the extent the stdlib has
* `.discardable`, doesn't play nice with Nim's type inference and is rarely
useful.
* `converter`
* `method`, replace it by an interface macro.
* enums with holes, replace it by a `distinct` integer type.
* `.borrow` as a builtin, should have been a macro.
Exceptions are hard to
I think interfaces or something akin to them would be much more useful for the
language than methods. I don't know how hard this is to implement - that's not
why I'm suggesting it - I just don't find methods particularly useful.
I don't generally like exceptions - but I've also been told not
On my machine and debug mode `i == 7` takes 12 seconds to run and `i * i == 49`
takes 20 seconds. With release mode it was like 1.3 for `i * i == 49` and 0.8
for the other. A little faster than double the speed, which means it's at least
faster than `i == -7 or i == 7`.
Based on [this online
proc main =
var s = 0
for i in 0 .. 10:
if i * i == 49:
#if i == 7:
s += 1
echo s
main()
For this test, using "if i == 7" instead of "if i * i == 49" gives half runtime
on my box. This is a bit surprising as multiply is
If you are interested in parsing a file of specific format, the
[NESM](https://github.com/xomachine/NESM) library
([docs](https://xomachine.github.io/NESM/)) might also be useful for that
purpose.
> What else would you kill off?
* method
Nim already has the ability to do OO style polymorphism without **method** , I
think for those relatively rare cases that this is useful something other than
**method** should be provided, maybe something like Ada 2005 interface types. I
thought
25 matches
Mail list logo
