> 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 f
> 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 up
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 sp
> 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 o
> 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 community
Oh, btw, I have found another area where partial-casing is restrictive:
bar.nim:
import typetraits
proc bar*[X]() =
echo "bar:" & type(X).name
foo.nim:
import bar as nil
when isMainModule:
bar.bar[int32]()
Leads to:
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 languag
WTH? I like ALLCAPS and use it with pride!
@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, RED,
> Shrug, so are the people who don't like indentation based syntax. "Designing
> for popularity" doesn't work for me, I don't want to design TypeScript.
Hate to tell you but at some moment your going to lose control over the
project. Most languages when they become big, the original developer wi
> 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 w
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 case
> 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 s
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 m
Yes, I've used `#mangle` before. _Very_ helpful.
`--nep1` is interesting.
My complaint -- that the C library being wrapped could have conflicting
identifiers -- is a minor one. I can always find ways around that. UPPER_CASE
macros are the most common collision, and that's not a big deal since *
> 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 reall
17 matches
Mail list logo
