The other part is that Nim's strongly typed and compiles to native code but allows you to do dependent typing like things that lets you be flexible on types:
type
X = object
Y = object
Z = object
NotXY = not (X | Y)
proc doSomething(_: NotXY) = echo "hi!"
type MyObject[T] = object
val: int
other: TEdit: oh X, Y, Z are singletons I guess? Still don't see the flexibility or dependent types?
To quote from Wikipedia:
dependent types are used to encode logic's quantifiers like "for all" and "there exists". ... dependent types help reduce bugs by enabling the programmer to assign types that further restrain the set of possible implementations
type
State = enum Open, Closed
SomeObject[T: State] = object
val: int
SomeObjectOpen = not SomeObject[state.Close]
proc close(obj: SomeObjectOpen) = ...
Ya I don't think this is a good definition of dependent type - the prototypical example of a dependent type is a k-length vector. Obviously there's a mapping from what you wrote to this (in the same way there's almost always a mapping from a sequence of decision problems to an optimization problem) but it's still not a good formulation.
> In my example the objects could be any object types, combination of types, or concepts
Um yes this is literally what I was asking with respect to top ⊤.
> usually can't [contain] expressions
ya the negation is interesting - I wonder how it's implemented.
Yah that's why I qualified my statement as dependent type like setup as I don't know a good definition of dependent types which I really grok and I've only briefly dabbled in it. It'd be awesome if you could point out a good resource showing a clear example / simple proof.
Well I started working on statically typed vector concepts [1]. The compiler can't do `proc concat[N,M: static int](v1: Vector[N], v2: Vector[M}): Vector[N+M]` and it fails. It might be able to be implemented via a macro like `proc concat(v1: Vector[N], v2: Vector[M}): typeFromSumOf(N,M)`, but I haven't tried yet.
Also just using static ints would require specific values at some point to work I think. Whereas you'd really want "induction" of some sort. Maybe a SAT solver would be required at that point? There's DrNim [2] which does tie Z3 but it's sorta dormant.
> Um yes this is literally what I was asking with respect to top ⊤.
Ah, I didn't know what you meant by top T.
> ya the negation is interesting - I wonder how it's implemented.
Nim's VM runs from Nim AST, so probably running it as a VM expression.
1: https://github.com/elcritch/platonic 2: https://nim-lang.org/docs/drnim.html
What does this mean? There's a runtime VM or compile time VM?
Compile time VM. It's used to run macros / templates / concepts. You can also run most code at compile time in a `static` block except for stuff that needs C calls. You can also compile the VM into a program and use it as a runtime VM (see https://github.com/beef331/nimscripter) which I do in my GUI lib. NIR should enable the compile time VM to run faster too, and possibly use JIT'ed code.
(Nim compiles to C, so in fact it compiles to exactly that).
Any plans to develop this into something beyond a hobby project? I think a Qt rival in a language safer and more pleasant than C++ would be welcomed by more than a few people.
At least I personally would like to use it to ship commercial cross-platform apps w/o needing electron or something huge like QT. Nim is much more pleasant than C++! You can actually embed the Nim compiler (~8MB) and run Nim as scripts too, so in theory you could remotely update your app as a nimscript.
P.S. drop me a line (emails on my github profile) if you're interested
In defence of Qt, there's a lot of functionality in there, and they've made it modular.
To my knowledge Qt's library binaries have roughly the same file sizes as, say, their Gtk equivalents. I wouldn't expect a new competitor to be that different.
What do you use for controls, native OS objects or something custom drawn? If the latter, you're in for a word of pain with screen reader compatibility, internationalization, right-to-left languages, handling of Asian input methods etc.
> If the latter, you're in for a word of pain with screen reader compatibility, internationalization, right-to-left languages, handling of Asian input methods etc.
Custom drawn, and yep it's a pain! Actually emoji's seem the hardest (e.g. smiley face + skin tone).
The windowing library I'm building upon uses the OS'es input method editors (IME). For example MacOS'es functions for composing letters like `é` already works. Hopefully Asian input methods will work via the OS'es IME. Luckily I know a bit of (modern) Hebrew, so I'll can add basic RTL languages soon.
Pixie can render svg and ttf fonts with unicode in addition to drawing the shapes used for boxes and lines (e.g. like pango+cairo). It's SIMD optimized, very fast, and pure Nim so cross platform.
The challenge I mentioned with emojis is text selection and cursor movement when dealing with multi-grapheme characters. :)
edit: see https://youtu.be/8acDfUIwLnk?si=1EAUwUNZqje88J86&t=382 where they discuss how hard Text is
Like the sibling I'd be very much interested in this! Have you considered open-sourcing the GUI library part?
https://github.com/saem/vscode-nim#nim-lanugage-server-integ...
That is the fist time I hear this. Other than Python, I always felt Nim is more like Pascal and Ada.
We should be getting back what Xerox PARC was already doing in systems programming with Mesa/Cedar, Interlisp-D and Smalltalk in terms of systems programming.
This is where I see a value in languages like D and Nim, Swift, or even Go, regardless of the opinion on much systems it can be used for.
Back in my day writig compilers, linkers and OS services was considered systems programming.
(There is a hint on something like that wrt. Mesa/Cedar on wikipedia. FWIW -- I've obviously never used it myself)
A small taste,
"Eric Bier demonstrates Cedar"
https://www.computerhistory.org/collections/catalog/10278104...
Full graphics workstation in 1980's, implementated in a systems programming language using reference counting, with a tracing GC as cycle collector, with an object model partially implemented years later as OLE/COM.
Swift is the closest to it, and it is still not widely adopted across Apple ecosystem, although as per CppCon 2023's Apple talk they even have plans to push it into the kernel (long term).
I'm sure there are quite a few systems worked on by lone developers today that make for a nice and smooth demo. The hard part is getting adoption and making it ergonomic and performant for a variety of uses, not just demo stuff.
Nim's home page acknowledges borrowing from Python, Ada, and Modula, as well as C/C++. I don't think D is part of the mix.
While Nim indeed comes from Wirthian heritage instead of K&R heritage, its goals are pretty similar to D. You could say that Nim is for (Object)Pascal what D is for C(++). I think that's what the GP alluded to - not that Nim borrows directly from D or the other way around.