I hope you don't disappear. And I hope I can show you something in code asap that makes you interested.
And maybe you will understand why for me compile time check is mostly irrelevant.
I shouldn't disappear normally, but never know these days
Oki for code example
Rather I would say compile-time checks are important especially for small details, but we can't possibly type every semantic due to unbounded semantics.
Because every programmer will consider Turing law as some kind of holy bible, but in truth it's really useful in the paradigm of program to make scientific computation.
Turing model is for program who start with initial parameters, do their loop, and finish with the computed result.
Once you throw irq ( usb event, key/mouse input, network events, hard drive event ) , or threads, it's not a Turing machine anymore. States can change outside of the influence of the program
Well to me ultimately, i still stay in the idea that the only things cpu knows about are registers and memory address.
I still spent some time once uppon a time close to cracking scene, and i'm quite familiar with intel assembler, for me if you don't have security understanding at C level, you ain't got any security at all.
And most high level language will still use C compiler or interpreter, and still run on a CPU who only know about registers and memory address.
And no VM is perfectly safe, as far as i know, most exploit on JAVA comes more from exploiting bugs in the VM rather than the program itself. Or even from the layers underlying the VM, kernel, or libs etc
It's the problem with RUST and why it doesn't really bring that much more security from C to program operating system or kernel, or low level things as they say.
And why to me high level language are only false security, and in the context of event based programming based on plugins/components, the compiler can't check much.
C++ compiler can't really check much memory leak, neither JAVA sdk/VM know how to prevent dead locks or screw ups, not even talking about exploit via VM or underlying layers down to the kernel.
It just give the impression it does by giving a sort of semantic to express it in programming language, but at the end it still can't really check much that the program will really function as the semantic imply.
This is
unbounded nondeterminism.
Most of the program flow is not function calling each others in a precompiled order, but integrating component on top of an event processing layer, and the functions will be called by programs outside of the compiler scope.
It's even more relevant in the context of distributed application, and application server.
Most of the high level function will not be called by the node itself. The parameters with which they will be called will not be determined by the code of the node itself, and that's the only thing the compiler can see.
It look like oracle based Turing machines, but it's not even a problem of deterministic algorithm, because the code is determined by the hardware interupts, or other threads, rather than the algorithm itself.
Even if the algorithm is perfectly predictible in itself, if it's called from an interrupt or use shared state in multi task environment, the execution flow is still not predictible from the code.
That is only fundamentally incompatible with compile-time (i.e. static) typing in the sense of an exponential explosion of types in type signatures.
It doesn't matter the language used, it cannot determine most of the relevant code path at compile time, or check the client side of the interface. It doesn't even really make sense to try to figure that out at compile time.
Yes for me the trade off between explosion of data types and signature, and the benefit it bring in term of high level programming in this context is not in favor of compile time type checking
I don't think anyone was proposing dependent typing.
Any way @iadix, I must say that I better expend some time on developing my stuff and not talking about all this theory. I was already talking about all this theory for months with @keean. I don't want to repeat it all again now.
Let me go try to do some coding right now today. And let's see how soon I could show something in code you could respond to.
We can then trade ideas on specific coding improvements, instead of this abstract discussion.
I understand what you want, and I essentially want same. We just have perhaps a different idea about the exact form and priorities but let's see how close we are to agreement once I have something concrete in code to discuss.
Yes, i think anyway i got my most thinking across, or the part relevant for the moment and i can get your from the discussion on the github or on this forum
Most of the code defined will not be called from inside of the component, but by other programs/applications, and you know nothing about them, how they might represent data or objects internally, or how they might do function call passing those object and data. The compiler can't have a clue about anything of it. Neither about the high level code path, or global application logic.
It doesn't have to, and shouldn't. The application do not follow the Turing model anyway, and the high level function of C/C++ compiler are at best gadget, at worst it can force to complexify the code or add level of abstraction where it doesn't really matter, because it still can't check what is relevant in the application execution flow. It can just check the code flow of the abstraction layer, which is mostly glue code and doesn't matter that much in the big picture.
I think you may not be fully versed on typeclasses. The are not OOP classes. @keean and I had long discussions about how these apply to genericity and callbacks.
Please allow me some time to try to show something. This talk about abstracts or your framework, will just slow me down.
Please two or three sentence replies only. We really need to be more concise right now.I have read those discussion, i need a good deeper look into it, to me it seem similar in certain aspect to the purpose of my system of dynamic object tree, but not exactly in the same context
But i'm pretty sure this system of typeclass could be used as input to create those object tree in the script language.
Would not be too hard to implement the low level aspect of memory/instance/reference and concurrent access on the instances with the framework, large part of the low level function being already made to have a runtime to manipulate data and objects created out of this definitiion.
But it's not exactly done with same purpose in mind or coming from same place or to solve the same things exactly =)
