I generally like Nims approach a lot - but I think that @Araq is too hard on
this. The guiding rule should be "Nim prohibits false and dangerous things".
Naming (e.g.) private variables
'_[foo](https://forum.nim-lang.org/postActivity.xml#foo) is not dangerous and
whether it's false is largely
I had headeaches trying to find why my first opengl triangle looks like that
[https://nsm09.casimages.com/img/2018/11/16//18111610551424237015998588.png](https://nsm09.casimages.com/img/2018/11/16//18111610551424237015998588.png)
After two days I accidentally discovered that in a certain file
> There is an easy solution to this problem: case insensitive and style
> insensitive search (which is supported by nimgrep)
Most people edit their code in an editor or IDE, not with an external program.
And they don't like it when a language pushes another tool on them that, from
their
> A user is reading someone's code and wants to see all instances of a name. So
> they go using find in their editor and fail to pick up on all because some
> instances have underscores in their name.
There is an easy solution to this problem: case insensitive and style
insensitive search
dom96
YES! There is a genuine problem with the underscore magic that allows different
spelling of the same names: The problem is readability.
The also relaxed rules for referencing imports has exactly the same problem of
readability.
To make it very clear, consider these two examples:
1. A
Thanks, interesting alias syntax!
Also, there's some nice syntax for aliasing over in the issue tracker over here:
[https://github.com/nim-lang/Nim/issues/7090](https://github.com/nim-lang/Nim/issues/7090)
Edit: Have also requested that this be added to the Nim Cookbook:
> Araq if you want to succeed with this language you need to realize how silly
> it is to have style insensitive name parsing.
It really isn't that big of a deal. Don't judge a book by its cover. Try the
language and if you find some genuine problems with style insensitivity then
report them.
Thanks Wizard for pointing out that this comes from Ada. Now at least there is
an explanation for it.
Besides OpenGL, there's also SDL2, which can't be faithfully represented
because of partial casing, eg SdlError enum, vs say SDL_Error.
On the other hand, recently working with Ada, I see there's a lot of case
insensitivity there too, which is a point in it's favor:
Araq if you want to succeed with this language you need to realize how silly it
is to have style insensitive name parsing. Its even dumber than not declaring
types which you have already identified was a bad idea. Strike it off before
1.0.
> I guess I can work around any problems caused by partial-casing, but honestly
> I would like to see this project become more community-driven. That is the
> biggest concern I hear from colleagues when I suggest adopting Nim.
"Community-driven" is fine with me, but arguing all day long on the
> These points are not massive deal breakers but i always get the impression
> when people advocate for something, Araq reacts like people step on his toes.
> People are putting a lot of time in discussing things and looking for
> solutions. But the impression is that people just need to shut
About Website Design / Documentation: There is stuff in the works and it may
end up being all good eventually. Thinking that the main developer can fix all
of that while also working a day job is just a bit blue eyed. Nim is in fact a
hobby project. Being a bit more grateful to a person which
> ALLCAPS
They have a place ... I still think all caps is perfectly reasonable for
constants. Variable & constants mixing makes things more difficult if they all
look the same. And marking variables like cFoo, vFoo is just silly.
> honestly I would like to see this project become more
> You could call this a language bug (or a feature), but I say it's evidence
> that this whole partial-casing idea was not considered clearly.
I'm sorry but the fact that module names fight with proc names in the same
scope is entirely different issue. Sure, you can avoid it by casing the proc
I think @araq is doing a great job and him being stubborn in some cases does
makes perfect sense to me. We all can be happy that he has strong opinions
about stuff. Nim language design itself is not really community or committee
driven. It still is his language and he decides what Nim is about.
> > I'm in the majority, by a wide margin.
>
> _Shrug_, so are the people who don't like indentation based syntax
That's silly. Python has similar syntax, and I always tell people that Nim is
Python + Ada + C. People who complain about enforced indentation should be
using a more verbose
@Araq
> and I don't want ALLCAPS in my language
Do you know
c2nim --nep1 h.c
cat h.c h.nim
enum TrafficLightState
{
OFF,
GREEN,
YELLOW,
RED,
RED_AND_YELLOW
};
type
TrafficLightState* = enum
OFF, GREEN, YELLOW,
> Why can't someone else do it?
Fair enough, somebody else can do it. My work is then only to review the patch.
The problem is though, that on top of the "it's work for me" argument, I don't
want the feature. I don't see the point. The conflicts that do arise are all
about ALLCAPS and I don't
All good points, except this one, which is a real problem:
> Changing it now would mean more work to me.
Why can't someone else do it? It seems like OderWat is almost volunteering.
Maybe it would be too hard. But I would love to see you say, "Hey, OderWat.
Would you look into adopting full
> Maybe that's a fair justification for partial-casing?
I consider it to be largely orthogonal really. But coming back to `ALL_CAPS`
macros. They are this way because C's preprocessor doesn't know anything about
C's scoping rules or C's symbol table. ALL_CAPS are an archaic hack, and
wrappers
I wrote:
> Anyway, I do see your point. With `--nep1`, we're actually making disparate C
> APIs look similar within Nim. Maybe that's a fair justification for
> partial-casing?
Rethinking, actually it seems the other way round. If we had case-sensitivity,
then `c2nim --nep1` could be used to
I know in scala (and possibly other programming languages), there is the option
to rename imports.
import some.package.{fooBar => foo_bar}
According to the documentation here:
We can't afaik. The symbol table is about hash values and those are hard coded
(see hashes.nim in the compiler) at one place and classic string compare
cmpIgnoreStyle() in another one (see idents.nim). I did not understand all of
it though.
Or, can we have the ability to modify symbol table in macros?
In this way, both `rename` and `alias` can be implemented in library.
Templates can not be used for simple aliasing of a procedure name like this
`template echo = print`. You need to specify the parameters and that brings
problems if you have a lot of overloaded functions or when they are from FFI.
You can simply duplicate anything with a macro or create a macro
> would like to have a new "alias" functionality
Was thinking about it a few times...
For example, I have a longer proc with return type View. Can use predefined
result variable in the proc, but then I have to remember that result is view.
Or I use "var view: View ... return view". alias view
Having `alias` functionality would be good regardless of the rest: for now
templates are used for aliasing, and they are too general for such a simple
thing.
>From looking at the code I think:
* the compiler could be made identifier CS
* probably pragmas CI (thats a bit harder because I think they are stored the
same way as all identifiers)
* ignoring underlines removed
* allowing underlines in front and back.
This would need few fixes to
> -> IntelliSense / Code completion
If it is really so "intelli", it should follow your casing (and guess your
casing from the file you are editing).
I don't use code completion so I may not be the right person to discuss this.
> -> People following guides. Good luck on that. I can guarantee
> This is offtopic, but it really shouldn't. If the casing where all that
> important, how come every URL I look at starts with 'http(s)'?
Well I didn't mean to start a discussion on that, but just give an example
showing that `snake_case_Caps_allowed` contains more information than
> With partial casing, who give a f*** about the library author's casing style?
> Just follow the style guide, no matter what.
-> IntelliSense / Code completion: Will follow the original authors there
casing. In other words you are then forced to use code completion & edit the
code structure
> Why the hell do the Nim OpenGL guy do the same thing with a much richer
> language? Why are they implement enums as const s?
Because I wasn't aware of the XML thingie at all and people improved my
original wrapper. :)
> How do you know that HTTP need to be in ALL_CAPS?
This is offtopic, but
* **I find partial casing can better enforce the casing style**
Your organization must have a style guide and it must say something about
naming convention and casing style (What? You don't have such thing? How crazy
are you people!). And all of you are following that casing style. Then,
> It would take similar effort (in sum) to fix the few problems in the Nim std
> library as it takes me to fix the problems each time I run c2nim.
Do you know about `--nep1` and `#mangle`? I used c2nim to wrap hundreds of
thousands of lines of code. Yes, it's some work, but the results are
> But striving for overall simplicity would mean to get rid of 99% of Nim
> (macros, templates, converters, pragmas, ..., lots of stuff) and to create
> quite an opposite language - then why to begin with Nim.
Its not about removing features LeuGim... Its about making them more user
friendly.
_OderWat:_ There is nothing wrong with Basic or simplicity, just each language
has some its characteristic feature, its accent. There cannot be C without
pointer arithmetic, or Java without OOP, Basic without simplicity, Haskell
without functional programming stuff, be each of those accents
> And changing it WILL break a lot of code... I don't even think that this
> could be done without harm to Nim.
\---
In all honesty, a default is better as fixed state, with the ability to
override to stateless if people want to use it like that. The argument that it
will break current code
Basic was probably one of the most influencing factors for us all sit in front
of computers. C is also a pretty simple language, as is Javascript. There is
nothing wrong with keeping stuff simple.
Nim kinda suffers from feature creep for a long time. You can call it
experimenting though.
> Simplify, simplify, simplify
Such a language already exists, Basic. But instead of just using that probably
it's more fun to choose one of the most feature-rich languages and advertise
triple simplicity for it. Then further steps: promote rejecting pointer
arithmetic in C and OOP in Java.
BTW: Why not giving my font to the compiler so that he can decide which
identifiers look to similar for me to use?
I'm torn. I _love_ Araq's attitude on this. He's right that languages should
reject similar identifiers, or flag them, or consider them the same. It's bad
coding.
However, I'm not looking for the perfect language. A major strength of **Nim**
is the easy foreign-function-interface, and this
> For example, GLint / GL_INT is a problem - I mean, IIRC doesn't one represent
> an int type and the other an enum? Is that sensible naming? The source of
> this particular problem is the library, not CS/CI/_. I just think they're
> named badly and are ambiguous about what they really are.
Seems like there are two separate things in this thread.
* One, some people don't want _ to be ignored,
* Two, some people don't like case insensitivity.
In my _opinion_ case insensitivity is better.
> What are the pros and what are the cons of 100% matching identifiers. I do
> not see
@LeuGim: But that would mean I had to write if structure.structureType =
StructureTypes.STRUCTURE_TOWER. I think that would be even worse :)
I just changed the compiler to at least not ignore _ such that foo_bar !=
foobar != fooBar. That is quite easy and needs just some few fixes in the
> That is leaving the audience to cope with a design decision based on a
> personal opinion. And yes. This is my personal opinion.
Its not only your opinion because i also agree with you. It has advantages but
the disadvantages do seem to out way the advantages.
**Non-uniformal type
_OderWat:_ {. pure .} could be used for the enum in your example, no renaming
then needed.
* * *
I'd like some special character to be allowed at the end of identifiers, be
that underscore, or (better) apostrophe (`'`), or something else present on
keyboards. `x`, `x'`, `x''`, or `x`, `x_`,
@Araq Please try to be objective. Nobody forces you to change anything. You can
leave the style insensitiveness in this language just for the sake to
distinguish it more from other languages and make Nim a more unique experience.
I think everybody can live or deal with it, there are no major
I want to be polite but I find it just ignorant to say "search tools should
become smarter..." because one of the search tools is my brain and my brain
says: foo_bar != foobar != fooBar. That is leaving the audience to cope with a
design decision based on a personal opinion. And yes. This is my
* Search tools should generally become smarter anyway. And the Unix "tools"
are all abominations anyway.
* the indirection would be necessary anyway for performance.
* It's just better than other programming languages.
* Compile-time errors are not "bugs".
Yes this get's discussed a lot. And yes there are problems:
* Non-conflicting names in C libraries become conflicting names in nim
wrappers. See OpenGl wrapper for example. (No `cGL_INT` is not a sane name)
* common search tools such as
The only time I got a problem so far is in Nim-Screeps. There I would need
something like this:
type
StructureTypes = enum
STRUCTURE_SPAWN
STRUCTURE_TOWER
Structure = object of RootObj
structureType: StructureTypes
@araq ... nobody enforces you to write _foo but I would love to use _ for temp
variables or proxied values. I don't see any reason why a programmer can't use
them as he wants besides your opinion about what is ugly and what is not :)
We generally do not have to write _foo. My suggestion was only for the few
people who needs this feature, maybe to wrap an exotic lib without being
willing to put much work in text mangling. That people can use full case
sensitivity with underscores for VERY FEW identifiers and are happy. And
> That is easy to implement and allows to fix ALL of the rare real problems.
It doesn't fix the problem that I don't want to write `_foo`. Nim is not
Python, it doesn't need ugly naming to indicate "that's private" or "that's a
member" or whatever the distinction between `_foo` and `foo` should
@cdunn2001 > partial-casing causes problems.
Can you provide examples?
For the gtk related libs, I had initially indeed problems two years ago when
Nimrod was fully style insensitive. But now with partial casing there are no
problems, types like Buffer start with capital letter, and procs or
What kind of problems? All I know it means you have to come up with sane names
sometimes. You know, names you can actually _talk_ about. (I know talking about
code is uncommon, but still.)
> Partial casing is simply the next logical step, IMHO. As our editors grow
> smarter and smarter they should allow us to present the code in the way we're
> most comfortable with. This means the freedom to render fooBar as foo_bar
> instead. What's necessary to accomplish this goal? fooBar has
I agree it causes problems, but having identifiers in existing libraries with
same partial-cased names is very rare. (It might be a good idea to allow _XX
and XX_)
Making partial-casing a compiler flag is a worse idea than disabling it (most
existing code anyway won't compile with this flag).
59 matches
Mail list logo
