> `{.prototype(extensible).}` These could also be valid inside the defining
> module.
Yes but you have submodules then. How to make it explicit in recent Nim, it's
not in the language yet. Your syntactic extension looks reasonable.
> A general thought: prototypical/exemplary definitions seem to
>A required goal if we want to get out of today's whack-a-mole type system
>development. ;-)
> Whack-a-mole ? Type system ? Really?
Imperative languages do offer product types for both datatypes and function
types and typechecking via identity. Some coercions, e.g. int8 -> int32, and
conversio
> A DSL for type calculus and transformation rules which produces the compiler
> code for type verification and resolution and defines new type
> implementations with Nim's existing types as building blocks; is that a pipe
> dream or a realistic goal?
A required goal if we want to get out of to
> I'm sorry, but you didn't get the irony here
I guess the joke's on me. I couldn't decide if you were serious or not :-)
Me:"Well, concepts were newly introduced (Dec 2020), the draft paper had 380+
pages, so give C++ a try, the language will mature soon."
> If you read the code at the end of the message you replied to, you'll see a
> translation into C++ 20 which compiles with both clang and g++
> (--std==c++20)
> Well, concepts were newly introduced (Dec 2020), the draft paper had 380+
> pages, so give C++ a try, the language will mature soon.
If you read the code at the end of the message you replied to, you'll see a
translation into C++ 20 which compiles with both clang and g++ (--std==c++20),
and d
Really interesting, as your comments usually are. I've started diving into type
theory and things you, @timothee and others have contributed are part of the
reason.
A modification proposal: the minimal one-pragma approach is elegant, but let's
not break import visibility semantics: the meaning
...but we omitted the star at Gstack. This makes the type _extendable_ . Due to
the {.prototype.} pragma, the compiler knows that Gstack is a virtual type will
be exported. But now, the user programmer could write:
* Gstack[U] = Ustack[U]
and therefore extend Gstack with a new implementatio
> For those who use C++, C++ 20 concepts fail this test as well
Well, concepts were newly introduced (Dec 2020), the draft paper had 380+
pages, so give C++ a try, the language will mature soon.
> BTW, nice example! I hope you file an issue.
IDK. Probably not. The typing world has changed consi
Reading the [new style concepts
RFC](https://github.com/nim-lang/RFCs/issues/168), we see that the first goal
is
Empower concepts to make generic code type-checkable at declaration time,
not only at instantiation time.
Run
>From that we can draw some hope that th
It trusts the user.
The concept is not checked in the procedure body during the declaration, like a
regular non generic type would be. That's unfortunate. I wonder if there's a
conservative solution to rule out cases like this without making the concepts
unusable?
For those who use C++, C++ 20 concepts fail this t
> There is nothing to prove really. These annotations override the compiler's
> reasonings.
Well I mean if an acyclic prameter/type is acyclic, but it's to complex to
figuring that out, does the compiler trust the user or is an error issued?
> What is the strategy for these 5 things, if the compiler can't prove them for
> certain situations, is then an error issued or not?
There is nothing to prove really. These annotations override the compiler's
reasonings.
> Nim's type system, Concepts. Do they provide statical guarantees? Let's see...
I find having both generics and templates is too much. Either approach has its
advantages.
Concepts provide positive guarantees, but not negative guarantees. Nim will
still use static duck typing to try to substitute the type, and if it works,
cool.
Nim's type system, Concepts. Do they give statical guarantees? Let's see...
#{.experimental.}
type
Aclass = concept x
x.inum is int
Anobj = object
fnum : float
inum : int
Bnobj = object
text : string
inum : int
> It doesn't compile, but you get the error report only if the function gets
> used really. This is expected behaviour within Nim because Nim resolves
> Generics late and ad-hoc, this will say using concrete types when all generic
> types are gone.
Sure, this is like C++ SFINAE. This is why I s
> @juancarlospaco, why the scare quotes around "bugs"? At the very least, the
> code in @sixte's first code block that is marked as ill typed, should not
> compile.
It doesn't compile, but you get the error report only if the function gets used
really. This is expected behaviour within Nim beca
> So far there are no plans to go beyond sink/lent/move/cursor/acyclic. I know
> these 5 new things can be a bitter pill to swallow but they are opt-in and
> also address issues existing since Nim's initial design, not only "memory
> safety". To the best of my knowledge the design is reasonably
> The program compiles and prints the content of the sum type Stype as expected.
Terminology nit: Maybe it's just me, but I wouldn't call Stype a "sum type". I
reserve that for Rust/Swift enums or OCaml variants. You'd model sum types in
today's Nim with object variants. I hope tomorrow's Nim fo
Yep, you can write type edgy "bugs" like these on Python and Typescript too.
Generics and Nim's type system again, let's see what we have. We have:
import typetraits
type
Atype[T] = object
data: T
inum: int
Btype[T] = object
jnum : int
data: T
Stype[U] = Atype[U] or Btype[U]
> also think there's far more benefit to fixing Nim than developing a Nim
> inspired C dialect
Honestly, the main motivation for the NimC example was to smuggle in an
innocent looking typedef [T]; working as a generically defined type through the
entire file. The same thing could be done with N
> I told you but you won't listen. ;-)
You might have told me but perhaps I didn't understand. At least, I learned
that actually the LLVM target is not a viable alternative to C.
So, please try to explain it again. Especially how to deal with a stackless
memory model. . (It is not an accident t
Did you file issues for this yet?
I also think there's far more benefit to fixing Nim than developing a Nim
inspired C dialect, but you've got to do what you want.
> So we can safely conclude that C should not be used as a target language
> longer. Oh wait...
No, we generate C because it has excellent optimizers... The portability is
nice too. But it's closer to Algol than it is to an assembler. The subtle
aspects of its spec make the Nim compiler harder
> It's 2021 now, C has "volatile" and dozens of subtle concepts. Now you can
> argue all of this was required, but the fact is that it is not "simple"
> anymore.
So we can safely conclude that C should not be used as a target language
longer. Oh wait...
The basic idea of NimC was not to promot
> When C came up, it felt pretty intuitive...
The stack/heap split was already in Algol and Fortran, but ok, it was
intuitive, in the 70ies. It's 2021 now, C has "volatile" and dozens of subtle
concepts. Now you can argue all of this was required, but the fact is that it
is not "simple" anymore
> assembler allows for control flow that C doesn't; an assembler's syntax is
> more regular and thus easier than C's, an assembler allows easy access to
> overflow flags, an assembler doesn't conflate pointers and arrays, and
> finally an assembly language doesn't have very subtle aliasing restr
> C is not a portable assembler, the machine code you get out of a C compiler,
> while somewhat predictable, isn't more predictable than e.g. Ocaml's machine
> code it's less predictable because C has the better optimizers.
When C came up, it felt pretty intuitive, producing small binaries and
> help us to define what Nim's type system actually is
Let's see.
type
Atype[T] = object
data: T
inum: int
Btype[T] = object
data: T
iinum : int
# Atype and Btype are isomorphic, however they do not have the sa
> I'll now consider NimC...
We simply need better education... C is not a portable assembler, the machine
code you get out of a C compiler, while somewhat predictable, isn't more
predictable than e.g. Ocaml's machine code -- it's less predictable because C
has the better optimizers. Furthermore
I have a couple of intentions with this thread (stackless Nim <=> statefule aka
"static" Nim, Linear Programming, Call-by-Name in Nim) but letting all these
nasty things aside, I'll now consider NimC, not a new C, but a "tainted" or
better painted C that brings Core-Nim's memory model and Nim's
> I hope Nim will not go into the Rust direction.
Again... It's a little bit too late for these remarks and fears. We copied the
inspiring things that Rust offers, made them work well for Nim's design and
called the result `--gc:orc`. And even though you should not praise yourself
... I'm not l
I hope Nim will not go into the Rust direction.
I gladly pay x2 and even x4 more memory and CPU cost, just so I don't have to
deal with things like Rust. :)
i understand the arbitrariness of the choice, and the ugliness of the
asymmetry. maybe my lack of understanding is about what the metaphor of
'ownership' represents. In my mind, it represents the locus of control over an
objects deletion, as defined through différance with a viewer, which can ke
> i'm more familiar with the idea that one of the next or prev refs be owned,
> the other a view.
Do you prefer the left or the right side? A good doubly linked list
implementation should provide two entrypoints, one to each side. Insert and
Delete will work identically for both pointers.
How
> In a doubly linked list, every node inherently has two owners.
can you explain this model? it seems to me that multiple ownership is the same
as none. i'm more familiar with the idea that one of the next or prev refs be
owned, the other a view.
Memory safety is a multipolar discipline. Linear type theory describes how
ressources move through the program. A "viewer" is part of a triple
(Owner,Data,Viewer). We have a sequence : (Owner,Data,None) =>
(Owner,Data,Viewer) => (Owner,Data,None). As long as the viewer is active, the
data alloc
Can't say I agree, "simplicity" is not a value in itself or else we would all
still be writing assembler code. (Yes, assembler is simpler than C, it's not
simpler to use, but you focussed on language simplicity.)
> When a language decides to add three new keywords, it does not result in
> three
Memory safety is good. If you can make it happen, by all means you should. If
you can't, it is okay to have manual memory management. There is nothing wrong
with it.
Some people tend to think that C/C++ bugs result from its manual memory
management. That is not entirely accurate. The occurrence
Thanks, I spotted the bug now.
Works for me and the newer version of the document is a complete example, no
need for a `resize`.
> Every type has =destroy but it can be "trivial", like in C++.
When I took the code from the destructors manual, added a missing `resize`
proc resize[T](x: var myseq[T]) =
x.data[x.len] = cast[typeof(x.data)](realloc(x.data, x.len * sizeof(T)))
x.cap = x.len
> What's supposed to happen when you have a sequence of elements that don't
> have an =destroy, like ints? Can value types get an implicit no-op =destroy?
Every type has `=destroy` but it can be "trivial", like in C++.
> To the best of my knowledge the design is reasonably complete and the
> implementation is catching up.
Cool! Quick question about that: in the destructor manual, the _mostly_
complete example (needs 3 line implementation of **resize** ) of defining a
myseq calls the `=destroy` on all the elem
> It seems that Nim is now exploring the ownership ala Rust (sink, lent, move).
> I certainly hope Rust lifetime stuff does not creep into Nim.
So far there are no plans to go beyond sink/lent/move/cursor/acyclic. I know
these 5 new things can be a bitter pill to swallow but they are opt-in and
Even though Nim has lots of GC options, most seem like toys or are for special
use cases. Like @Araq mentioned
[here](https://forum.nim-lang.org/t/7927#50492), `--gc:orc` changes a lot for
Nim's coming evolutions/additions.
Simplification of Nim can easily come in the form of better defaults (l
My ideal language is something like a modern C or a minimalist C++. A language
with built-in concurrency library, unicode support, basic OO constructs,
generics, intuitive metaprogramming, clean syntax, easy interoperability with
C, and performant. Being memory safe is a plus, but I am fine with
I agree with most of your points, but I mind
> Until now, macros can only deal with Nim-parsed code and therefore the Nim
> parser is in the way.
How is it in the way? You can easily write compile-time parsers that work on a
triple quoted string literal and produced NimNodes, see how `strformat
Nim is in the line of classic programming languages: FORTRAN, Pascal, C. Nim
represents a minimal (if not THE minimal) closure over C's memory model.
* FORTRAN did not use a stack for variables at all, because any of these were
placed in global memory. Recursion did not work of course, but the
52 matches
Mail list logo
