Roadmap to Falcon 2.0
29 views
Skip to first unread message
Giancarlo Niccolai
Dec 23, 2017, 2:25:58 PM12/23/17
to FalconPL
So, basically, what was causing me to hesitate and reconsider the whole project was just a set of small little things at the base of the engine, like the INTEGER/NUMERIC type duality, or some naming conventions, which deeply bothered me. Some decision were taken in the effort of making other things work and some other were simply a relic of the past, when they used to have a precise and valid (at the time) reason to be set up a certain way. Some where simply due to the need of having some things completed a working for existing project based on this software to progress.
After analyzing the codebase we have now for more than a month, I am convinced that we need to restart from the ground up, writing the basics from scratch and building the rest of the code around it.
This doesn't mean throwing everything away. The vast majority of the code, about 95%, isn't directly involved with the most intimate part of the engine. Even functions directly talking with the virtual machine are mostly logic (and good logic), and the interface points are few and well controlled. Module functions are mostly detached from the inner workings of Falcon, and even radical changes, as i.e. rewriting the ITEM API, would involve a quite limited set of (and in most cases a code refactoring might do the trick).
However, this will also provide the occasion to move the engine into C++17 and to uniform both the SDK and the language with the latest standards in terms of algorithm representation (i.e. find_if and lower_bound), without dropping any of the interesting features that were being included in the upcoming 1.0 version.
The operating steps are the following:
This will be done through "incremental moves". We will start a new repository on github, where we'll work at the new components and we'll move in the code from the pre-existing falcon projects.
Other than an operating roadmap, I am also planning action to attract developers to help out in the process.
But first of all, I will publish a simple documentation on github about the features we had ready in 1.0 -- which are still accessible in the new_engine branch: basically, it will be an expanded version of the cheatsheet we were preparing (the document was never officially published: it was just a note we had circulating around developers and interested people i.e. in the mailing list).
After analyzing the codebase we have now for more than a month, I am convinced that we need to restart from the ground up, writing the basics from scratch and building the rest of the code around it.
This doesn't mean throwing everything away. The vast majority of the code, about 95%, isn't directly involved with the most intimate part of the engine. Even functions directly talking with the virtual machine are mostly logic (and good logic), and the interface points are few and well controlled. Module functions are mostly detached from the inner workings of Falcon, and even radical changes, as i.e. rewriting the ITEM API, would involve a quite limited set of (and in most cases a code refactoring might do the trick).
However, this will also provide the occasion to move the engine into C++17 and to uniform both the SDK and the language with the latest standards in terms of algorithm representation (i.e. find_if and lower_bound), without dropping any of the interesting features that were being included in the upcoming 1.0 version.
The operating steps are the following:
- Redesigning the ITEM structure
- Redesigning the Handler interface (what was called Class)
- Redesigning the PStep and CodeStep structures -- so that they can better represent both polymorphic code and code coming from written sources.
- Review the garbage collector (actually, it was one of the things I liked the most, especially when compared against the ones of other generic untyped languages in our same class)
- Redesigning the VM context (or, the operational virtual machine stacks), with particular attention to the process of value resolution.
- Refactoring the VM to serve the changed entities
- Writing tools to manipulate the VM directly (memory dumper, assembler, debugger).
- Adapting (refactoring) the falcon source compiler
- Porting all the modules to the new architecture.
This will be done through "incremental moves". We will start a new repository on github, where we'll work at the new components and we'll move in the code from the pre-existing falcon projects.
Other than an operating roadmap, I am also planning action to attract developers to help out in the process.
But first of all, I will publish a simple documentation on github about the features we had ready in 1.0 -- which are still accessible in the new_engine branch: basically, it will be an expanded version of the cheatsheet we were preparing (the document was never officially published: it was just a note we had circulating around developers and interested people i.e. in the mailing list).
Klaim - Joël Lamotte
Dec 23, 2017, 2:36:46 PM12/23/17
to falc...@googlegroups.com
Good to see that there is a future for this project,
although a rewrite (whatever the shape) is always risky because require even more focused effort (from experience).
I'll watch the project until it reaches a point I can use it and I have a need for it.
Meanwhile, good luck!
--
You received this message because you are subscribed to the Google Groups "FalconPL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to falconpl+unsubscribe@googlegroups.com.
To post to this group, send email to falc...@googlegroups.com.
Visit this group at https://groups.google.com/group/falconpl.
For more options, visit https://groups.google.com/d/optout.
Renato Lenzi
Dec 23, 2017, 3:35:21 PM12/23/17
to falc...@googlegroups.com
Very good, Giancarlo... very good.
yves.c...@gmail.com
Dec 23, 2017, 10:28:30 PM12/23/17
to FalconPL
Yes this is great. I had shied away from investing in learning Falcon since it didn't seem to be active. But I kept coming back to the page once in a while to see if there was any updates or "stay tuned!"s.
This is great
This is great
To unsubscribe from this group and stop receiving emails from it, send an email to falconpl+u...@googlegroups.com.
To post to this group, send email to falc...@googlegroups.com.
Visit this group at https://groups.google.com/group/falconpl.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "FalconPL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to falconpl+u...@googlegroups.com.
Stanislas M.
Dec 24, 2017, 2:02:43 AM12/24/17
to FalconPL
It is a great time to start anew. I will do my best to contribute like we used to.
--Nikopol--
Giancarlo Niccolai
Dec 24, 2017, 7:32:14 AM12/24/17
to FalconPL
I do agree indeed that rewriting from scratch is both an immense effort and dangerous, and that more or less what happened in 1.0: there, I changed the underlying engine so radically that nothing around could stay. And yet, actually the codebase we have in the new engine branch is basically usable and nearly complete. It lacks just packaging and the porting of some modules.
At any rate, it is not a full rewrite what I am aiming for, at all.
First of all, this time around the base concepts are going to stay. I consider the organic virtual machine, or maybe we should call it virtual OS, as it also provide memory, process and file system abstractions, as a model worth being explored and expanded. That, as the real core of the system, is not going to change except for the necessary refactoring. Same goes for the compiler, the module structure, the garbage collector (I have some details i’d like to tackle on that, but nothing major) and vast part of the library, as the strings, arrays and dictionaries, iterators, some advanced statements as for/last etc, and surely modules as curl, and applications as the web server. All this doesn’t need any rewrite, most of them might be fine with minimal refactoring at worst.
It’s the process of moving on what I am focusing on now: start from a fresh repo bringing in code incrementally as the previous steps are complete and solid. Most of the time we’ll be copying the old code as the base to work on, rewrite the parts in need and refactor the others, compile and run the tests, in an incremental process of building from ground up in a test oriented development fashion.
Some things will be scrapped away, as the genexpr expression system, as all that stuff will be handled by the new Number class, but some other, as the ITEM class, will be mostly copied as they are, worked on without fear of breaking anything, compiled and tested anew.
See my next post...
At any rate, it is not a full rewrite what I am aiming for, at all.
First of all, this time around the base concepts are going to stay. I consider the organic virtual machine, or maybe we should call it virtual OS, as it also provide memory, process and file system abstractions, as a model worth being explored and expanded. That, as the real core of the system, is not going to change except for the necessary refactoring. Same goes for the compiler, the module structure, the garbage collector (I have some details i’d like to tackle on that, but nothing major) and vast part of the library, as the strings, arrays and dictionaries, iterators, some advanced statements as for/last etc, and surely modules as curl, and applications as the web server. All this doesn’t need any rewrite, most of them might be fine with minimal refactoring at worst.
It’s the process of moving on what I am focusing on now: start from a fresh repo bringing in code incrementally as the previous steps are complete and solid. Most of the time we’ll be copying the old code as the base to work on, rewrite the parts in need and refactor the others, compile and run the tests, in an incremental process of building from ground up in a test oriented development fashion.
Some things will be scrapped away, as the genexpr expression system, as all that stuff will be handled by the new Number class, but some other, as the ITEM class, will be mostly copied as they are, worked on without fear of breaking anything, compiled and tested anew.
See my next post...
Giancarlo Niccolai
Dec 24, 2017, 7:35:19 AM12/24/17
to FalconPL
Thanks, Nikopol! I am coting on you and on all the help we can get on this one :)
Reply all
Reply to author
Forward
0 new messages