Introducing HarbourNova — a new direction built on Harbour’s foundations
Eric Lendvai
I would like to introduce HarbourNova (HN), a project I have been developing to carry the strengths of Harbour and xBase into a modern, database-oriented language, runtime and toolchain.
Harbour’s contributors have given us an extraordinary foundation. My interest is in building on that work: keeping the readability and productivity that make this family of languages valuable, while reconsidering architectural constraints that need not define its future.
HN is not intended to be a drop-in Harbour upgrade. It deliberately allows changes to language semantics, datatypes and APIs. Its focus is modern database applications, services, APIs and business processing, with PostgreSQL as the primary database target—not preservation of DBF/CDX compatibility.
Here are several areas that distinguish the project. Some already have working, tested implementations; others are approved designs still being developed.
Unicode-native text and source code
HN separates Unicode Text from Raw binary data. Text carries its encoding, with ASCII, UTF-8, UTF-16 and UTF-32 in the model, rather than requiring applications to treat every string as an ambiguous sequence of bytes.
The source-language direction includes UTF-8 source files and Unicode identifiers—not merely international characters inside quoted strings. The text model distinguishes storage bytes, Unicode code points and user-perceived characters, or grapheme clusters. That distinction matters for accented characters and multi-code-point emoji.
Unicode text operations already have tested implementations. Broader Unicode identifier coverage remains work in progress.
Named parameters
Named arguments are implemented for cataloged core APIs and statically known user functions and methods. Positional calls remain available.
This makes calls with several options easier to understand and maintain: the source says which parameter is being supplied, instead of making the reader count argument positions. The compiler also checks binding errors. Required arguments, defaults, reference parameters and declared type contracts are part of the same callable model—not separate conventions that each library must invent.
A substantially richer datatype system
HN’s type model extends beyond the traditional small set of xBase values. It includes distinct Text and Raw values, UUIDs, structured JSON, bit strings, richer date/time types including timezone-aware values, and an expanded numeric architecture. The collection roadmap also includes rectangular multidimensional Tensors, with matrices as the two-dimensional case.
The approved numeric design distinguishes exact integers and decimals from approximate floating-point arithmetic. It includes arbitrary-precision integer and decimal families, exact fractions, and explicit precision and conversion rules.
The aim is not simply more type names. It is to make the meaning of a value consistent across variables, parameters, cursor fields and database persistence. These types are at different implementation stages; the expanded numeric design is not yet a completed arithmetic subsystem.
Shared cursors with independent workareas
HN’s shared-cursor design separates the Cursor that owns records from the WorkArea that holds navigation and view state. Multiple workareas can refer to the same underlying cursor without sharing one current-record position.
For example, two routines can navigate the same in-memory dataset independently, without copying the records or continually saving and restoring each other’s record pointer. Closing one workarea does not destroy data still retained by another.
Shared-storage and workarea foundations already exist, while the complete native data engine remains under development.
Stronger language structure without mandatory typing everywhere
HN retains optional typing while adding explicit contracts where they are useful. The implemented compiler-native class model supports typed properties, method signatures and constructors, with one class declaration and method implementations distributed across source files.
Further approved work includes typed collections whose restrictions survive access through other references, block-scoped locals, genuinely immutable const contents, and recursively protected ReadOnly parameters.
Those last two have deliberately different purposes: const protects stable contents, while ReadOnly lets a function inspect supplied data without gaining permission to modify it. These newer guarantees remain design work, not claims about completed runtime behavior.
Error handling and development tools
Compiler-native TRY/CATCH/FINALLY/THROW and structured runtime errors are already implemented, including captured failure context and controlled propagation.
The development environment is also receiving substantial attention. HN has working compiler/build foundations for dependency-aware incremental compilation and embedded resources, alongside an HN-specific VS Code extension with a validated debugging baseline.
The current build/editor work is consolidating these pieces into a supported hnmake workflow and a consistent command-line/editor experience. The broader project-management interface and package tooling remain on the roadmap.
Where the project stands
This is an introduction to an active development project, not a production-release announcement. There is already substantial compiler and runtime implementation behind it. A full Windows/MSVC core test run has passed 170 suites containing 2,662 tests. That is evidence for those implemented components, not proof that every feature described above is complete.
The accepted end-to-end baseline is currently Windows/MSVC. Broader platform validation and important runtime and tooling work remain.
Migration tooling is part of the project, but compatibility is not being promised by simply recompiling existing Harbour applications unchanged. Nor am I suggesting that anyone abandon a working Harbour system.
I would welcome constructive questions and feedback from developers interested in this direction—particularly about the language features, database workflows and migration concerns that would matter most in a real application.
My goal is to preserve what makes Harbour productive while giving those ideas room to evolve.
Eric Lendvai
marcos...@gmail.com
I am very interested in HarbourNova. I would like to know more about these 10 points:
1. What will HN's OOP model be like, and what concrete improvements will it have over Harbour? Will it keep `CLASS/METHOD/DATA` and add interfaces, traits, generics, reflection, namespaces, or visibility?
2. Will there be an official unit testing framework, integrated with `hnmake` and VS Code, with assertions, fixtures, mocks, and coverage? How will PostgreSQL databases be tested?
3. What execution, memory, and concurrency model will it have: VM/JIT/AOT, GC/ARC, async/await, threads, actors?
4. What modern tools will there be: package manager, REPL, LSP, formatter, linter, and dependency management?
5. How will an existing Harbour application be migrated, and what will happen with DBF/CDX? Only PostgreSQL, or other engines as well?
6. Will there be interoperability with C/FFI, WebAssembly, REST/GraphQL, and existing Harbour libraries?
7. Will Linux and macOS be supported? Will Windows/MSVC remain the only validated platform?
8. What is implemented and tested today versus what is only approved design? What are the next milestones?
9. What backward compatibility is promised and what is not?
10. Where are the repository, specification, and documentation? How can one contribute, and how is the project governed?
Thank you for your work and best regards.
Marcos Jarrin
Eric Lendvai
1. What will HN’s OOP model be like, and what improves over Harbour?
HN retains the familiar CLASS/ENDCLASS and METHOD vocabulary, but uses PROPERTY instead of DATA/VAR for property declarations. Its implemented compiler-native foundation includes single inheritance, public/protected/private visibility, static members, typed properties and method contracts, abstract classes/methods, and checked overrides.
A class has one authoritative structural declaration, while its implementation can be distributed across multiple independently compiled source files. HN program files use .hnp rather than .prg; include files use .hnh rather than .ch. A file can implement one method or several methods belonging to a class.
The approved design also allows short method bodies—and ordinary methods used as event handlers—to be written directly inside CLASS/ENDCLASS, using ENDMETHOD to close an in-class method body. Longer implementations can remain in separate files. This is a choice of source organization, not a requirement to put every method inside the class declaration.
Object construction will automatically execute the declared constructor. The approved ClassName(arguments) form binds to the constructor without requiring a separate caller-written :New() call. Ordinary object creation must not accidentally skip initialization simply because the programmer omitted an explicit constructor invocation. This automatic form is approved design; the accepted implementation baseline still uses explicit Class():New(...).
The event model includes lifecycle notifications and custom application events, with RAISE functionality for publishing notifications to subscribed handlers. Events are distinct from ordinary method calls, and optional notification handlers do not replace mandatory construction or cleanup. Detailed lifecycle ordering and event syntax are still being finalized.
Compiler ownership also creates opportunities for better runtime performance: more efficient known-target method calls, property access and reduced repeated runtime lookup. These are optimization opportunities to measure, not a claim that HN already outperforms Harbour by a particular percentage. Placing a method body inside a class declaration does not itself guarantee machine-code inlining.
Interfaces, traits/mixins, general class/method generics, full reflection and the complete namespace/import model still require further design and implementation. Typed collections and compiler metadata should not be mistaken for completed general generics or reflection.
2. Will there be an official testing framework, and how will databases be tested?
HNTest already provides the project’s core smoke and contract-testing foundation, including assertions, checked-in fixtures, expected-output tests and compiler rejection tests. The supported hnmake pipeline can execute test targets, and consolidation of the internal testing workflows is underway.
The intended direction is integrated testing through hnmake and VSCode. However, a complete application-testing framework with standardized fixture lifecycles, mocks, source-level coverage and Test Explorer integration is not yet delivered.
DataWharf is also being updated for HN and will be the basis for schema definition and management. Its schema definitions and generated migration artifacts can therefore become part of the tests: creating the expected database structure, applying schema changes and checking that the resulting database matches the intended model.
For PostgreSQL, the testing direction is to use disposable, non-production databases with controlled schema versions and seed data. Tests should cover migrations, constraints, transactions, concurrent access, error handling and round trips between HN values and database fields. Mock-based unit tests remain useful, but they do not replace testing the actual PostgreSQL adapter and schema behavior.
3. What execution, memory and concurrency model will HN use?
The current build pipeline produces C output that is compiled and linked into native executables with runtime/VM support. It is an ahead-of-time native build process, but that does not mean all VM machinery has disappeared. No JIT is being announced.
The longer-term architecture gives HN its own value, storage-slot and execution-frame contracts, together with a verified, versioned module format. That work is staged rather than being treated as one complete VM replacement already delivered.
The current runtime retains inherited garbage-collection machinery while HN-owned value and lifetime rules are developed. I am not claiming that a completely new collector or a pure ARC system has already replaced it. Resource cleanup—closing a file, releasing a database resource or ending an owned task—is a separate contract from eventual memory reclamation.
The approved concurrency direction includes structured task scopes, bounded message queues, cooperative cancellation, immutable ordinary task inputs/results, and explicit protected sharing. Sharing a cursor or object must have defined ownership and synchronization rules; it must not silently turn arbitrary mutable state into thread-safe state.
Generators are designed to execute on demand in the consuming task. They can therefore be useful in single-threaded applications without creating worker threads.
The full scheduler and multithreaded runtime still need implementation and validation. Final async/await syntax and an actor-specific API are not being presented as completed features, and a task should not be assumed to correspond one-to-one with an operating-system thread.
4. What modern development tools will there be?
The immediate tooling focus is hnmake and the HN-specific VSCode extension. A working debugger and LSP-based editing baseline already exist. Deeper compiler-backed completion, navigation, diagnostics and project management are part of the continuing roadmap.
Build and dependency management are designed around a canonical project/workspace model and explicit dependency graphs. Initial package support is bounded to exact local or vendored source packages and an offline lock. A public registry and general version-range dependency solver are later capabilities, not finished facilities today.
The design also adds compiler-owned diagnostic constructs: Debug() for conditional debugger pauses, Trace() for conditional reporting of values, and TraceDump() for structured state snapshots. They support conditions and per-call-site limits. Trace values are not evaluated when the condition is false or the reporting limit has been reached; excluded instrumentation can be removed at compilation.
Built-in cross-platform tracing is also planned, providing DebugView-like collection and viewing on Linux as well as Windows, with VSCode integration and configurable log destinations. This is HN-owned tooling, not a claim that Microsoft’s DebugView runs on Linux. The existing Windows debug-stream API is a narrower implemented component; the complete portable tracing system remains to be delivered.
A supported standalone REPL, a fully HN-aware formatter and a dedicated semantic linter are not yet completed tools. Existing formatting machinery and compiler diagnostics should not be advertised as the finished versions of those products.
5. How will existing applications migrate, and what happens to DBF/CDX?
Migration is a dedicated workstream. hnconvert already has tested conversion and project-planning foundations. The approach is to automate transformations that are well defined and identify cases requiring developer review, rather than silently guessing at changed semantics.
An application migration should begin with regression tests, operate on a separate copy, and validate language, API and data-access changes against real behavior. Renaming .prg files to .hnp is only one small part of that process.
DBF/CDX support will be provided through optional contrib packages, primarily for importing existing data into SQL backends. That is different from making the inherited RDD stack the foundation of HN or promising unchanged execution of a DBF-centered application. The main direction remains SQL-oriented applications and HN’s native Cursor/WorkArea model.
PostgreSQL is the primary database target, not an architectural prohibition on other engines. Additional databases can be supported through adapters; MySQL/MariaDB, SQLite and ODBC are among the candidate areas. Their availability and capabilities will need to be documented individually.
The HN version of DataWharf is the basis for schema management: defining the target model, managing its evolution and producing the corresponding database artifacts.
HN also drops codepages from its native text model. Text uses explicit Unicode encodings, while collations define sorting and comparison behavior. These are separate concerns. Legacy codepage conversion will be available through a contrib import tool, allowing older data to be converted into Unicode rather than carrying global codepage state into HN applications.
6. What interoperability will be available?
Mixed HN and hand-written C is already supported within the accepted native build scope. The broader foreign-function interface is being designed around explicit value conversion, ownership, error handling and supported calling boundaries.
CPython integration already has an implementation; it is not merely a future idea. However, support and testing do not cover the entire Python package ecosystem. Completing its HN-native packaging, value-conversion and lifecycle contracts is separate from the existence of that bridge, and individual packages still need appropriate validation.
An updated embedding interface is also planned so that other languages can call HN code without manipulating internal VM stacks. The intention is a common native interface with language-specific bindings, not a different runtime contract for every host language.
Some contrib packages will also support Rust integration or use Rust implementations behind defined native interfaces. That does not make Rust a requirement for writing ordinary HN applications.
REST services fit the planned HarbourNova Web Framework and HTTP/FastCGI ecosystem. A complete official GraphQL stack is not being announced. WebAssembly remains a longer-term integration target, not a validated deployment platform today.
Existing Harbour libraries must be evaluated individually. Some source can be migrated and some native libraries wrapped, but compatibility with every Harbour contrib package or already-compiled library is not promised.
7. Will Linux and macOS be supported? What about 32-bit and ARM?
HN drops 32-bit support and focuses on 64-bit systems.
The initial release is planned to support MSVC and MinGW on Windows, and GCC on Linux, initially on x86-64. ARM support is intended to follow afterward.
Windows x64/MSVC is the currently accepted end-to-end validation baseline. There is already bounded Linux compiler and runtime evidence, but it is not equivalent to complete release acceptance. The first-release toolchain plan is therefore broader than what has already passed every validation gate today.
macOS remains a separate platform-support and validation task. I am not presenting it as already accepted or giving it a confirmed release date. Windows/MSVC is the current baseline, not the intended permanent limit of the project.
8. What is implemented and tested today, and what are the next milestones?
Implemented and tested foundations include named calls and callable contracts; compiler-native classes with independently compiled methods; Unicode text operations and Text/Raw separation; structured exception handling; semantic incremental builds; embedded resources; the initial supported hnmake execution pipeline; and the VS Code debugging baseline. Cursor/shared-storage and value-type foundations also exist, but their complete planned feature sets are not finished.
One recorded full Windows/MSVC core acceptance gate passed 170 suites containing 2,662 tests, with zero failures. Focused compiler, class, build, resource and editor checks have their own evidence. That is a concrete accepted checkpoint, not a claim that every advertised design has been implemented or that every target platform has passed the same suite.
Approved but unfinished work includes automatic construction and the newer class/event conveniences, the broader numeric and collection architecture, recursive const and ReadOnly guarantees, fuller cursor/concurrency behavior, the newer debugging/tracing system, and the replacement module/embedding architecture. Python integration exists, but its broader package coverage and HN-native completion remain separate work.
The immediate engineering milestone is to finish the build-tool migration and provide a consistent CLI/VSCode build-run-debug workflow. Subsequent tooling milestones cover workspace and native-library integration, compiler-backed language/project tooling, local packages and portable installation. Broader platform acceptance and application-level ecosystem testing must accompany release preparation.
9. What backward compatibility is promised, and what is not?
HN is not a drop-in Harbour compatibility distribution. I am not promising unchanged source compatibility, inherited p-code compatibility, preservation of every old API or identical behavior for every library.
Source-level API compatibility and compiled-library binary compatibility are different questions. A C API describes the callable interface and its behavior; binary compatibility also depends on calling conventions, data layout, symbols and runtime expectations. HN’s redesign means existing native libraries cannot be assumed to work without review and, where necessary, adaptation and rebuilding.
The migration commitment is to make differences explicit through specifications, diagnostics, conversion guidance and tests. Familiar xBase concepts are retained where useful, but HN’s own contracts take precedence where semantics change.
DBF/CDX import support is a migration facility, not a promise to preserve an entire legacy application’s storage and execution behavior. There is no suggestion that developers must abandon stable Harbour applications that continue to meet their needs.
10. Where will the project live, how can people contribute, and how is it governed?
Several related repositories will be hosted under github.com/harbournova/.
The compiler/runtime repository will also contain the HN VSCode extension: compiler and extension releases are version-dependent and will be developed, tested and released as compatible combinations rather than unrelated products.
The same GitHub organization will include the HarbourNova Web Framework and the HN version of DataWharf. Public repository access and contribution arrangements will be announced as the projects are prepared for wider participation.
I lead the design, specifications, architectural reviews and acceptance decisions directly. Almost all implementation work is AI-produced under that direction. The initiative is design-, documentation- and test-driven: documentation is part of defining and delivering a feature, not something added afterward.
The most useful contributions at this stage are additional independent testing and careful review of the design and documentation, especially with concrete application examples, migration cases and platform-specific findings.
HN-provided public API functions use the hn_ prefix. The planned HarbourNova Hub Admin tool will manage API definitions and datatype specifications and support generation of reference documentation and the JSON metadata consumed by the compiler and other tools. Versioned, committed outputs will remain the release authority, keeping the compiler, editor and documentation aligned without requiring a live administration database to build applications. Language keywords and compiler intrinsics such as Debug() are not ordinary API functions.
HarbourNova will be released under the GNU GPLv3 license, with applicable third-party licensing and attribution preserved.
My current estimate is that an initial release may be possible in approximately four to six months. This is a readiness-dependent estimate, not a fixed delivery commitment.
I have already created Google Groups for HN, ready for active discussions when the project reaches that stage. With sufficient developer interest, I would also arrange meetings to demonstrate working components and discuss the design.
The official website will be harbournova.org. Other project domain names redirect to the .org address.
Thank you again for the detailed questions. Independent review and real-world testing will be particularly valuable as HarbourNova moves toward its first release.
Eric Lendvai
Francesco Perillo
Eric Lendvai
Because the productive ideas behind Harbour and xBase still have value, and there is room to develop them without making backward compatibility the primary architectural constraint.
HarbourNova’s focus is database-oriented business applications, web services, reporting and background processing. The aim is to retain the readability and directness of this language family while bringing together Unicode-native text, richer datatypes, stronger optional contracts, better class organization, shared cursors and modern development tools.
The purpose is broader than adding features. It is to develop a coherent environment in which the compiler, runtime, database schema tools, editor, debugger, API definitions, documentation and tests are designed together. A datatype should have a clearly defined meaning in a variable, a function parameter, a cursor field and its database mapping. An API’s documentation and the compiler’s understanding of its parameters should come from the same definition.
Why a separate project rather than simply extending Harbour?
Because some of these changes deliberately alter existing behavior. Preserving working applications is a legitimate and important objective; so is exploring a different architecture. A separate project allows that exploration without asking existing Harbour users to accept disruptive changes to the platform they depend on.
Backward compatibility is not a flaw. It is a commitment to existing users, and it inevitably shapes which changes are practical. HN takes a different position: retain useful concepts, but allow language, runtime and API changes where they contribute to a more consistent system.
That does not diminish Harbour’s contribution. Quite the opposite: HN builds on a foundation that Harbour’s contributors made possible. It represents another direction for this language family, not a demand that Harbour stop serving its existing users.
Why not simply use another language?
Other languages can certainly build these applications. The question is whether the productive qualities of xBase can be retained while giving them a modern, integrated foundation for data-oriented development.
HN does not need to be the best language for every task—or replace Python, Go, Rust or C#—to be useful. Interoperability is part of the direction precisely because a language should be able to work with other ecosystems rather than attempt to reproduce everything itself.
The development approach also matters: specifications, documentation, implementation and tests are treated as parts of the same deliverable. The objective is not merely to accumulate capabilities, but to define how they behave and verify that they work together.
Ultimately, HN will have to justify itself through working applications, reliability and developer productivity. A feature list is not sufficient, and nobody should migrate simply because a new project sounds promising. Existing Harbour applications that continue to meet their requirements remain entirely valid.
The reason for HN is not novelty for its own sake. It is to preserve what makes this family of languages valuable while creating room for a different next chapter.
hherrera
Eric Lendvai
HN is not tied to one presentation model.
It will support normal console/terminal applications, so text output remains available where that is appropriate. HN itself is Unicode-oriented, so console applications are not limited to traditional ASCII/codepage assumptions.
For business applications, a major focus is HTML-based user interfaces, particularly through the planned HarbourNova Web Framework. HN will also have an official FastCGI contrib, making it suitable for high-performance server-side web applications behind standard web servers.
There will also be WebView support, allowing an HN desktop application to use modern HTML/CSS/JavaScript for its user interface while still behaving like a locally installed application. This provides a practical bridge between native desktop applications and web-based UI development without forcing everything to run as a remote web application.
HN is also designed so that more traditional native graphical interfaces can be supported, but a particular cross-platform desktop GUI toolkit is not being built into the core language.
A later release is planned to go further with a visual form builder, including visual inheritance. The intention is that developers will be able to design forms visually, derive new forms from existing ones, and inherit and refine their UI structure and behavior rather than repeatedly rebuilding similar screens.
The development environment itself is graphical as well: the HN VS Code extension provides project, language and debugging integration, while DataWharf provides visual database/schema management.
So the short answer is: Unicode console applications, HTML/web applications through FastCGI and the HarbourNova Web Framework, desktop applications using WebView, and later a visual form-building environment with inheritance.
hherrera
Thank you for taking the time to address my concern.
Francesco Perillo
Eric Lendvai
Hi Francesco,
Thank you for the thoughtful message. I actually share part of your concern about fragmentation.
The Harbour community is relatively small, and creating another language inevitably risks dividing attention. That is something I have considered carefully. On the other hand, I think trying to make these changes directly inside Harbour would create a different and potentially worse division, because many of the changes intentionally break with existing behavior.
Harbour has an important role as a highly compatible continuation of the Clipper/xBase tradition. Existing applications depend on that compatibility. I don't think it would be appropriate to ask Harbour to abandon it.
HN therefore takes a different approach: preserve the parts of the xBase/Harbour programming model that remain productive, but allow the language, compiler, runtime, datatype system and tooling to evolve without requiring compatibility with every historical decision.
So I don't see HN as "the new Harbour" or something Harbour developers should be expected to move to. They are different projects with different goals. If HN eventually proves useful enough that some Harbour developers want to use it, great. If an existing Harbour application is working well, there may be no reason to move it at all.
At the same time, I don't want HN to be designed only for existing Harbour developers.
A significant part of the design review is looking at capabilities that have proven useful in languages such as Python, Go, Java, C#, Rust and others, and considering how those ideas can fit naturally into an xBase-style language rather than simply copying their syntax.
This is particularly true in areas such as classes, typing, collections, error handling, concurrency and multithreading. For example, HN's class model is being reviewed against capabilities that developers from mainstream object-oriented languages would expect, while the concurrency design takes ideas from newer structured-concurrency and message-passing models.
The objective is to keep the directness that makes xBase productive for business and database applications, but make HN less unfamiliar to somebody coming from Python, C#, Java, Go or Rust.
I hope that eventually this works in both directions: Harbour/xBase developers should feel at home, while developers from other ecosystems should see concepts they recognize rather than viewing HN as an isolated historical language family.
Regarding implementation, yes, there is considerably more than a feature list now. Some features are still approved designs, but others are already implemented and tested.
The two items you mentioned are good examples.
Named parameters are implemented at compiler level. They are not implemented by passing a dictionary of names and values at runtime. For a statically known function or method, the compiler knows its signature, including parameter names, required/default parameters, reference parameters and type contracts.
For example, arguments can be supplied positionally and then by name, and named arguments can appear in a different order. The compiler binds them to the correct formal parameters while still evaluating the expressions exactly once and in their original left-to-right source order. The callee receives the canonical parameter layout and also enforces the declared contract.
This works not only for HN APIs but for user-defined functions across separate .hnp source files, and the same callable/signature infrastructure is used for methods.
Classes are also compiler-owned rather than primarily preprocessor constructs. A class has one authoritative structural declaration containing its properties, method signatures, visibility, inheritance information, etc. Method implementations can then be in that declaration for short methods, or independently implemented in one or several other .hnp files.
The compiler and build system understand those relationships. A change to the implementation of one method need not cause everything using the class to be rebuilt, while a change to the class layout or public contract invalidates the appropriate dependent code.
That compiler knowledge also gives us opportunities later to optimize statically known method calls and property access more aggressively than would be possible if the compiler knew very little about the class. I am being careful not to claim performance improvements before they are benchmarked, but the architecture is deliberately being designed to make such optimization possible.
Another major change is the API model.
HN is not simply retaining every historical Harbour API name and adding more names beside them. The intent is that, where practical, one semantic action has one canonical HN API.
Over time Harbour accumulated APIs with overlapping purposes or slightly different semantics—for example things such as AINS() and HB_AINS(). Experienced Harbour programmers learn those distinctions, but they increase the amount of historical knowledge needed to write code.
They also make automated code generation more difficult. An AI coding agent may know that several functions appear to perform approximately the same task without reliably understanding which historical variant should be used in a particular situation.
HN APIs are therefore being reviewed and redesigned rather than mechanically renamed. Public HN functions use a consistent hn_ namespace, and their signatures, parameter names, types and documentation come from machine-readable definitions shared by the compiler and development tools.
My hope is that this will benefit both humans and future coding agents: fewer overlapping choices, clearer contracts, better diagnostics and less historical ambiguity.
That is particularly important because I think xBase still has an advantage that is sometimes underestimated: it grew up around data and databases. HN is trying to retain that strength while incorporating ideas that have developed elsewhere over the last several decades.
Ultimately I would like a developer—or an AI development agent—to find it especially straightforward to build a database-oriented business application in HN.
There is already a substantial automated test suite around the compiler/runtime work. One accepted Windows/MSVC checkpoint was 170 suites / 2,662 tests with zero failures, and there are additional focused compiler/build/class tests that are not simply added to that number.
You are also correct about the repositories.
The public repositories visible at the moment are not representative of the current HN development tree. Active development is presently being done privately while some fairly fundamental architecture, repository organization and tooling work is still changing.
The intention is not to keep HN closed. HN will be released under GPLv3, and the public projects will be under:
https://github.com/harbournova/
There will eventually be several related repositories/projects there, including the compiler/runtime and its matching VS Code extension, the HarbourNova Web Framework, DataWharf, and other components.
I want the compiler and VS Code extension versions to remain coordinated because the editor understands compiler metadata, APIs, signatures, classes, named parameters, debugging information, etc. I don't want the IDE support to become an unrelated project that gradually drifts away from the language.
Interoperability and migration are also important parts of the longer-term plan.
There will be a Harbour-to-HN converter, and I also intend to develop Visual FoxPro-to-HN and Python-to-HN conversion tooling.
I don't expect those converters to magically translate 100% of every application. That would be an unrealistic promise, especially for large applications or code that depends on runtime behavior specific to the original language.
The intended model is closer to:
convert everything that can be converted with confidence, and produce a detailed exception/report for everything requiring developer attention.
That report should identify unsupported constructs, ambiguous conversions and behavioral differences rather than silently generating questionable code.
Python is particularly interesting because I would eventually like conversion and interoperability to work in both directions.
If useful portions of Python packages can be converted to HN, and the resulting HN functionality can also be called back from Python through a clean embedding interface, that could make it easier for developers outside the xBase community to experiment with HN without having to move an entire application to it.
I don't expect arbitrary Python packages to be converted automatically—Python's dynamic nature makes that unrealistic—but a useful subset, combined with generated wrappers and clear exception reports, could still cover a significant amount of practical code.
More generally, HN is being designed so that other languages can call HN without knowing about its internal VM stack, using a defined foreign-language interface. C is the natural base interface, with bindings for languages such as Python and potentially Rust, C#, JavaScript and others.
Another longer-term objective is PostgreSQL integration. PostgreSQL is already the primary database target for HN's datatype and cursor design, and I intend to investigate HN as a supported PostgreSQL procedural/backend language as the HN module/runtime model matures.
Being able to execute appropriate HN routines close to the database would fit naturally with the project's database-oriented focus, although that is clearly a later feature rather than something I would claim exists today.
The project is also being developed somewhat differently from a traditional compiler project. I make the architecture and language decisions and review the results, while almost all implementation is AI-assisted. Because of that, I have put a lot of emphasis on specifications, automated testing and recorded acceptance evidence. Documentation is being developed together with the features rather than being postponed until the end.
When the repositories become public, I actually think some of the most valuable contributions will initially be review and testing, not necessarily writing large amounts of code. Experienced Harbour/xBase developers finding semantic problems, migration cases, missing business-language capabilities or flaws in the documentation would be extremely useful.
And thanks for the FoxScript link. I took a look at it after your message. It is definitely relevant and interesting, particularly the way the project documents its compiler/runtime architecture and keeps the editor connected to the same compiler used by the runtime.
Its objective is quite different from HN—FoxScript is deliberately pursuing very high Visual FoxPro compatibility, whereas HN deliberately allows semantic changes—but there are certainly implementation ideas and lessons worth studying.
I don't expect everyone in the Harbour community to agree with the HN direction. At this point I mainly want to make the design and the working implementation visible enough that people can evaluate it on technical merits.
If there is enough interest when the public repositories are ready, I would also be happy to organize an online meeting and demonstrate some of the parts that are already working, including the compiler, named parameters, classes, build system and VS Code debugger.
Thanks again for taking the time to look at it.
Eric
marcos...@gmail.com
First of all, I want to sincerely thank you for the time and detail with which you answered my previous ten questions. It has helped me understand not only what HarbourNova (HN) is, but also what it is not, and why you have made such deliberate decisions regarding compatibility, semantics, and architecture.
I have also carefully read your later contributions to the thread, especially your replies to Francesco Perillo, to hherrera, and your explanation of the "why" behind the project. I agree with you that Harbour has an irreplaceable role as a highly compatible continuation of Clipper/xBase, and that forcing certain changes inside Harbour would have created a worse division.
1. Microservices, API, and front end
Will HN have a native microservices model, or will it rely on the HarbourNova Web Framework + FastCGI? How will it communicate with modern front ends (React, Vue, Angular, Blazor) — REST, GraphQL, WebSockets, SSE? Will there be automatic generation of OpenAPI contracts or similar from the API definitions in hn_?
2. Virtualization, containers, and elastic deployment
I understand that HN compiles to native code and does not depend on a heavy VM. How does it integrate with Docker and Kubernetes? Will there be official images, Helm charts, or example manifests? Will it be able to run in serverless environments (AWS Lambda, Azure Functions) or in managed containers (ECS, AKS, Cloud Run)? What role do OS-level virtualization, hypervisors, or microVMs play in the deployment strategy?
3. ERP/HIS on AWS or Azure
If I want to build an ERP or a HIS for a client on AWS or Azure, does HN give me the necessary pieces: connection to managed PostgreSQL (RDS, Aurora, Azure Database), queues, object storage, authentication, observability? Or do you foresee those pieces coming from the client's ecosystem while HN focuses on business logic and data access?
4. Multiple database connections and real time
Confirmed that HN uses Cursor/WorkArea and not RDD. Will it be possible to connect to multiple databases in the same project natively and transparently? How will information gathering and real-time data presentation be handled? Will there be support for WebSockets, Server-Sent Events, or integrated message queues?
5. End-to-end encryption and security
How will end-to-end encryption, secret management, and communications security be addressed? Will there be native APIs for TLS, signing, hashing, symmetric/asymmetric encryption, or will it be delegated to system libraries and contrib packages?
6. Artificial intelligence
Will HN have integration with AI services (OpenAI, Gemini, local models, etc.)? Is native support planned for code agents or assistants that generate HN code, given that you yourself mention that almost all implementation is AI-assisted? Will there be API metadata designed also so that agents better understand the language?
7. Real migration of large applications
I greatly appreciate your honesty in saying that the converters will not translate 100%. How will runtime behavioral differences be handled? Will there be a "controlled compatibility" mode or exception reports by file, function, and line? Will it be possible to migrate module by module within the same system?
8. Status, repositories, and contribution
I understand that the current public repositories do not represent the current tree and that the work is being done privately. Will there be a closed or public beta before the release? Will it be possible to contribute with tests, design review, and migration cases before the code becomes public? How will the project be governed when there are more contributors?
9. Development tools
Will VS Code support include debugging, autocompletion, refactoring, static analysis, Git integration, Test Explorer, coverage? Will there be support for other editors (JetBrains, Neovim, Emacs) via LSP? Will the REPL and formatter be in the first release or later?
10. License, sustainability, and enterprise support
GPLv3 seems fine to me for the core. Will there be a commercial license or enterprise support? How will the project be funded long term? Is an open core, donations, sponsorship, or services model being considered?
11. Testing, quality, and CI
You mention 170 suites / 2,662 tests with zero failures on Windows/MSVC. Will those results be published? Will there be public continuous integration? Are tests planned on Linux, macOS, ARM, and integration tests with real PostgreSQL?
12. Community and training
Will there be complete documentation, tutorials, examples, courses? How do you see the coexistence between the Harbour community and the HN community?
I know these are many questions again, but I believe they reflect the real concerns of those of us who have been working with Harbour for years and see in HN a serious opportunity to take a qualitative leap, without abandoning what already works. If you think it appropriate, I offer to help in whatever way I can.
Thank you again for your work and for the transparency with which you are sharing it.
Best regards,
Marcos Jarrin
Eric Lendvai
Hello Marcos,
Thank you again for taking the time to think through HN at this level. These are exactly the kinds of questions I hope experienced Harbour developers will ask, because they force a distinction between what belongs in the language/runtime, what belongs in official HN packages, and what should remain the responsibility of the surrounding deployment ecosystem.
I will try to answer each point separately and also distinguish current direction from features that are not implemented yet.
1. Microservices, APIs and front endsFor the first release I am not planning a special "microservices runtime." Microservices are primarily an application/deployment architecture, and HN does not need a new execution model simply to expose an HTTP API.
The initial server-side model will primarily use an official FastCGI contrib. For API-only applications there is no requirement to use the HarbourNova Web Framework; HNWF is more relevant when building complete web applications and their UI infrastructure.
I actually think persistent FastCGI processes are a very good fit for many business applications because the process can remain alive across requests and retain resources such as database connection pools instead of reconnecting for every request. That is particularly useful for the type of database-oriented software HN targets.
A React, Vue, Angular, Blazor or other front end would simply communicate with HN through normal web protocols. REST/JSON will be the obvious initial model. SSE is already part of the design direction for server-to-browser events and progress reporting. WebSockets can be added where bidirectional persistent communication actually requires them. GraphQL is possible, but I do not currently consider it a first-release priority.
One clarification concerning OpenAPI: the hn_ API catalog describes HN language/runtime APIs, not an application's HTTP endpoints, so I would not generate an application's OpenAPI document directly from those definitions.
I do, however, like the idea of explicit machine-readable service/route contracts. Once that part of HNWF/API development is defined, generating OpenAPI from those contracts would be a logical feature. It would follow the same general philosophy already used elsewhere in HN: define something once and derive compiler/editor/documentation artifacts from that definition rather than maintaining several independent descriptions.
HN can certainly be used to implement microservices, but optimizing specifically for very large microservice/serverless installations will probably come after the initial release.
2. Virtualization, containers and elastic deploymentContainers are one of the primary deployment targets. Docker/OCI containers are a natural fit for HN because the end result is a native application with its runtime and required libraries rather than an application requiring a large external managed-runtime installation.
HN still has runtime/VM machinery internally, so I would not describe it as having no VM at all, but deployment is based on native binaries rather than requiring something analogous to a Java or .NET runtime installation on the target machine.
The build/project design already distinguishes the target operating system from its execution environment. For example, Linux is the platform, while Docker, Podman, a Kubernetes pod or a bare server can be deployment environments.
I expect us eventually to provide example Docker images and container deployment configurations. Kubernetes examples also make sense. I am less certain that HN itself needs to maintain something such as an official Helm chart, because that becomes application-architecture specific very quickly. I would rather provide good examples and composable building blocks than pretend there is one correct Kubernetes deployment.
Serverless is interesting but probably later. For example, an AWS Lambda adapter could potentially invoke HN through the planned C/embedding interface. Similar adapters could be produced for other platforms.
The important point is that HN should not architect itself around AWS, Azure, Docker or Kubernetes. A hypervisor, container runtime or microVM is simply an environment in which the native application executes.
3. Building an ERP or HIS on AWS/AzureHN is not being designed specifically for AWS or Azure. I want the first architecture to be vendor independent.
An HN application should be able to connect through normal encrypted network connections to PostgreSQL whether that PostgreSQL instance is self-hosted, Amazon RDS/Aurora, Azure Database for PostgreSQL or another compatible service.
For things such as object storage, cloud queues, identity services and vendor-specific monitoring, I expect a combination of:
HN contrib packages;
standard HTTP/service APIs;
native libraries;
and Python interoperability where that is the practical solution.
Python interoperability is strategically useful here because enormous amounts of cloud integration already exist in Python. HN does not need to reproduce every AWS or Azure SDK before somebody can use those services.
If HN becomes widely used, native HN packages for the most important services would make sense.
For an ERP or HIS, HN should provide a strong language/runtime, database model, schema management, transactions, concurrency, web/API support, diagnostics and security building blocks. Cloud architecture and regulatory compliance remain larger application/deployment responsibilities. I would not claim, for example, that using HN by itself makes an application HIPAA compliant.
4. Multiple databases, local querying and real-time informationYes, multiple simultaneous database connections, including connections to different backend types, are part of the direction.
I would not call different SQL engines completely "transparent," because pretending PostgreSQL, SQL Server, Oracle, SQLite, DuckDB, etc. have identical semantics eventually causes problems. Backend-specific capabilities should remain visible when they matter.
What HN can provide is a common Cursor boundary.
HN's own Cursor storage is an in-memory typed record store capable of representing the HN datatype system. Query results from different backends can therefore be materialized into HN Cursors and subsequently processed consistently.
I also plan to support DuckDB as a receiving/query engine, and there is a larger planned HN local SQL engine inspired in part by the convenience VFP developers had when querying local cursors.
The goal is to be able to retrieve data from several sources, materialize working sets locally, and then perform joins, filtering, grouping, aggregation and additional queries without repeatedly going back to the remote servers.
The native local SQL engine will not initially attempt to duplicate every feature of PostgreSQL or other enterprise databases. Its purpose is high-performance local data processing integrated closely with HN Cursors.
An especially useful capability I want to investigate is allowing appropriate HN functions in the current scope to participate as functions callable by local SQL, providing some of the convenience of stored/user functions without requiring everything to live on the remote database server.
This is a substantial amount of work. I expect significant portions of it before HN 1.0, but probably after the first Alpha/Beta preview rather than before anyone can begin experimenting with HN.
For real-time presentation, SSE is already the preferred simple model for one-way browser progress and event updates. WebSockets can be supported for applications that genuinely require bidirectional persistent communication.
Background work is being designed separately from HTTP request handling: durable job state can live in PostgreSQL while workers perform the long operation and an SSE/event layer reports progress. Message brokers/queues can also be integrated, but I don't intend to make a specific broker mandatory for ordinary HN applications.
5. End-to-end encryption, secrets and securitySecurity is an area where I specifically do not want HN inventing its own cryptographic algorithms.
The accepted direction includes an official TLS/SSL package using established, reviewed cryptographic implementations. The current candidate design uses a Rust interoperability layer with OpenSSL initially. HTTP/client packages would consume that rather than each implementing their own TLS behavior.
Hashing, signing, certificate handling, symmetric and asymmetric encryption should similarly be exposed through HN-owned APIs backed by established cryptographic libraries, not newly invented HN cryptography.
Secret management is a somewhat different concern. HN applications should not encourage embedding secrets in source files or project manifests. Deployments should be able to obtain secrets from the environment appropriate to them: container secrets, mounted secret files, Kubernetes secret mechanisms, cloud secret stores, operating-system facilities, etc. Generic HN interfaces or contrib adapters can sit above those mechanisms.
TLS termination may occur in a reverse proxy/web server or inside an HN service depending on the deployment. If an application requires true application-level end-to-end encryption beyond transport TLS, that should also be possible through the crypto packages.
The exact public crypto/security API surface is not frozen yet, and this is an area where external security review will be important before calling it production-ready.
6. Artificial intelligenceYes, I expect AI integration to be important, but I don't think OpenAI, Gemini or another provider should become a dependency of the HN language itself.
An HN application should be able to call hosted AI APIs through HTTP just as applications written in other languages do. Local models can be reached through their HTTP/native interfaces, and the Python interoperability layer gives us another route into the existing AI/ML ecosystem.
Provider-specific HN contrib packages may eventually make these integrations more convenient.
There is also a second AI question that I consider particularly important: how well AI coding agents can understand HN itself.
A considerable part of HN's architecture already helps with this deliberately.
Public APIs have canonical names and machine-readable signatures. The compiler has a canonical datatype registry. Parameters, named arguments, nullability/type contracts, diagnostics and source locations are represented as structured information rather than existing only as prose documentation.
The VS Code/VSCodium tooling consumes those same authorities.
One reason I have been simplifying the API surface is exactly this problem. If one operation has several historical functions that are almost—but not quite—the same, a human has to remember those distinctions and an AI agent can choose the wrong one just as easily.
My preference is therefore one clear canonical API for one semantic operation whenever practical.
I hope this makes HN unusually approachable both for humans and future coding agents. AI support inside the IDE can then be built on real compiler/API metadata instead of asking a model to infer everything from source examples.
Given that nearly all HN implementation itself is currently AI-assisted, making the language friendly to AI development is not an abstract consideration.
7. Migration of real large applicationsI definitely do not want hnconvert to produce questionable output silently and report success.
The converter already has the concept of structured reports and source locations. The intended end state is that conversion problems can identify the original file and source span and, where available, the function/class/method context and the reason developer review is required.
So the model is approximately:
convert what can be converted deterministically;
identify changed semantics explicitly;
flag ambiguous or unsupported constructs;
provide file/line/context information;
produce a report of remaining manual work;
validate the converted application with tests.
The goal is not "100% automatic conversion." It is maximizing the portion that can be converted safely while making the remainder measurable and manageable.
I don't currently want a broad runtime "Harbour compatibility mode" that silently restores old semantics, because that would eventually reproduce the compatibility constraints HN is intentionally escaping.
There may be carefully bounded migration/compatibility facilities where useful, but semantic differences should remain visible.
Module-by-module migration is desirable, especially for large systems, but there is an important distinction: I am not promising that arbitrary Harbour and HN object modules can simply be mixed in the same executable.
Practical staged migration may use well-defined C/foreign interfaces, processes/services, database boundaries, or specific migration bridges. The converter and build tooling should help determine which boundaries are safe.
The same philosophy will apply to the planned VFP-to-HN and Python-to-HN converters.
Python conversion in particular will never convert every Python package automatically because Python permits extremely dynamic behavior. But if a useful majority of a package can be translated and the converter produces a good exception report for what remains, that can still be very valuable.
An additional goal is that converted HN functionality can then be exposed back to Python through the HN embedding interface. That could create a useful two-way migration/interoperability path rather than requiring an all-or-nothing language switch.
8. Status, Alpha/Beta, repositories and contributionMy current thinking is to have a small closed Alpha/Beta group before the general release, probably consisting initially of developers who are genuinely interested in testing the language and challenging the design.
One reason for keeping that group relatively small initially is that I do not want to declare language features permanently frozen too early. Until HN 1.0 there needs to be room to correct a bad decision when actual use shows a problem.
Alpha/Beta users should have direct input on features and priorities. I expect real application experience to affect the roadmap.
Initially, governance will continue to be led by me directly. If the community eventually becomes large enough that this is no longer practical, then the governance model can evolve.
I have some experience with that side as well. I was a lead board member of the San Diego FoxPro Developers User Group for more than twenty years and have participated in other nonprofit organizations.
For larger design changes I want to establish HNEPs — HarbourNova Enhancement Proposals, similar in purpose to Python's PEP process. That gives important changes a persistent specification, discussion history and decision rather than allowing language design to emerge only from message-board conversations.
I expect most core implementation to remain AI-assisted under controlled design/review/testing. Traditional contributors may be particularly useful for contrib packages.
But I see enormous value in contributions through:
independent testing;
design review;
documentation review;
migration cases;
additional platform validation;
examples;
translations/localization;
and community support.
I would especially welcome future help managing discussion groups and other community infrastructure. I have already reserved HN groups on Google and Facebook.
9. Development toolsVS Code and VSCodium are the target IDEs.
The existing extension already has a working debugging foundation including launch/attach, breakpoints, stepping, stack/locals, Watch/evaluation and language/API integration. The current build/editor work is making the compiler, hnmake, debugger and extension share one consistent project/build context.
The roadmap includes increasingly compiler-backed:
completion;
signature/named-parameter help;
navigation;
diagnostics;
API documentation;
project editing;
build/run/debug integration;
and static/semantic analysis.
The API documentation is already intended to be available directly inside the extension rather than requiring the developer to constantly leave the editor.
Refactoring support can grow once the compiler-backed semantic model is mature enough to perform changes safely.
Git itself is already handled well by VS Code/VSCodium, so I don't see a reason to create an HN-specific Git implementation.
Test Explorer and coverage integration are desirable, but I don't want to promise that every testing UI feature will make the first preview. The underlying HNTest/testing contracts come first.
A modern profiler is also now planned for late HN 1.0 development, with profiling compiled out when disabled and visualization through a VS Code/VSCodium WebView—for example statistics, call trees/flame graphs, timelines and source navigation.
A dedicated REPL and full HN formatter are lower priorities and may come after the first release if necessary.
I currently have no plans to develop dedicated JetBrains, Neovim or Emacs integrations. If the community eventually wants to build them, compiler protocols and machine-readable metadata should make that more practical, but I don't want to dilute the initial tooling effort across many editors.
10. License, sustainability and enterprise supportThe sustainability model I have in mind is closer to the community-oriented Python/PostgreSQL model than to a vendor-controlled commercial language.
HN is currently self-funded by me. The HarbourNova trademark application is pending.
The HN project itself is intended to use GPLv3, with the appropriate runtime/application exception so developers can build commercial and closed-source applications without their application automatically becoming GPL simply because it uses HN.
I do not currently plan a separate proprietary "commercial edition" of HN or an open-core model where important language features are kept behind a commercial license.
If HN becomes widely used, I would certainly be open to sponsorship, financial support and companies providing professional/enterprise services around it. That does not require the language to become dependent upon a particular vendor.
I would actually prefer an ecosystem where multiple companies and developers can provide support.
International participation is also important to me. One of the earliest HN language features I worked on was Unicode support at the source-code level, not merely Unicode strings. Function, class, method and variable identifiers can therefore be written using non-English characters.
That was intentional: I don't want HN to assume that software development happens only in English-speaking countries.
11. Testing, quality and CIYes. The tests and testing framework will be part of the repositories, not private acceptance artifacts that users are asked to trust.
The currently quoted Windows/MSVC acceptance checkpoint of 170 suites / 2,662 passing tests is one recorded baseline. As development continues there are also many focused compiler/build/application tests around individual features.
When the source becomes public, I expect CI results and the tests that produced them to be visible as well.
Windows/MSVC is currently the strongest validated platform, but Linux is a required supported platform, not just an experiment.
macOS and ARM will require additional hardware/platform expertise, and I will probably need community help there. I would rather state that openly than claim validation on machines/configurations that have not actually been tested.
Database testing will include real PostgreSQL integration, with controlled test schemas and test data—not merely mocks of database calls. DataWharf's schema definitions can participate in creating and validating those database fixtures.
Over time I want the release matrix to make it obvious which compiler/OS/database combinations actually passed the release gates.
12. Community, documentation and trainingDocumentation is being treated as part of development rather than something to write after the compiler is complete.
Almost every significant architectural decision has a design record, and public APIs are derived from structured catalog information. My intention is to publish that as an online, searchable/queryable documentation system, in the same general spirit as the new harbour.wiki.
The same API documentation will also be available from inside the VS Code/VSCodium extension.
I expect to add:
tutorials;
migration guides;
complete examples;
reference applications;
architecture explanations;
and probably YouTube videos/demonstrations.
Formal courses may come later depending on demand.
Regarding Harbour and HN communities, I hope they can coexist without hostility.
HN exists specifically so Harbour itself does not have to change its compatibility mission. There will certainly be ideas or implementations that can travel in either direction where licensing and architecture allow it.
HN-original code will be GPLv3, so if portions of that code are incorporated into another project, the applicable GPLv3 licensing requirements need to be respected. The runtime/application exception is intended to protect developers writing applications; it should not be assumed to relicense copied HN source code.
Out of respect for the Harbour group, I only intend to post occasional major HN announcements here rather than turn the Harbour list into the HN development forum.
I hope we can start moving detailed HN discussions soon to:
https://groups.google.com/g/harbournova-users
The official web site will be:
Finally, thank you very much for your offer to help. That is genuinely appreciated.
As we approach Alpha/Beta, developers who understand real Harbour/xBase business applications will be particularly valuable because they can identify problems that language/compiler tests alone will never find.
And yes, I think we should arrange a meeting soon. It would probably be much easier to demonstrate the pieces that are already working—compiler features, named parameters, classes, hnmake, VS Code/VSCodium debugging, etc.—than to keep describing all of them only through long messages.
Best regards,
Eric
Luigi Ferraris
first of all thank you for this project.
I read sources on the fly on repository and seems interesting.
I'm not a great C programmer and a very expert in different scenario.
But, I see again internal codepage and hb_gtxxx handling.
About classes it seems good.
So, I have a very very simple questions:
1) Why not use external 3rd cross-platform about characters / language?
e.g. ICU or GNU libiconv
2) Why not use external 3rd cross-platform video driver?
e.g. ncursesw (linux/MACos) and PDCurses(windows)
4) About classes
4.1) I remeber great problem with "template composition"
e.g.
CLASS Tsample
VAR object INIT myObject():new()
every Tsample object instance share the same myobject instance
4.2) I don't see isDerivedFrom("xxxx") only className() in your implementation
4.3) about inheritance: I think this code can be used
::inheritedClass:doSomething instead of ::super:doSomething
5) I believe that upgrading to (at least) C++11 could offer significant benefits and facilitate the future integration of code.
+-------------------------------------------------------+
| XBase code |
| ( es. cTesto := "Ciao", @ 10,10 SAY cTesto |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| C++ abstraction layer |
| - icu::UnicodeString |
| - video output |
+-------------------------------------------------------+
|
+--------------+--------------+
| |
v v
+-------------+ -----------+-----------
| ICU library | | |
+-------------+ v v
+-------------+ +-------------+
| ncursesw | | PDCurses |
|(linux/MACos)| + (windows) |
+-------------+ +-------------+
Eric Lendvai
Hi Luigi,
Thank you again for the questions and for taking the time to draw the architecture diagram. These are useful points, and your examples help make the architectural questions much more concrete.
Before answering, one clarification about the source code you mentioned.
The current HarbourNova development source has not yet been published publicly. Therefore, if you saw extensive hb_..., codepage and GT handling in a repository, I suspect you were looking at Harbour/Harbour Legacy source, or at older/public material based on the Harbour codebase, rather than the current HN development tree.
HN still uses portions of Harbour internally as transitional compiler/runtime infrastructure, but the presence of that code should not be interpreted as the intended HN public architecture. HN is progressively defining its own runtime types, APIs, compiler semantics and tooling.
- Why not use ICU or GNU libiconv for characters/languages?
In principle, I agree.
HN does not intend to reimplement the entire Unicode ecosystem internally. ICU is already part of the intended direction for advanced Unicode services such as language-aware collation, normalization and other locale-sensitive Unicode operations.
The important distinction is between HN language semantics and the implementation provider.
HN must first define exactly what Text, comparison, sorting, character length, code points, grapheme clusters, etc. mean. ICU can then implement appropriate portions of that contract.
HN's normal string model is deliberately different from Harbour's historical codepage model:
Text = Unicode text
Raw = arbitrary binary bytes
A normal HN Text value is Unicode. Codepages do not determine normal string semantics.
Legacy codepages are instead treated as boundary concerns:
- legacy import
- legacy export
- migration
- explicit external encoding conversion
A future codepage-import contrib/tool may use libiconv or another established conversion library if that proves to be the best implementation choice.
Collation
For collation, we are also taking significant guidance from the way modern PostgreSQL handles the problem.
The important separation is:
Encoding = how the Text is represented
Collation = how Text is ordered or compared for a language or locale
A Text value should not permanently carry a locale inside itself.
For example, UTF-8 tells us how characters are encoded. It does not tell us how characters such as é, e and É should sort for French, Hungarian, Swedish or another language.
HN's collation support is primarily intended for HN in-memory processing, for example:
- sorting HN Arrays
- comparing Text values
- working with HN Cursors
- local SQL processing
- filtering
- grouping
When the work is performed by PostgreSQL or another SQL backend, the database backend owns the collation semantics.
So conceptually:
PostgreSQL table/index
→ PostgreSQL collation
→ PostgreSQL collation-aware indexes
HN in-memory Cursor
→ HN collation
→ eventually ICU-backed
HN Text encoding
→ independent of both
HN should not try to duplicate PostgreSQL's index/collation behavior on the client and pretend it is identical.
That is especially important because PostgreSQL can build indexes according to a selected collation and tracks the collation provider/version. If the backend owns an index, then the backend must also own the rules under which that index was created and searched.
So yes: ICU fits the HN design, and PostgreSQL's modern separation of encoding, collation and indexed database behavior is an important reference model for us.
I would not, however, make HN Text simply an alias for something such as icu::UnicodeString. The HN language needs its own semantic contract independent of whichever implementation library happens to provide part of it.
- Why not use ncursesw/PDCurses as a cross-platform video driver?
I should clarify the HN direction here.
HN is not planning to carry all of Harbour's historical GT implementations forward as part of the core runtime.
Harbour's GT system is very capable and made a lot of sense for Harbour's compatibility goals.
HN's goals are different.
Traditional screen-coordinate programming such as:
@ ... SAY
@ ... GET
READ
SAVE SCREEN
RESTORE SCREEN
SET COLOR
and the traditional full-screen GT APIs may still be useful for migrating older applications, but I do not want that architecture to determine the core HN user-interface model.
If there is enough demand, I expect a Classic UI contrib could provide that type of functionality and could use appropriate terminal backends such as ncursesw or PDCurses.
That would remain optional.
The primary HN desktop direction is instead:
HN application/business logic
→ HN UI / Web Components
→ HN Desktop Host
→ platform WebView
The expected default renderer family is approximately:
Windows → WebView2
macOS → WKWebView/WebKit
Linux → WebKitGTK
That also means much of the same UI can operate in a normal browser.
Later, probably as a V2-generation capability, I want a visual Form/Class Designer inspired by the productive ideas in Visual FoxPro, but targeting the HN UI model rather than reproducing the VFP runtime.
I expect useful concepts such as:
- component palette
- form/layout designer
- property inspector
- object/component tree
- event/action editor
- data binding
- validation
- tab order
- visual preview
- reusable components/classes
The designer itself will probably be web-based.
WebView remains the preferred cross-platform rendering model.
If there is substantial community demand for native platform controls, that could eventually become a separate contrib renderer/backend. However, I do not want to reverse the current architecture and require HN itself to maintain independent Windows, GTK and macOS widget implementations.
The application design should remain renderer-neutral enough that an optional native-controls contrib could be developed later without redesigning the business application model.
So I like the abstraction idea in your diagram, but I would separate the architecture roughly like this:
HN application
For Text/Data:
HN application
→ HN Text/Data semantics
→ ICU when advanced Unicode services are needed
For UI:
HN application
→ HN UI / Web Components
→ HN Desktop Host
→ WebView2 / WKWebView / WebKitGTK
Optional later:
→ Classic UI contrib
→ Native-control contrib
4.1. Class property initialization and shared objects
This is a very good example, and this issue has already been reviewed explicitly.
Consider conceptually:
CLASS TSample
PROPERTY Object := MyObject()
ENDCLASS
HN's intended semantics are that MyObject() is evaluated separately for each new TSample instance.
It is not evaluated once when the class definition is initialized and then reused by every instance.
So:
oA := TSample()
oB := TSample()
would normally mean that:
oA:Object is not the same object instance as oB:Object
assuming that MyObject() creates a new object each time.
The same principle applies to mutable collection literals.
For example:
CLASS Customer
PROPERTY Tags Array := {}
ENDCLASS
Then:
oA := Customer()
oB := Customer()
oA:Tags:Add( "VIP" )
must not cause oB:Tags to suddenly contain "VIP".
Each construction evaluates the initializer separately.
HN's approved initialization sequence is approximately:
base-class property initializers
→ base constructor body
→ derived-class property initializers
→ derived constructor body
all operating on the same newly created object.
There is one important distinction.
If an initializer deliberately calls something such as:
PROPERTY Cache := GetGlobalCache()
and GetGlobalCache() intentionally returns an existing shared object, HN should not secretly clone it.
So the language distinguishes fresh construction from intentional sharing.
Class-wide state is also different. HN uses the CLASS PROPERTY concept for storage that intentionally belongs to the class rather than to each object instance.
4.2. IsDerivedFrom() versus ClassName()
I agree with you that these are different operations.
ClassName() answers approximately:
"What is the name of this object's class?"
An inheritance query answers:
"Is this object an instance of this class, or of one of its descendants?"
Those should not be implemented by comparing strings.
HN's compiler-native class model records actual class identity and inheritance relationships. Those relationships can therefore be queried using class metadata rather than doing something fragile such as comparing ClassName(oObject) with a string.
I have not finalized whether the public HN API will literally be called hn_IsDerivedFrom(), hn_IsKindOf(), or something else.
HN APIs are being systematically redesigned rather than automatically preserving every Harbour API name.
But yes, I agree that an inheritance-aware query is useful and should exist separately from a class-name query.
HN API naming
One of the general HN design rules is that all normal public HN core APIs will use the hn_ prefix.
For example:
hn_Something()
rather than accumulating several historical naming conventions.
The goal is that HN has one clearly identified core API namespace and, where practical, one canonical API for one semantic operation.
Compiler syntax and compiler-owned constructs are a different category. Keywords or special compiler constructs do not need the hn_ prefix because they are not ordinary runtime API functions.
4.3. Calling a parent implementation
HN already has an approved SUPER direction.
Conceptually:
SUPER:DoSomething()
from a derived method means:
"Invoke the inherited implementation on this same object."
Suppose we have:
A
→ B
→ C
and C:DoSomething() contains:
SUPER:DoSomething()
The natural meaning is to invoke the inherited implementation through B.
That is different from explicitly naming A, because that could mean:
"Skip B and invoke A directly."
Those are potentially different operations.
SUPER also has the benefit that a class does not unnecessarily hard-code the identity of its immediate parent.
For example, if the hierarchy changes from:
A
→ C
to:
A
→ B
→ C
a SUPER call in C can continue to mean "my immediate inherited implementation."
So I think SUPER is the better normal mechanism.
Whether HN should additionally support explicit named-ancestor qualification in specialized cases is still something we can discuss before the syntax is permanently frozen.
Imported libraries and namespaces
HN is also being designed so that imported libraries do not have to dump every public symbol into one global namespace.
Imported HN libraries will support qualified access using consumer-selected library aliases/namespaces.
Conceptually, a project might import a library using the local name:
Accounting
and then use:
Accounting.CalculateTax()
Accounting.Invoice()
Accounting.Invoice:Create()
Another application could import exactly the same library using a different local alias if that name fits the application better.
This also allows different libraries to expose similarly named classes or functions without creating global collisions.
For example:
Sales.Customer()
Accounting.Customer()
CRM.Customer()
could represent three different public classes.
The exact final import syntax is still being specified, but the important design decision is that HN will support qualified namespaces/aliases for imported libraries rather than forcing all public library symbols into one flat global namespace.
This is separate from the hn_ rule.
The hn_ prefix is reserved for canonical HN core APIs.
Imported application libraries and contrib libraries can instead be accessed through their qualified library namespace/alias.
- Why keep the main core primarily in C instead of moving it to C++?
C++ could certainly be useful for individual components, and I am not opposed to using it when there is a concrete benefit.
However, I currently prefer to keep the main HN compiler/runtime core primarily in C.
The advantages are architectural:
- a simple and stable native ABI
- straightforward integration with operating-system APIs
- easy integration with existing C libraries
- easier embedding from many programming languages
- clear ownership/lifetime boundaries
- minimal assumptions at interoperability boundaries
- excellent portability across supported compilers
It also makes the future HN embedding API easier to expose to languages such as:
- Python
- Rust
- C++
- C#
- Java
- JavaScript runtimes
- and others
because almost every language ecosystem knows how to call a C ABI.
That does not mean every HN component must be written in C.
Quite the opposite.
HN is intended to support Rust-authored contribs and selected components through a stable C ABI.
Conceptually:
HN
→ stable C ABI
→ C module
HN
→ stable C ABI
→ Rust module
HN
→ stable C ABI
→ C++ wrapper
A Rust contrib could compile as a native library and expose C-compatible entry points.
That lets us use Rust's memory-safety and modern library ecosystem where appropriate without rewriting the VM/compiler/runtime around Rust.
Security-sensitive, cryptographic or networking packages are particularly interesting candidates for that approach.
Similarly, if ICU or another useful library has C++ interfaces internally, an HN wrapper can isolate that implementation behind a stable HN/C boundary.
From the HN developer's perspective, the implementation language should normally be irrelevant.
For example:
hn_SomeFunction()
could internally be implemented using C, Rust, C++, or an external system library as long as it obeys the same HN contract.
That is one reason the API definitions, datatypes, errors, ownership rules and documentation are being specified independently from their implementation language.
One final clarification about the HN repositories and discussions
Since you mentioned examining source code, I want to emphasize again that the current HN development tree has not yet been made public.
I do plan to begin publishing much more precise language and architecture specifications for interested developers fairly soon.
The dedicated discussion group is:
https://groups.google.com/g/harbournova-users
Anyone interested can request access now.
Before HN 1.0 I intend to keep that group private. During Alpha/Beta development some specifications may still change significantly, and I would prefer that experimental proposals and design discussions not be mistaken for final language behavior.
Once HN 1.0 is released, the intention is for that group to become public.
I very much welcome this kind of technical review before then. Questions about Unicode architecture, class initialization, inheritance, external libraries and implementation-language boundaries are exactly the kinds of things that are useful to challenge before the language is frozen.
Thanks again for taking the time to review the ideas and send detailed suggestions.
Best regards,
Eric
hmpaquito
Eric Lendvai
Eric
Luigi Ferraris
As I wrote in my previous message, I'm not a great expert, so take with care these opinions :-))
Regarding:
I don't think it will be possible to use commands like DISPOUT, hb_Dispout in a GUI environment: too very simple command.
At the same time, I don't know if WebXXXXX family can be used for this purpose (terminal level).
For this reasons I think that a Terminal Text library give you a better way to replicate XBASE commands in a simple way.
Other question is GUI interface: a separated layer, addon library is mandatory.
2) classes
For previous reasons (but not only), a most robust classes implementation is required and is not related to backward compatibility
Related to ::super is right, but think about multiple inheritance like: myClass INHERIT abstract1, abstract2, etc You need to be able to specifically access a method of a specified inerithed class. And every inherited class must be initialized automatically
3) ICU or.....
I'm in agreement with you: for internal purpose and other propblems like collation sequence, etc.
4) DBF
For the same reasons, every commands related to dbf can be in a addon library (like SQL, etc) in this way you don't need a monster
5) About data types ( It's just my humble opinion, looking at other frameworks internal conversions process. )
A) Boolean
B) Number:
B.1) Integer -> C maximum signed long (machine dependant),
B.2) Real -> C maximum signed double (machine dependant)
B.3) High precision -> Decimal types
C) String, Character
D) Date
E) Time
F) DatTime structured + offset
Only humble opinions.
Regards, Luigi
Eric Lendvai
I found a configuration problems in the group setting. This is fixed now.
Could you try again please?
I can answer your questions there tomorrow and provide the current list of data types, which is quite large.
Eric Lendvai
Don't mind if my answers are sometimes long, they are generated using AI, which I review.
All answers are based using designs and implemetation I worked on for several months now.
Thanks and see you in the new group.