Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EXPERIMENT] Arturo as Data #1763

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

drkameleon
Copy link
Collaborator

Description

This PR will serve merely as a lab, to experiment with the idea of Arturo as a data format (think Json, and you'll be spot on).

Also, here I would mention Carl's own idea - which is similar-ish since the two languages share some syntactic elements. But there are also lots of differences which make the format described in the link not precisely suitable for Arturo.


Where to start

Basically, it's very simple; Arturo has different layers:

  • (1) the parser (text -> Arturo values)
  • (2) the AST generator (Arturo values -> AST tree)
  • (3) the evaluator (AST nodes -> bytecode)
  • (4) the exec loop (bytecode -> ⚡ )

The data it "natively" understands - as a literal - stops at the very first step: the parser.

In different words, whatever the parser can see could be used as a valid type in a possible data format (from now on, and to avoid repeating it 18966 times: AAD)

What's "wrong" with that

We can see what the problem is by using the parser via Arturo itself. And the normal way would be to :block.

Screenshot 2024-10-10 at 17 34 55

That's awesome (obviously). I mean... it's already data. We don't have to do anything!

Now, let's try to trigger the issue:

Screenshot 2024-10-10 at 17 36 51

So, a :string, an :integer, a :floating and... a :word(❗).

Caution

And no true is not a :logical - it is evaluated as such; not parsed as such!
Otherwise, Arturo would suddenly have reserved keywords; and as we know, we don't! 😉

So... as you can see, we should find a way to - at least - define a way to refer to a limited set of specific constant-literals; namely: true, false, null (I cannot think of anything else)

Another issue

The most important issue I've thought since the very beginning:

Screenshot 2024-10-10 at 17 41 52

Yep, exactly: # is just an alias to dictionary which is... a function call, that is to be executed!

In a few words: we don't have literal dictionaries.

And what sort of data format is this claiming to be when we'll have a SemVer literal, but not be able to define a hash/dictionary/table/you-name-it? Obviously, this is important.

One idea would be to use #[ as a dictionary-literal start symbol. But then, wouldn't this clash with our "normal" Arturo? What if you actually want to wrap #[something] - as is - and then store it as data?! 💥

Another idea would be to use {..} as Carl suggests. But this would 100% against our use of curly braces in Arturo as string delimiters.

Plus, the more new syntax rules we invent for AAD, the less the two syntaxes will look alike.
We want something seamless here. Ideally... identical.

And, if not: as-identical-as-possible.

Food for thought! 🍕 (or pizza for thought, for that matter lol)

Type of change

  • Code cleanup
  • New feature (non-breaking change which adds functionality)

@drkameleon drkameleon added enhancement New feature or request vm Issues related to the Virtual Machine implementation open discussion Open discussion about features/ideas/suggestions parser Issues related to the evaluator (src/vm/parse.nim) experimental Experimental PRs (may be completely abandoned; or maybe not...) labels Oct 10, 2024
@RickBarretto
Copy link
Collaborator

Worth to mention: https://github.com/RickBarretto/blanca

@drkameleon drkameleon mentioned this pull request Oct 18, 2024
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request experimental Experimental PRs (may be completely abandoned; or maybe not...) open discussion Open discussion about features/ideas/suggestions parser Issues related to the evaluator (src/vm/parse.nim) vm Issues related to the Virtual Machine implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants