Re: Should we get rid of style insensitivity?
I’d like a vote. I completely see where Dom is coming from with this proposal. This is mentioned as a negative in every discussion about been that I’ve seen in reddit and proggit I’m sure there are people who would give Nim a chance but which are very put off by this. Personally I am not against this in principle, and I can understand some of the proposed benefits. I haven’t needed it myself and I prefer to be consistent when I write code but I imagine it could be useful when interfacing with external libraries and with non nim code for example. However I believe that people in favor of it minimize the drawbacks a bit. For example the fact that it makes identifiers harder to find is a real problem. I don’t think that saying that you should use ningrep to search is a good answer. People like to use their existing tools such as their editor of choice’s search box and won’t happily change that just to use a new language. I think we can keep the benefits of this controversial feature without most of its drawbacks. To me the biggest problem is that it is enabled by default, for all the code in all the files. Instead I’d suggest making it optional and letting the user explicitly enable the style insensitivity on a particular section of the code or for a particular library, etc. I believe someone else proposed something similar earlier in the thread.
Re: How to convert integer to pointer
> I want to include type name in that user defined type. Is it possible ?
You can of coarse do anything with "type names" \- i.e. just strings "int",
etc. But you probably want to store types themselves - `typedesc`. There's not
so much you can do with them. Types exist at compile-time only (opposite to
Ruby, Python and the like). Pointers - at run-time only. So no `addr Sample`
and the like. It's possible to store types in compile-time variables (like `var
a {.compiletime.}: array[10,typedesc]`), but even then you cannot then use them
in place of types (like `var x: a[0]`).
Re: how to run vim and get output
Having a conversation in two places at once is annoying, and I think this forum is much more valuable than Reddit, so I'll reply here: > Oh. Awesome! Thank you. I have been traveling with the family for the > holidays so haven’t been checking. I’ll test it as soon as I can. Knew I > should have been using a tempfile, but I didn’t bother since I figured the > issue with the Error was unrelated. > > Do you know what is different about ‘execCmd’ that makes this work? It's first important to understand how Unix terminals and [pipes](https://en.wikipedia.org/wiki/Pipeline_\(Unix\)) operate. A pipe is a simple one-directional stream of text, mainly designed for programs that dump output and exit, like `dmesg | less`. Running `vim | less` gives you a warning, "output not to a terminal", and then it's a mess until you exit. Vim is an interactive program that clears the screen, moves the cursor around, and interacts with the user until s\he exits. Vim can even let you edit multiple files, split the screen, show auto-suggest drop-downs, run other programs, etc. (Same for emacs, nano, mc, etc.) What it sends to stdout is a hodgepodge of strings and ANSI / [control characters](https://en.wikipedia.org/wiki/Control_character). Vim doesn't dump the full file(s) to stdout, but to the filesystem when you save. Nim's [execCmdEx](https://nim-lang.org/docs/osproc.html#execCmdEx%2Cstring%2Cset%5BProcessOption%5D) runs the process as a pipe, captures any output it sends, and waits for it to terminate - which Vim, being an interactive program, doesn't do until it gets user keystrokes for quitting. [execCmd](https://nim-lang.org/docs/osproc.html#execCmd%2Cstring) runs the program normally (manual says: "standard input, output, error streams are inherited from the calling process"), so that it can interact with the screen until it terminates.
Re: How to convert integer to pointer
Thanks a lot
Re: How to convert integer to pointer
Thanks for the tips. Actually, that was my question. I want to include type name in that user defined type. Is it possible ?
Re: Should we get rid of style insensitivity?
Case insensitivity is one thing, style insensitivity is another, and what Nim does is yet another thing. You probably know this but just for the sake of removing any possibility for misunderstandings for others: * Case insensitivity: `fooBar` == `foobar` * Style insensitivity: `foo_Bar` == `foobar` * Nim's style insensitivity: `foo_Bar` == `foobar`, but `F` != `f`
Re: Should we get rid of style insensitivity?
> Stating that the same group of people dislike style insensitivity, GC, etc is > a bold claim. That’s not what I meant. I suppose I should have been more precise :-). What I mean is that some people will find any reason to reject a language they don’t like. And why do they not like this language? Simply, because it isn’t their favorite language and all that’s different is bad. Programming languages have always been a very controversial topic. For me there is a big difference between people who don’t like the case insensitivity in Nim, but use the language, and those who pretend that they will use Nim if it was case sensitive. Nim has a lot of attracting features and I don’t believe that case insensitivity could prevent to use it. There are so much more important things. In fact, anything which is somewhat new has always been criticized. A new feature is a differentiation factor and, so, it must be fought. Python has, for a long time, criticized for its syntax, which truly is a differentiation factor. Guido van Rossum has not changed anything and he was right. Now, languages with a syntactically significant indentation as Nim is, are accepted. And, for me, this is an important feature (but, again, not one that could prevent me to use languages with traditional syntax).
Re: Should we get rid of style insensitivity?
> many of those who definitively rejected Nim for its case insensivity will > have, anyway, rejected Nim for other reasons Stating that the same group of people dislike style insensitivity, GC, etc is a bold claim.
Re: Should we get rid of style insensitivity?
There's a difference between having style insensitivity and writing/editing code (either manually or by a tool) to let you write your code in different styles. You could also write a tool to achieve this in C or use define statements and the like to do the same thing.
Re: Should we get rid of style insensitivity?
I think that changing Nim to get more users is exactly what should not be done.
A language should not be adapted to suit the opinion of a majority of potential
users. Rather users have to learn other ways to work.
For me, many of those who definitively rejected Nim for its case insensivity
will have, anyway, rejected Nim for other reasons: the fact that it is not
object oriented, its GC, the exceptions, its syntax, usage of keywords rather
than symbols ("and" rather than "&"), etc.
And I don’t buy the idea that there are lot of users who would prefer case
insensitivity. Those who are satisfied with the current situation do not say
anything. They use Nim, that’s all. It’s easier to find people who complain
than people who agree.
Look at other languages. Go, for instance, has chosen to use return codes
rather than exceptions. This is an important choice, much more important than
case sensitivity/insensitivity. A lot of people have complained. It was their
right, but Go designers have not changed anything. They have lost potential
users, me for instance, but have considered that a language should follow a
philosophy. That’s fine an I respect this.
Python is another example. When it was a young language, its syntactic
significant indentation has been a blocking point for a lot of users. At this
moment, Guido van Rossum could have get a lot of users by changing this. He
don’t. Slowly, the language has received more and more attention, until even
the most reluctant have finally learned it. For me, Python is the exact example
of what should be done: no concessions for major points. Whether case
sensitivity/insensitivity is a major point is somewhat disputable though.
Re: In the response always 4000 byte by AsyncHtpp request
@dom96 thanks a lot! ok, this is a special for FutureStream for string type. yeah, I did not understand what is use case the proc read of FutureStream[T]
