Re: Should we get rid of style insensitivity?
Do you plan to implement nimgrep for github and IDEs too? Btw, removing this "feature" wouldn't dumb down Nim because this feature is already dumb - the fact that we need to change our standard tools for its mythical benefits already tells a lot about the ecosystem for an outsider.
Re: Should we get rid of style insensitivity?
@moerm grep -i is not style-insensitive, it's only case-insensitive which means it'll be useless most of the time. This feature shouldn't be in any language.
Re: Should we get rid of style insensitivity?
Just a fresh example: I was searching for a function in someone's github repo and I couldn't find it - guess why - the author used camel case in the examples while it was defined with snake case in the code. This feature only caused me issues so far.
Re: Should we get rid of style insensitivity?
Style insensitivity is bad when you try to use tools like grep, sed etc. and it also confuses a lot of people. **I want a vote.**
Re: Type inference and pragma issues in lambdas
@juancarlospaco what's that supposed to be?
@mratsim the sugar module produces the same. Also, I REALLY don't want to type
down {.closure.} every time I create a lambda function because it'd be insane.
Also, I think it's wrong for a lambda to assume that it'll be a {.closure.} -
it should allow everything by default unless explicitly defined otherwise.
Type inference and pragma issues in lambdas
Hi,
> Why is this an issue:
proc doIt(x: (string, proc(): void)) =
echo x[0]
doIt(("xx", proc(): void = echo "aa"))
Run
Hint: used config file
'/home/steven/.choosenim/toolchains/nim-0.19.0/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: t [Processing]
t.nim(5, 5) Error: type mismatch: got
but expected one of:
proc doIt(x: (string, proc (): void))
expression: doIt(("xx", proc (): void = echo ["aa"]))
Run
Is there a sane way in nim to do lambdas?
Re: Type inference and pragma issues in lambdas
But this is ok:
proc doIt(x: (string, proc(): void)) =
echo x[0]
proc make1(x: string, y: proc(): void): (string, proc(): void) = (x, y)
doIt(make1("xx", proc(): void = echo "aa"))
Run
Doesn't make any sense.
Re: How can we use operators as type names
Thanks! It's a bit weird which makes it useless, unfortunately...
How can we use operators as type names
Hi, the question is in the title, here's a sample:
type `!`* = enum A B C
proc stuff(p: !): void = echo p # (3, 16) Error: expression expected, but
found ')'
and another:
type
`?`*[T] = object of RootObj
case isDefined* : bool
of true : value* : T
of false : nil
proc some*[T](val: T): auto =
?[T](isDefined: true, value: val)
proc none*[T](): auto = ?[T](isDefined: false)
proc `$`*[T](option: ?[T]): string = #(12, 23) Error: type mismatch: got
(array[0..0, T]) but expected '? = CompositeTypeClass'
if ?option : result = "some(" & $option.value & ")"
else : result = "none"
Thanks!
Re: VSCode Editor Nim Extension (free Visual Studio Code Editor by Microsoft)
@OderWat Is Atom slower? Possibly. If I install enough plugin on Atom to make it seem like an IDE and open a project with it it can eat up to 4 GB of RAM which is unacceptable. Is Atom ameturish? [vscode just introduced tabs and find-replace](https://encrypted.google.com/url?sa=t=j==s=web=1=rja=8=0ahUKEwjjhaHo2_LNAhUOrRQKHYoFAqAQFggdMAA=https%3A%2F%2Fwww.reddit.com%2Fr%2Fprogramming%2Fcomments%2F4rrf0p%2Fvisual_studio_code_13_released_now_with_tabs%2F=AFQjCNHROCRpylDYXv_SlStapvOxI4kgyg) . Could electron be fast? Of course, the hello-world app. More "serious" apps like a git gui([https://www.gitkraken.com/](https://www.gitkraken.com/)) just wastes tons of resources for nothing when you open larger projects with them. It doesn't matter what electron app we use, both the startup and the runtime will be slower than it should be - even slower than a .net app while spawning a lot of processes because of chromium. BTW: what a nice new world where most editors are written on one of the slowest platform. With such "progress" they'll never beat neither sublime nor vim.
Re: VSCode Editor Nim Extension (free Visual Studio Code Editor by Microsoft)
VSCode is almost the same as Atom - just like their Nim plugins - except the UI differs a little bit(VSCode is more like a Qt creator/brackets copy) and it has less plugins. It's built on electron too so prepare for the leaks and glitches(the app stuck on the screen for me after minimizing it)!
Re: Concept[T]
> concept is likely the most misunderstood language feature This is true because (almost?) everybody wants it to be something like a typeclass or an interface but it's none of these. And the temporary solution - the tuple-of-procs - isn't so convenient and can't describe relations between such tuples. So, I'm really interested in what it'll turn out to be.
Re: Concept[T]
@Araq it still doesn't compile: > Error: type mismatch: got (seq[int]) but expected one of: proc first[T](x: > Container[T]): T Mainly, because of ["Generic concepts" (Foo[T] = concept) don't work."](http://forum.nim-lang.org///forum.nim-lang.org/t/2366) . Also, it's pretty weird to describe type signatures with values, isn't it?
Re: Status of Concepts
> Unlikely to become stable for v1.
I'm sad too to hear this because Nim doesn't have any other abstractional
feature besides the tuple-of-procs solution:
type Container[T] = tuple [get : proc (i : int) : T]
converter seqIsContainer[T](s : seq[T]) : Container[T] =
cast[Container[T]](proc (i : int) : T = s[i]) # don't need to cast if the
tuple is n-ary
proc first[T](c : Container[T]) : T = c.get(0)
echo first(@[1, 2, 3])
I don't know how expensive is this at runtime but at least there should be a
way to define tuples with one parameter to be a decent temporary solution.
> Well we have an {.experimental.} pragma that needs to be explicitly enabled
> per module to enable these unfinished features. I think it's a viable
> solution even if it means v1 is not as feature complete as we would like (but
> then what language is feature complete at v1 anyway?).
Please, no more pragmas - it's the weakness of the language - complexity and
uncertainty++. As @OderWat said: "Keep experimental stuff in the experimental
branch."
Status of Concepts
Hi all! In the manuals there is a note belove [concepts](http://forum.nim-lang.org///nim-lang.org/docs/manual.html#generics-concepts) : "Concepts are still in development." but there is no information about it in the [Roadmap](https://github.com/nim-lang/Nim/wiki/Roadmap). When I've started to experiment with them I've met with dead-ends like the OP in [this thread](http://forum.nim-lang.org///forum.nim-lang.org/t/2363) . Would some of the developers enlighten me about the development status of concepts - is it labeled an important feature and are the fixes will make it into 1.0? Or its expressive power will stay the same as now?
