Mysterious error message

So it turns out that a distinct returntype is pretty much useless and should be avoided.

Mysterious error message

Well, the concatenator '&' works well with two distinct strings. So, their types match. The `else` branch of the `when``should not be seen - it is statically clear that the first branch gets used. Since the ``else` branch is not used, it should not create a new distinct string. And it is a simpl

Mysterious error message

The following program does not compile: proc addoneb(a : distinct string, b : distinct string) : distinct string = when typeof(a) is distinct string : let v = a & b result = v else : result = cast[distinct string]("") proc run() =

Nim v2: what would you change?

Looking at the content of this thread and the (mostly conflicting) requests for new features, one comes to two possible conclusions: either the language is still in its infancy and awaiting a concise definition, or the language is on the verge of a split. Into different branches though. The cor

Why I left the Nim community

Well... _every Nim developer will eventually run into exhaustion_ The reason is rather technical than personal. Why? * Nim is agnostic about type dependencies * things become considerably worse when function overloading is mixed with function typeschemes aka "generics" so both the program

Nim v2: what would you change?

> I also don't like * as the public marker. > It's not readable or intuitive. > A newcomer to Nim will have no idea what * does when stumbling across it > the first time in a codebase. (the rest of Nim's syntax, by comparison, is > very straightforward.) The "*" export marker comes from Obe

Nim v2: what would you change?

> rust/haxe style enums instead of the currently confusing object variants With Haxe style enums, _Generalized Algebraic Data Types_ are possible. These haxe/rust style enums can be seen as datatypes on the fly. Look at: Whe

Nim v2: what would you change?

> Just want to reiterate: please focus your suggestions on ones that require > breaking changes. I’m seeing responses which don’t fit this. Well, I have something for you that certainly would require breaking changes. Something that contradicts the definition of the language. See :

Nim v2: what would you change?

> Enable circular dependencies to overcome complexity barrier (I don't want to > redesign existing C/C++ projects to make my idea compile) Both module instantiation and object instantiation do not allow for circular dependencies because an abstraction layer is missing.

Nim v2: what would you change?

Introduction of existential types, e.g. on the module level.

Seeking advices for a C programming book

> Indeed, Ada generics suffer from this deficiency as well. It was an important > factor in my decision to stop using Ada, even though I liked many other > aspects of it. If you have module-wide types, you might be tempted to instantiate or over-instantiate them. Both Ada and Modula-3 allow thi

Seeking advices for a C programming book

I can offer you another language comparison: Oberon-2, Modula-3, Sather and Self with focus on "object orientation". It is particularly because of the asterisk "*" annotation that you can find both in Oberon and in Nim. [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.6912&rep=rep1&

Seeking advices for a C programming book

> So 2.5.5 isn't generics ? Yes, it is. Both Modula-2 and Modula-3 allow module-wide "polymorphic" (abstract) types. In addition, Modula-3 allows "generic" types (explicit type parameters) on the interface and module level. Due to abstract types, both Modula(s) support static polymorphism witho

Seeking advices for a C programming book

> The version of Modula 3 that I looked at had no generics Modula-3 has _abstract_ types like Modula-2 has. They allow for modular (separate) compilation. > Nim follows C++'s take on generics C++'s templates allow for abstract types too. It is a hidden feature though. I demonstrated it within:

Seeking advices for a C programming book

> Most points I brought up equally affect LLVM too. ;-) Unfortunately. With a strange syntax... So do I have to define my own intermediate assembler or are there alternatives?

Seeking advices for a C programming book

So, would LLVM be a better choice? C is basically a stack-based reimplementation of FORTRAN for the PDP 11. The "++" and "\--" were directly taken from the PDP 11 Assembler. The "register" keyword was important in a time where automatic register allocation was not available.

Seeking advices for a C programming book

> Nim has not much "context" with C, whatever that means, it's Modula 3 with > Python's syntax and Lisp's macro system. But where is Modula-3's _opaque_ type then? It seems that a "tiny" abstraction layer is missing in Nim. If this is intentional or accidential, I don't know. Anyhow, it has som

Nim 1.6.2 : silent program rejection

Well, no segfault was reported. The compiler "died" silently. Linux Mint, VSCode.

Nim 1.6.2 : silent program rejection

I just downloaded Nim 1.6.2 via choosenim. The tiny program type PCset[T,V] = object of RootObj cnt : V pc : ptr T PTa[V] = object of PCset[PTa[V],V] dummy : int proc show[V](a : PTa[V]) = echo a.cnt # #[ proc runb

Why don't build Nim libraries ecosystem on Rust ecosystem?

> As Rust doesn't have GC, it should be also faster in theory That's not true. Both Rust and Nim allow for dynamic heap management and both rely on reference counting (RC) for that. The Nim compiler optimizes RC heavily (runtime elision), therefore, many refcount updates can be avoided. I doubt

Module typing, code reuse and separate compilation

I deeply apologize for the inconvenience. A bit of an irony here: I took the quotes entirely from section 6.3 , headline "practicum". They are the least technical part of the entire paper. I added some context about the motivation , side effects and relevance for imperative languages. If you wan

Module typing, code reuse and separate compilation

I just recently stumbled over a paper from Karl Crary: which aims to solve the “avoidance problem” aka “implicit abstraction” problem. Implicit abstractions occur, if a program does take advantage of a type that it doesn’t know about. The

Changing a generic return type automatically

> I definitely need some way to decide what to return at runtime Nim resolves statically and this is a good thing. If you want it dynamic, you should go for Objective C, Ruby (Crystal) or Javascript. Nothing wrong with these languages, they have a different purpose, they work well in and for ver

F-bound polymorphism in C++ and(?) Nim

You want to have FibTask as a type and a type scheme parameter at the same time, but only one of them is possible. Nim is based on instantiation types - and resolves by instantiation only, no abstraction available. Therefore, it can't instantiate a type parameter with itself. A concrete type is

A rant about Nim bugs

> Nim has a theoretically strong foundation And the theoretically strong foundation is what?

F-bound polymorphism in C++ and(?) Nim

Hi, I wanted to encode entities with an "intrinsic" (existential) type and a thing that comes close to it is described in : I had to extend the pattern a bit with a template taking two types, the latter for the intrinsic type

Macros: why and/or when to use them?

> If we're going to talk about modularity, one could do worse than making > modules instantiatable using type replacements. This would allow for (re)instantiable module-wide type parameters. Unfortunately, Araq already dismissed it: "too ugly". The topic has been discussed extensively in :

Macros: why and/or when to use them?

> And again, "everything depends on everything else" is the opposite of > "modularity", it cannot hurt to use the correct terms. So, do you want to go for "a program is a single (albeit large) equation" or do you want to go for orthogonalization (factoring out parts of the program and their equ

Macros: why and/or when to use them?

> But I know that I don't have any problem with modularity in other languages. You want module extension. In fact, you have a module **A** with type X and a module **B** with a type Y and then you extend **A** with **B** that can be read as **A[B]** so you "plugged in" the B into the A. Now you

Macros: why and/or when to use them?

There was a typo. UXT and UIT are "constructor helper types". The UIT could simply be a value with a parametric type. If you pass it a number, an int, an IT with an int will be constructed. With a string, IT will contain a string. The helper is not identical with the target IT type. But it could

Macros: why and/or when to use them?

>Visibility is not the problem, it's a phase ordering problem. * visibility problem <=> phase ordering problem Well, 100% separate compilation can be achieved if we split the program into a general part and a DLL. But we don‘t need to go so far. A C compiler could in principle do the split

Macros: why and/or when to use them?

> Hardly, it depends on what you mean by "modularity". You cannot have it both > ways -- you claim that we ignored 50 years of research into type systems > which for me basically means "you ignored ML, Ocaml, Haskell" I'm addressing imperative languages only. The paper (slide show) did mention

Macros: why and/or when to use them?

@Araq > language adoption is driven by external factors such as "companies behind it" > and "availability of library X" and "tooling support". Whether we like it or > not, "best type system ever invented" doesn't matter. This sounds rather depressive to me, it sounds like: „We don‘t have the mo

Macros: why and/or when to use them?

> I know that this is my personal problem. Whenever I try to learn macro, I got > distracted from it. The reason is interesting. I want to access type X from > module A in module B. And I want to access type Y from module B in module A. > And Nim is not allowing this. Nim suggest me to plan my c

Garbage collection of nim vs pony language

quote: That's one small step for a man - one giant leap for mankind

The Cylons have a Plan

> OCaml uses explicit types in this case and some others (GADTs? It's been a > while, I could be mistaken) OCAML uses modules primarily and GADTs are an add-on introduced late, in 2012. I'd go for GADT's indeed, specialized for module inclusion/membership. We have: type MA r

The Cylons have a Plan

Well, there is much to say about it, the very first thing being the notation of the `N` as a "free running parameter". But it is not as free as it seems, because it is now declared as a part of `NTuple`, in fact, `NTuple` establishes its own namespace. I would write it (almost) as a repeat of yo

The Cylons have a Plan

> The better solution here is to watch out that the used algorithms are > decidable Compilers will typically use decidable algorithms, otherwise, they could not run stable. > Yes and I know, but I still don't care. This sounds that I've just pulled out a (cheap) textbook argument but this is

The Cylons have a Plan

> Maybe, but keep in mind how terrible I'm at type theory. No comment... I'm focusing on Nim only. For "generics", a core type theory is necessary anyway, because otherwise it is not sound. > ou say "undecidable!", I say "don't care, I'll simply add a counter and bail > out if it takes too long

The Cylons have a Plan

The "static thing" could be addressed/achieved in the type section with first order unification, if concepts had such a type section (they should...). The "each T" would then be represented by export statements, in fact an each T would no be exported. These concepts would come close to SML/OCAML

The Cylons have a Plan

No, Kobi meant that the declarative style should be depracated, because "it doesn't work". But the declarative part has to stay. It is for other reasons. The "static thing" is a red herring.

The Cylons have a Plan

> Well I suppose the major problem is coming up with a syntax for it. :-) Concepts are in the language for - at least - 6 years. And now, a keyword is missing? I don't believe it.

Preview of coming attractions?

The original calculus goes back to Michel Parigot in 1992. It was intended to be used with Natural Deduction, ND extended with quantification over predicates, therefore 2nd order. You can translate the calculus into CPS, if you want the lambda calculus back. If you don't need that, you should by

The Cylons have a Plan

Let's make a deal. You wrote > you'll tell me why you could not infer a static value (if decidable in > prinicple, of course...) and now the other part: > I don't know what that means. Same for your remark about 2nd order logic and > CPS. Please link to the relevant books/papers. How many pape

Preview of coming attractions?

What do you want? Do you want it "Soft" or "Aggressive"? Soft means - there is not much to see there. The compiler can derive more than now, and e.g. macros can be passed as arguments. Aggressive: Labels can be passed as arguments. A new keyword `fm` , "functional macro", will "macroize" a func

The Cylons have a Plan

What? Some late 70ies Cyborgs want to enter a a fight with me? This will not end well for them.

The Cylons have a Plan

Do the Cylons have a Plan to decide / to reason about the scope of a type? So, that type dependencies are made explicit? If not, the Cylons might have a plan, but would ride a dead horse at the same time.

Preview of coming attractions?

> Concepts are stuck in the design phase as I have no idea of how to infer > static values. We can solve this > We should map methods to C++'s virtual function tables. We should implement > for our "take on OO". > Unfortunately, #380 is harder to i

Preview of coming attractions?

@bpr > I'm a bit fond of being able to make structs callable. Perhaps C++ has warped > my mind, but it allows for cheap and easy closures and I was hoping it could > evolve into such a thing for Nim. Making structs callable is crucial, it should be the cause or the "seed" **for anything else**

Preview of coming attractions?

Is there an elephant in the room? There is no simple answer to that. If we had a simple answer, we would not see the abundance of diverging RFCs, we would not see smth that I call the "master caution lamp effect" \- people tend to leave "suddenly and unexpected" the community, but the explanati

Contexts, scopes and intrinsic types

> don't understand the question true... > already can the concept demand a ==/hash operation to exist. This was not the question. What I did with the example above: I linked a type with `Self` that is not directly attached to `Self`. Do you spot it now ? type ExU = concept

Contexts, scopes and intrinsic types

> We already have the necessary parametrization in Nim's generics, we're > getting generic constraints via concept, O.k. How do we obtain concept wide intrinsic type parameters then or did I miss a detail?

Contexts, scopes and intrinsic types

This post is related to issues addressed in and it attempts to solve them. I'll quote some statements from there (copyrights not mentioned) A remarkable observation: > Instead of attaching syms to types, I think we should attach scopes (the > decla

How to make Nim more popular

> By providing excellent integration and re-using existing platforms (compiling > to some platform is not the same as having a good integration with it). It's > hard to formulate preceicely how "good integration" should looks like. As an > example Java integration in Scala is terrible, and in Ko

How to make Nim more popular

...In continuation of the post above and answering about : > break ... implicit copy forever > > The latter I'm thinking is a reference to the work being done on CPS. Can you > elaborate how that breaks the let/var distinction? I'm not super familiar > with the CPS transform, but I don't immedi

How to make Nim more popular

I'm hoping I can convince you to expand on what you mean by > Heterogeneous Environments The first question can be answered perhaps best with a video : and then the question is , how to represent it in a type system. (modelling existential types sp

How to make Nim more popular

How to promote Nim? Well, where does Nim shine? * (1) Write a compiler in Nim - for Nim. This is not a pun, because * (2) Every compiler can be written in Nim, it is by far the most convenient language for that particular task. So, with advantage, a compiler for Swift could be written i

Nonlinear module behaviour in Nim

> The "pragmatic workaround" would probably be "Don't export the fields, > then.", which works until there is a fourth module which actually needs > access to them... This will simply not happen because types being abstract remain abstract, they can't be opened with the underlying type or field

New concepts, visibility and mount points

> I should point out my use of concepts is not typical for system software or > other mainstream software development in Nim. I'm trying to model structures > from abstract algebra as I did in a limited way in Rust: > Nice work, I appreciate it. Very

Order of concept implementations and functions is significant?

Well it compiles after some rearrangements #module eqc.nim import eq_impl type Eq* = concept x, y eq(x, y) is bool ne(x, y) is bool func is_symmetric*(x, y: Eq): bool = eq(x, y) == eq(y, x) #module eq_impl.nim func eq*(x,

New concepts, visibility and mount points

stu002 is working hard on concepts now - IMHO he tries to squeeze smth out of them that they don't represent. Actually, I regard concepts more or less as cargo-cult : They try to imitate typeclasses or interfaces or whatever in that direction. They are implemented as constraints and therefore to

Order of concept implementations and functions is significant?

This should compile: ype Eq* = concept x, y eq(x, y) is bool ne(x, y) is bool func eq*(x, y: int): bool func is_symmetric*(x, y: Eq): bool = eq(x, y) == eq(y, x) func eq*(x, y: int): bool = x == y func ne*(x, y: int): bool = x != y

Nonlinear module behaviour in Nim

> Is that the separation you wanted? You just tried to achieve separation with inclusion, look at your imports. But additional boilerplate code does not address the problem: > # should probably have been `v.b = v.a + 5` in the original code You got the point and missed it at the same time. I i

How to return an object of a particular type following a value.

Well, it boils down to: type V2*[T: SomeInteger] = object of RootObj a*, b*: T V3*[T: SomeInteger] = ref object of V2[T] c*: T proc my_return[T](dim: int): V3[T] = return V3[T](a: 0, b: 1, c: 3) echo "done" echo my_ret

How to return an object of a particular type following a value.

The ct failure at play.nim indicates that the compiler expects a uniform return type. You want to return V2 or V3, but V2 or V3 are not uniform enough, even if they are in a subtype relationship : `V3 = ref object of V2`

Compiler error: "... is T too nested for type matching"

Where? Couldn't locate it at :

Nonlinear module behaviour in Nim

I have a couple of modules : mdlimpl, mdlabst and mdlprog. mdlimpl implements (you guess it) some basic functionality. mdlabst (abstraction) imports mdlimpl and operates on a type `TOb` given by mdlimpl, but the type gets not revealed in mdlabst. To achieve this, functions defined by mdlimpl onl

Compiler error: "... is T too nested for type matching"

Yes, a limit is there, I can canfirm that there is a maximum with 7 derivations. > Can I change this limit somehow, even at the cost of longer compilation times? Probably not (you had to modify the compiler), but in the end, only Araq will know.

NimConf 2021: Saturday, June 26th 2021

> What do you mean by “implement monads”? We have sequtils.flatMap and > options.flatMap, what are they missing? It is not a question that you can _implement_ an evaluation of specific monads in Nim ( or C or whatelse). But monads (categorically generalized) belong to functors, themselves being

NimConf 2021: Saturday, June 26th 2021

> Nim is Nim (best in class for concise imperative programming). You are just repeating my argument: > Nim shines if a project has limited, well defined scope from the very > beginning So, again, this is not the question. But there are other things: > imperative spill-offs, e.g. GADTs, module

NimConf 2021: Saturday, June 26th 2021

Nim shines if a project has limited, well defined scope from the very beginning. > There should be one and only one programming language for everything. That > language is Nim. Well, let us implement monads with Nim ... ehm no. Functional Programming is not in the realms of Nim. Even imperative

Trying to understand compilation error "Error: no tuple type for constructor"

Well, it boils down to : type XConcept* = concept x check(x) is int proc check[T](x : T) : int = 1 proc reif*(u : XConcept): bool = true # This is okay. assert reif(2.2) # This is not. assert reif((2.2, 3.3)) R

Nim 2.0 -- thoughts

> What? Sorry, but what? I meant that caring about correctness is not > pre-mature, in other words: it's never too early to care about correctness. Of course, correctness is never debatable itself. I translated @freeform 's "premature" as "when to resolve". Otherwise, his post would not make se

Associating a type with a concept?

> the change i made was removing the non-generic overloads and adding > doEp(12,13) i removed the specializations from your original version as the > generic was never getting called. I didn't remove them. Anyway, how to express in the concept, that T is distinct from the types for x and y ?

Nim 2.0 -- thoughts

This still gives headaches to me: > If everything reachable is also visible then changing the set of imported > modules is always a breaking change for any "downstream" modules since they > can all name things from those modules without actually importing them. It > also greatly increases the r

Nim 2.0 -- thoughts

> And I don't believe in "premature correctness". ;-) Interesting statement. Translation: "Resolve as late as possible". This indeed has consequences for both language and compiler design. E.g. for incremental compilation. The compiler collects packed AST parts . At the very end, they get check

Associating a type with a concept?

> results in a type mismatch, as does ?? You made a minimal change - you imported strformat - it compiles anyway.

Associating a type with a concept?

Generic (pattern matching) use of a type parameter within `concept x,type U` The mentioned concept `NumTest` would compile as : type NumTest[T] = concept x,y, type U is_eq(x, float , T) is bool is_ne(x, y, T) is bool Run so the type of x is float and t

Associating a type with a concept?

> After feedback it looks like the most idiomatic way to do this in Nim is with > the generic concept parameter. You asked for a type "that is not known to the concept". But with the generic concept parameter, the type becomes part of the concept because it belongs to its instantiation type, e.

Associating a type with a concept?

> I'm coming at this as a relative newbie to Nim so it seemed like there was > some capability of the way concept elements are checked for truth that I was > missing. After feedback it looks like the most idiomatic way to do this in > Nim is with the generic concept parameter. Your question was

Associating a type with a concept?

> this won't compile if is_eq/is_ne are generic over Epsilon It compiles anyway: type NumTest[T] = concept x, y is_eq(x, y, T) is bool is_ne(x, y, T) is bool proc is_ne[T](x, y, epsilon: T): bool = echo "generic ne T ", T.type x != y p

Associating a type with a concept?

You want the existential type ( = type exists ). The concept should find out an underlying type that is part of the concept, the type being abstract (not revealed to the outside) but being used within the functions. I tried several things to achieve such a behaviour but it is not possible. Conc

Nim 2.0 -- thoughts

Your list is way too long, it mentions an important item though, but misses another very important item. Let's see. * Multi-threading: This has been ALWAYS a pain point for Nim * Concurrency: This is being addressed, finalize it properly Pragmatic approach: What do Rust and C++ offer for t

C++ (new) modules vs. Nim modules

I refer to the C++ example given above. Because of the hidden module type (hidden outside the module), functions can't be applied to the module from the outside. They can only be injected and need to be converted (instantiated ) by the module itself. An instantiated function then makes a change

C++ (new) modules vs. Nim modules

Without the export and module annotations, g++ will compile the following example. We have a module type (module structure) MS, and a module instantiation MI. None of these gets revealed to the outside. The module can be compiled separatedly, no dependencies with an importing program. :private t

C++ (new) modules vs. Nim modules

I just stumbled upon I think that it is well explained and highly intuitive. (Perhaps I am biased though...) C++ modules allow for module descriptions , the description itself is a module. The descriptive module is initiated by writing:

Nim 2.0 -- thoughts

> I mean yes, that's kinda what you get if you don't do weird > sub-partitioning and separate compilation Separate compilation is a form of abstraction (at least), because when the app gets linked against the library/dll, types are gone and an ABI only remains. Your example defines (implic

Nim 2.0 -- thoughts

> Well then templates/macros should also be eschewed, their behavioral opacity > is arguably even worse. Hehe, good point. I would differ a bit between templates and macros. Macros are opaque, if AST builds/rebuilds are involved. There is no clear connection with Nim syntax or semantics. Macros

Nim 2.0 -- thoughts

> in a long-running application, the error code paths are equally important to > the "normal" code paths "long-running application" == "a system that simply has to work and nothing else". Within such a system, the program runs/cycles through different states over and over again, the set of thes

Nim 2.0 -- thoughts

> Bjarne Stroustrup said that "Within C++, there is a much smaller and cleaner > language struggling to get out". He hiddenly mentioned Nim! ... Or not, who knows. I do regard Nim as "C on steroids" : Nim squeezes anything out of function overloading and macro-expandable annotations aka "generi

Proposed table changes - get and getOrDefault

> Rust can do it because it can expose interior pointers Rust can especially do it because of `FnOnce()` , a function with state. `or_insert_with` gets the value to be inserted as `FnOnce()` and therefore the computation can be delayed. This is the (CBN-related) alternative that I mentioned abo

Proposed table changes - get and getOrDefault

> table.getOrDefault(1, createAString("ONE!")) will ALWAYS invoke > createAString, even if not needed. It would be useful to have this only > execute when necessary. You want call-by-name. Alternatively, you could wrap it into a closure. But then, the callee has to know that it has to call the

Proposed table changes - get and getOrDefault

@Prestige > table.getOrDefault(1, createAString("ONE!")) will ALWAYS invoke > createAString, even if not needed. It would be useful to have this only > execute when necessary. You want call-by-name. Alternatively, you could wrap it into a closure. But then, the callee has to know that it has t

Nim as a classic programming language

> `{.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

sequtils insert sink problem

> please post complete, minimized examples otherwise it's impossible to tell if > there's an actual bug or not I didn't claim a bug. The `sequtils` was hidden behind another import layer, so it's okay that the compiler didn't know about it. However, the compiler knew about it, because it report

sequtils insert sink problem

> You have to import a module to use it. Interesting. I included another file that imported sequtils. So I thought that it already was available. Your are right, if I import sequtils (again), it works. Thank you.

sequtils insert sink problem

I tried to compile: (example drawn from the sequtils documentation) proc run() = var dest = @[1, 1, 1, 1, 1, 1, 1, 1] let src = @[2, 2, 2, 2, 2, 2] let outcome = @[1, 1, 1, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1] dest.insert(src, 3) assert dest == outcome

Nim as a classic programming language

>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

How to make Nim more popular

> Nim structures code as modules tied to types. By module I mean set of related > functions. This would be very very nice, but... A module is a set of positive datatypes (tuples, objects, arrays, tables, and not to forget sets themselves) and negative datatypes (functions). They _could_ be bou

Nim 2.0 -- thoughts

> (quote @Demos) I also want to see an implementation of c++ OOP What does "C++ OOP" stand for? > I agree, not because I think this is inherently good, but, as I've said > before, there's over a billion lines of C++ and the path to Nim from there > should be made as easy as possible. Virtual F

  1   2   >