I had never heard of it before!, it seems too good to be true, do you know of any project using it? or do you have yourself a project that uses it? (you’re the creator, right?)
@blake1024 , first of all, hat off for your great research and implementation of Dynace language. Even if it never would be extensively used, its ideas and technical solutions are already a brilliant contribution to programming languages theory.
I have two questions:
I see you have inspired by SmallTalk and CLOS (Common Lisp Object System). However, in the documentation I found Dynace have interface with C, Java and Scheme. Does Dynace have an explicitl interface with Common Lisp?
I understand Dynace acts as a preprocessor for standard C language. Does it mean its dynamic capabilities are limited to compile time? Are the compiled programs also dynamic capable? I mean, is it possible to program something like continuation passing style (when the next called function is passed as argument to currently executing function) in Dynace where the continuation is passed during runtime (not compile time)?
this sounds like a very bad idea. AI are “fuzzy”. They will produce code that looks similar to the input, but is occasionally slightly different and introduces hard to understand bugs. And transpiling is done more easily and more efficiently by other means (either a complex “search and replace”, or using a compiler framework like llvm, that can parse the code and then regenerate it in a different language, in a reliable and predictable way)
I don’t know about llvm, but many compilers compile to intermediate languages, C or Assembler etc, then compile from that output to machine code. Usually something like this, as an example only. Python ->C->Assembler>machine natuve code. Many compilers just compile Python → machine code.
There’s a entire academic literature on the subject if you’re dying to sleep and need to dry out your eyeballs, it’s as exciting as paint drying.
I believe Dynace can also be compiled with C++ (although it hasn’t been done in a while). If you run into trouble just let me know and I’ll take care of it.
Yes - in general. However, in the case you’re likely looking at it is referring to a directory within the repo not in the system. So, ../lib would always be correct.
I have another repo called WDS. It is an entire GUI development environment that is significantly used. It is all written in Dynace. Unfortunately, WDS is only meant to run on Windows. That uses the sort of PREFIX path you are talking about.
Dynace is like Smalltalk in its class hierarchy and metaclasses. Dynace is like CLOS in its use of generic functions. It’s like both in its use of metaobjects (classes and instances are just objects and treated the same. Instances hold values. Classes describe instances. Metaclasses describe classes.)
The Dynace interfaces with Java and Scheme are largely deprecated due to changes in those languages. There is an existing interface to ABCL (Common Lisp for the JVM) that runs fine. There is no need for a C interface because Dynace is C. C and Dynace code can link and use each other with no special processes or libraries. Building interfaces between Dynace and other languages would be no harder than building a C interface between those other languages.
The pre-processor only acts like syntactic sugar. All of the work is done at runtime. In fact, the first version of Dynace had no preprocessor. It just used a bunch of macros. The pre-processor merely inserts the macros and generates code that could be done manually. It is quite convenient in a larger system.
@Munchausen Most of the runtime work is done in kernel.c with the help of the other core classes (Object, Class, Behavior, MetaClass, etc.). The rest of the system - threads, class library, and dpp - are just plain Dynace code.
(Sorry about the name “Dynace”. When I first wrote the system I had a lot of better names but they were all taken…)
@damoklas Dynace was developed in response to what I perceived as many shortcomings of C++. The Dynace manual contains a large section that clearly describes the problems it solves. Dynace has far more dynamic OO capabilities than C++, as well as many other important features (see the manual), but also (on purpose) doesn’t have all of the additional syntax that C++ adds. I think converting C++ to Dynace (without C++) would be nearly impossible because of all of the additional syntax C++ adds to C.
I am not sure why anyone would want to use Dynace with C++ but that can easily be done. In other words, Dynace can easily be added to an existing C or C++ codebase.
In most cases, I’m not familiar here with the subject, on 64bit you get /system/bin and /system/lib, so there it would be correct, on 32bit if it doesn’t build with gcc2 (which I suspect it wont), binaries end up in /system/bin/x86 and libraries in /system/lib/x86, so there it would make a difference?
@Begasus I think if you look a little deeper into the code, you’ll see why it is always correct where you’re seeing that for all OSs, architectures, etc. because it is just a reference within the repo.