I can think of an example where the concept = container logic fails. Let's
assume that we have `Set[T]` concept, and one would like to implement it for
`T=char` by using a bitfield (that's 4 times 64-bit `int`, so it is an
`array[4, int]`). This could be `Set[char]`, however, there is no `char`
I don't want to announce a time frame right now, because I also have a day job
:)
The idea is pretty simple: We collect all the docs from all the modules which
are in nimble automatically and add the docs of the compiler and the manual
itself.
Those get indexed by the Nim compilers own doctool
@OderWat Have you any information on the creation of the better documentation?
I was planning a documentation site like php.net for nim.
I like the idea of external but integrated example files. Dropping a 50+ line
block right into the code base never seemed like the right idea.
> 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
Well. It could be as simple as creating PR where multiple people working in
collaboration to add to the documentation. There is no need to extract them
from the sources and re-inject them again.
For some key modules there also could be some example.rst files which get
included with the module a
I don't know about StackOverflow Documentation, but the GitHub wiki allows
exporting pages. We could use it for collaborative editing and then extract
good pages and merge them into the mainline doc at release time.
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
LeuGim said:
> For me it's allowing to write code compact and looking intuitively, and
> having many solutions to the same task, at programmer's choice. Something
> characteristic for Ruby, but even more so for Nim.
Completely agree! I haven't felt so liberated using a programming language
sin
There is work being done right now to create much better documentation for Nim.
The basics are done and we figure out some of the details and work on the
implementation.
This will be based on the current way on how Nim documentation is written.
Inside the Code, with optional includes of additio
@wulfklaue: I don't believe the intention is to replace the standard docs, but
the StackOverflow docs would instead be more concentrated around providing
examples, which I personally am all for.
WTH? I like ALLCAPS and use it with pride!
It looks interesting but i reserve some doubt about having a 3th party hosting
the documentation. And it also raises questions about synchronizing the
documentation in the code with stackoverflow...
Based on some of the previous comments/concerns over Nim documentation, this
seems like it might address some of the issues:
[http://stackoverflow.com/documentation/nim/commit](http://forum.nim-lang.org///stackoverflow.com/documentation/nim/commit)
Upvote if you're interested.
Now I can reproduce the error too. Very interesting, this code below works,
maybe someone else can explain this phenomenon
cap.add("test")
var tmp = cap
env[].ReleaseStringUTFChars(env, input, str)
result = env[].NewStringUTF(env, tmp)
@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,
Thanks for taking the time to reply.
Just a quick reply, I didn't have time to think about the answers too much.
@Araq: I think that your proposal would work not only for containers. It would
probably work for channels, streams, files as well.
@andrea: I understand the motivation, I'll think ab
> 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
This works:
type
Node* = concept n
`==`(n, n) is bool
Graph* = concept g
var x: Node
distance(g, x, x) is float
Applying it to your example yields:
type VectorSpace = concept x, y
x + y is type(x)
@Araq I feel that restricting `Concept[T]` to containers is very limiting and
will in fact make it impossible to define many abstractions.
Let me give an example. In [emmy](https://github.com/unicredit/emmy) I have
more or less the following defition of a field.
type Field = concep
Among extraordinary features Nim has is the {.emit.} pragma, that allows to
drop in chunks of C/JS code. So "porting" C/JS code can be done almost as fast
as copy-paste. And that would not be possible if Nim used LLVM or some other
direct codegen. Also note, that there is a lot of custom hardwar
> directly compiler is necessary.
No it is not... By compiling to C and then having the "actual" compiler turn
that C code to system code, it has several advantages. One of those is simply:
You use all the optimizations that are present in the used compiler to gain
more speed.
Take a look here
What have I changed: in Sample1.java main function now is:
public static void main(String[] args) {
System.loadLibrary("Sample1");
Sample1 sample = new Sample1();
int square = sample.intMethod(5);
boolean bool = sample.booleanMethod(true);
Let's go through your examples now.
type StrangeConcept[T] = concept c
c is T # Equivalent to "c is any", which is true
float(c) is T # Equivalent to "float(c) is any", which is true
$c is T # Equivalent to "$c is any", which is true
when int is StrangeConcept:
> Now I'm stuck at a language design question, how to find out T in concept[T]
Congratulations. you're definitely on the right track! :) That's the tough nut.
I have the following proposal, but I'm not sure it answers every one of your
questions. The idea is that `concept[T, ...]` is always used
Hi Guys,
I need your help. In the past two weeks I spent roughly 30 hours debugging the
compiler to add proper `concept[T]` support. It feels like I'm at half of the
work. Now I'm stuck at a language design question, how to find out `T` in
`concept[T]`. I don't have a good proposal. Please take
> 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
I didn't encounter the problem you've mentioned. I also increase the upper
limit of for loop to 100.000 and everything still fine. I manipulate the cap
variable here and there and still ok. What exactly you've done?
**gcc** actually produces assembly code and assembles it using the **as**
assembler. And nobody complains gcc borrow an assembler. and the assembler also
produce object file which is linked by linker to produce executable. I don't
see the point why Nim need to become something like rust and go.
Why Nim language unlike rust and go language, the same direct compiler, Nim is
compiled to C, it borrow gcc compiler, not borrow any other compiler directly
compiler is necessary.
37 matches
Mail list logo
