{"id":34271630,"url":"https://github.com/monte-language/typhon","last_synced_at":"2026-03-10T16:31:54.327Z","repository":{"id":16818362,"uuid":"19577510","full_name":"monte-language/typhon","owner":"monte-language","description":"A virtual machine for Monte.","archived":false,"fork":false,"pushed_at":"2025-10-22T20:37:55.000Z","size":17776,"stargazers_count":68,"open_issues_count":76,"forks_count":7,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-12-20T08:16:27.897Z","etag":null,"topics":["compiler","ocap","python","vm"],"latest_commit_sha":null,"homepage":"","language":"Mathematica","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/monte-language.png","metadata":{"files":{"readme":"README.rst","changelog":null,"contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2014-05-08T14:59:57.000Z","updated_at":"2025-10-22T20:37:58.000Z","dependencies_parsed_at":"2024-04-20T07:30:48.563Z","dependency_job_id":null,"html_url":"https://github.com/monte-language/typhon","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/monte-language/typhon","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/monte-language%2Ftyphon","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/monte-language%2Ftyphon/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/monte-language%2Ftyphon/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/monte-language%2Ftyphon/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/monte-language","download_url":"https://codeload.github.com/monte-language/typhon/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/monte-language%2Ftyphon/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30342176,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-10T15:55:29.454Z","status":"ssl_error","status_checked_at":"2026-03-10T15:54:58.440Z","response_time":106,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["compiler","ocap","python","vm"],"created_at":"2025-12-16T19:40:46.228Z","updated_at":"2026-03-10T16:31:54.319Z","avatar_url":"https://github.com/monte-language.png","language":"Mathematica","funding_links":[],"categories":[],"sub_categories":[],"readme":"======\nTyphon\n======\n\nTyphon is a virtual machine for Monte. It loads and executes Kernel-Monte from\nMonte AST files.\n\nDon't panic! We are in ``#monte`` on Libera.\n\nHow To Monte\n============\n\nYou will need Nix, either by dint of being on NixOS or by installing\nsingle-user Nix.\n\nOnce you have Nix, you can build a basic toolchain by building the ``monte``\ntarget::\n\n    $ nix-build -A monte\n\nNote: Translation is not cheap. It will require approximately 0.5GiB memory\nand 5min CPU time on a 64-bit x86 system to translate a non-JIT Typhon\nexecutable, or 1GiB memory and 15min CPU time with the JIT enabled. It will\ntake another few minutes to build all of the Monte support libraries.\n\nFor only a bit more extra CPU time, one can build a toolchain which includes\nCapn Proto support::\n\n    $ nix-build -A fullMonte\n\nThe pure-Monte portions of the build are incremental, so after building\n``monte``, the build of ``fullMonte`` should be relatively quick.\n\nFor development, it can be useful to build only the VM::\n\n    $ nix-build -A typhonVm\n\nAnd to run the VM untranslated, use a Nix shell::\n\n    $ nix-shell default.nix -A typhonVm\n    [nix-shell:~/typhon]$ pypy main.py ...\n\nContributing\n============\n\nContributions are welcome. Please ensure that you're okay with the license!\n\nDiffing Typhon Binaries\n-----------------------\n\nBy default, git won't show diffs of binary files. I don't especially blame it.\nHowever, with a bit of a filter, we can give git what it needs::\n\n    $ nix-env -iA monte -f default.nix\n    $ git config --replace-all diff.typhon.textconv 'monte dump-mast'\n\nThis configuration option, along with the ``.gitattributes`` in the\nrepository, will let git display textual diffs of the binary ASTs.\n\nRPython Quirks\n--------------\n\nHere's what you need to know about RPython and things imported from\n``rpython.rlib``.\n\nImmutability\n~~~~~~~~~~~~\n\nLike Monte, RPython values immutable structures. Whenever a class is\nimmutable, adding the ``_immutable_ = True`` annotation will cause RPython to\nenforce an immutability variant: The fields of an instance of that class can\nonly be assigned to once.\n\nDon't use ``_immutable_`` unless the class is *totally* immutable. It's\npossible to make only some fields immutable; just list all the immutable\nfields in a tuple with ``_immutable_fields_ = \"this\", \"that\"``. To make a\nfield an immutable list with immutable elements, use a ``[*]``, as in\n``_immutable_fields_ = \"this\", \"that\", \"those[*]\"``.\n\nThe JIT (``rpython.rlib.jit``)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n``r.r.jit`` is mostly about hints to inform the JIT about the behavior of code\npaths. Some hints are safe and some are not safe.\n\nThe JIT colors all values as \"red\" or \"green\"; a red value is non-constant and\na green value is constant. ``promote`` accepts a red value and turns it into a\ngreen value. The JIT will reflect this with a guard on the value of the given\nobject. When a value is expected to have a relatively small number of\npossibilities, a ``promote`` can be very effective at improving the\nperformance of the code. ``promote`` is safe; it will never cause the JIT to\ngenerate wrong code, although it can cause the JIT to perform too much\ncompilation.\n\n``jit_debug()`` can print one string and up to four integers to the JIT log.\nThe computation which prepares the debug message is part of the JIT trace, so\nit is ideal to have the inputs be green values.\n\n``elidable`` functions must be referentially transparent. In return, the JIT\naccepts the promise of referential transparency and will try to reorder or\nremove the call to the ``elidable`` function when it can. The function need\nnot actually be pure; it is sufficient for it to appear pure in all cases. If\nthe function is not pure, then ``elidable`` is unsafe, since the JIT will not\nsecond-guess a promise of elidability.\n\n.. note::\n    Do *not* mark ``elidable`` if you want the JIT to inline the function. The\n    JIT will not enter an ``elidable`` function.\n\n``elidable_promote`` changes a function so that it is ``elidable`` and all of\nits arguments will be ``promote``'d before entering the function body. It is\nunsafe, like ``elidable``.\n\n``dont_look_inside`` forces the JIT to not inline calls to a function. It is\nsometimes necessary to protect events like GIL handling or I/O. It can also be\na big improvement for calls to functions which don't inline well due to\nrecursive or other strange behavior. It should be safe.\n\n``unroll_safe`` forces the JIT to consider inlining calls to functions which\nwere not inlinable due to containing loops. This is important because the JIT\nwill otherwise refuse to look inside those functions. Usage of ``unroll_safe``\nis an informal promise to the JIT that the loops in the function are tightly\nbounded in the number of iterations which will be performed. While not unsafe,\n``unroll_safe`` can cause exponential amounts of overcompilation and\novertracing, so it should be used sparingly.\n\nHow are these used within the codebase? Values that are expected to be green\nbut aren't green-inferred by the JIT are ``promote``'d. Functions that do I/O\nhave ``dont_look_inside``. Functions which are pure and called often are\n``elidable``. Lots of factoring has been done to make small chunks of code\n``elidable``.\n\nIf a function has a loop that is conditionally called, it is useful to factor\nthe loop to a separate function and then consider whether to mark the new\nfunction with ``unroll_safe``. Even if the function isn't actually safe to\nunroll, merely the factorization of code is sufficient to allow the JIT to\nlook into the original function. This happens with every object which is\ndefined in RPython; the dispatch function, ``callAtom()`` or similar, is\nfactored to not have loops within it. Since atoms are (usually) green values\nduring execution, this means that ``callAtom()`` gets specialized for that\natom, and the actual work can usually be inlined.\n\nUnicode (``rpython.rlib.unicodedata``)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nWe use RPython's Unicode database. The magic incantation::\n\n    from rpython.rlib.unicodedata import unicodedb_6_2_0 as unicodedb\n\n``unicodedb`` will have plenty of useful functions, like ``islower()`` and\n``isalpha()``. These functions are *not* available as methods on ``unicode``\nobjects.\n\n.. _reference Monte: https://github.com/monte-language/monte\n\nDocumentation\n-------------\n\nIf you create a new object by subclassing ``Object`` or calling ``@runnable``,\nplease give it a docstring. The docstrings will be reflected into Monte, so\nplease follow these guidelines:\n\n* The first line should describe the object.\n* Subsequent lines should describe specifics of the object's nature which\n  might be helpful to somebody calling ``help()`` on the object.\n* Docstrings should refer to their object as \"this object\".\n* In-jokes are sometimes allowed. Ask on IRC.\n* Dry language is always allowed.\n* Unicode is encouraged; do not be afraid to use symbols which are generally\n  available in Unicode fonts. Ask on IRC if unsure.\n\nAn example:\n\n    ▲\u003e help(Any)\n    Result: Object type: AnyGuard\n    A guard which admits the universal set.\n    This object specializes to a guard which admits the union of its\n    subguards: Any[X, Y, Z] =~ X ∪ Y ∪ Z\n\nAlso document objects and methods written in Monte. For methods:\n\n* \"this method\" is the correct self-reference.\n* To refer to names defined in the method specification, surround the name in\n  backticks.\n* To refer to methods, use atom syntax and backticks: A method with name\n  \"meth\" and arity 2 would appear as \\`meth/2\\`.\n\nAutohelp would like to remind you that subclasses of ``Object`` should\ndecorate themselves with ``@autohelp`` in order to maintain compliance and\nsafety.\n\nTo override pretty-printing for an object, add a ``toString()`` method which\nshould return a Unicode string.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmonte-language%2Ftyphon","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmonte-language%2Ftyphon","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmonte-language%2Ftyphon/lists"}