Metacircular self-registration of MetaCall API via _ex load parameters

Open
  • Is something wrong?
#715 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
c
Domain
api, backend

Research direction

Start by reading the _ex load path and base PR 668, then inspect the C loader and source/tests/metacall_c_metacall_test/source/metacall_c_metacall_test.cpp. The work is complete when extra load flags flow through the _ex path, the C loader applies them, and the self-load test validates the metacircular flow; startup behavior remains the final step.

Written by the indexing model from the issue text.

Description

🚀 Feature

I’m writing this issue from a clarity & discussion with sir @viferga to track the idea clearly.

Problem

Right now, for each target language (Node, Python, etc.), we wrap the MetaCall API (metacall.h) again in that language’s style.

That means we keep reimplementing similar bindings multiple times, which is slow and time consuming & pasting thousand lines of code , everytime is hectic.

Goal

Enable a metacall-into-metacall flow where MetaCall can expose/load its own API path through loader configuration, reducing duplicated wrapper work.

Enable metacircular loading in core: pass extra flags through _ex, make C loader consume them, and make metacall_c_metacall_test work with that flow. Then define a default startup strategy for this path.

Scope of Work

1) _ex load flags support
2) C loader flag handling
  • Add support in C loader to receive and apply those extra flags.
3) Test implementation with extra flags
4) Default-load strategy in startup

Implement a default-load strategy for metacircular usage:

  • either force/package C loader path across platforms, or
  • export/embed required definitions in code (bindgen-like direction for MetaCall).

Proposed Solution

Implement a metacircular flow where MetaCall can expose its own API through loader-driven registration instead of repeating wrappers per language.

Logically:

  • Register metacall.h + libmetacall.so into MetaCall itself.
  • Make that API accessible from target languages through the same runtime path.
  • Use _ex load configuration and C loader flag support to make this practical (paths/options needed for loading/compilation).
  • Validate with the dedicated metacall C self-load test.

Additional info

  • This is an umbrella tracker for the full scope above.
  • Implementation should be split into focused PRs per step.
  • Step order should follow 1 to 4.

If this works, we can progressively reduce duplicated wrapper logic across language ports and move toward automatic API exposure for new ports.

Dominant language
C
Stars
1.8k
Forks
266
Avg merge
2d 16h
Merged PRs (30d)
14

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from metacall/core

All issues in metacall/core

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.