Use of قلب lisp vocabulary on HDPLisp for ISO 639-3: apc (maybe also as initial reference for ISO 639-3: ara

[fititnt]

Hi @nasser! First, let me say: people like you have my respect.

TL; DR: Could you please kindly authorize use of part of the keywords you took deep care to choose almost 10 years ago to be part of Vocabulary Knowledge Graph and (this is Important) allow public domain license (the initial organization is @EticaAI)? (It's not the code, but the words).

---

The bare minimum need for ISO 639-3 apc

• ATOM
• CAR (*)
• CDR (*)
• COND
• CONS
• EQ
• LAMBDA
• PRINT
• QUOTE
• READ

Also, based on this #8 (comment), I assume the very specific dialect you are using is Lebanese Arabic Wikipedia with ISO 639-3 apc on ISO 369-3. https://iso639-3.sil.org/code/apc.

Context

I'm here mostly as individual who is building tools for others and the target audiences is humanitarian field with special care to build production-ready While on https://github.com/EticaAI/HXL-Data-Science-file-formats do exist a lot of moving parts, (like the facto convert high level instructions to complex API calls) compared to alternatives, Lisp is more feasible to implement internationalized Turing-complete implementations.

The Domain Specific Language (that is not the dialect of lisp, but is something that could be used to implement advanced used) is called at the moment HDP. The GitHub issue is here [meta] HDP Declarative Programming (working draft) #16. The folder with ontologies is this one https://github.com/EticaAI/HXL-Data-Science-file-formats/tree/main/hxlm/ontologia (core.vkg.yml is used by HDP, but the (temporary name) HDPLisp do not yet have this type of vocabulary to transpose between natural languages).

You and others here may also be interested on this topic [meta] Internationalization and localization (i18n, l10n) and internal working vocabulary #15

What @EticaAI (and me) can do for قلب and you and other collaborators from non-Latin writing systems

I can acknowledge your previous work on software comments or when eventually do exist some place to cite collaborators, but by the very nature of the final usage, not even names like my would be referenced. Also, for the very nature of one of the targeted usage, humanitarian fields, allowing things to be public domain (even if it means writing code from scratch) simplify things. Its not just about be very well crafted, because of politics, war, etc on worst case do exist something that could be shared allow easier adoption.

Also, with such kind help and assistance of someone like you, as soon what is not temporary called HDPLisp have bindings, your code examples could be transpiled to other lisp dialects, and some of then allow direct port to C. So running Lisp inside an JavaScript or Python may not be fast (and this in fact is not my focus), but in theory even without optimizations is viable transpose at least a subset of functions of natural languages to "English".

The idea (and usable proofs of concept already exist) is let the maximum of the Vocabulary on either YAML or JSON files (this means make easier for the real people who could localize). But note that Arabic, both because is non-Latin, but also because RTL, requires deeper testing.

More advanced usages

As a matter of principle, while anyone could extend or add new features (this happens when we have Turing Completeness) at this point I'm more likely to focus on some baseline that allow exchange with more important keywords that could be translated with 100% equivalence.

So, for example, if you or someone from your culture would like to have a "ENG:sum" ("POR:soma", "SPA:suma"...) function, either such extensions would be translated to something like "+" or be somewhat acceptable think like every natural language also would need to have this name.

Maybe to make things feasible, even if local community would use an named function for express "ENG:sum", when the document would me exchanged with other locals, internally either the document would transfer a copy of the know function or could use an hash. This for example could somewhat allow interoperability between languages. These types of potential usages that could make easier for local community use compact syntax while being usable outside is what I would try to focus, but if you or other people as soon as we start to have something that can be used start to create some library, I will not oppose to this.

Numbers

But for example, this comment here #9 from you and @rednaks @muattiyah @MohammedFadin. This is the type of feature that the base library, instead of "decide" in a very hardcoded which numeric system an language must use, this could be configurable.

I'm not saying that we can make promises, but things that could solve cultural issues (or localization specific cases) while still implementable could be done as early as possible (see some drafts here EticaAI/HXL-Data-Science-file-formats#15 (comment)).

This example with numbers tend to be more important than decide huge number of named functions for every language.