{"id":23896544,"url":"https://github.com/brecert/emb","last_synced_at":"2026-02-03T16:31:01.317Z","repository":{"id":113036098,"uuid":"347025862","full_name":"brecert/emb","owner":"brecert","description":null,"archived":false,"fork":false,"pushed_at":"2021-03-20T08:58:43.000Z","size":10,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-02-23T07:33:04.599Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/brecert.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"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}},"created_at":"2021-03-12T10:23:20.000Z","updated_at":"2021-03-20T08:58:45.000Z","dependencies_parsed_at":"2023-06-06T14:30:10.083Z","dependency_job_id":null,"html_url":"https://github.com/brecert/emb","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/brecert/emb","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/brecert%2Femb","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/brecert%2Femb/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/brecert%2Femb/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/brecert%2Femb/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/brecert","download_url":"https://codeload.github.com/brecert/emb/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/brecert%2Femb/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":262035214,"owners_count":23248361,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","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":[],"created_at":"2025-01-04T16:53:08.169Z","updated_at":"2026-02-03T16:31:01.272Z","avatar_url":"https://github.com/brecert.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Emb\n\n\u003e A programming language idea that I have\n\n_I'm currently making up a lot of the ideas as I go, so the examples may be inconsistent (although I've tried to keep them consistent)_\n\nCurrently it draws inspiration from\n\n- [powershell](https://github.com/powershell/powershell) for the idea of functions being valid commands, and complex parts of the language still just being shell\n- [elixir](https://elixir-lang.org/) for how elegant syntax sugar can be\n- [rust](https://www.rust-lang.org/) for api concepts and some type concepts\n- [dyon](https://github.com/PistonDevelopers/dyon) for some of the \"weirder\" ideas it's introduced\n- [cue](https://cuelang.org/) for the way it validates data\n\nIn it's current form, it'd be unfeasable to realistically implement\n\nThings I want for a language like this\n\n- able to be compiled/executed with the command structure intact and helper options added\n  see [minecraft.expected.slang](./examples/minecraft/minecraft.expected.slang) for what I'd want that to look like\n- advanced types, just because it's more dynamic/scripting does not mean types should be avoided\n  - instead types will be mostly inferred\n  - really only\n    - new types\n    - input types\n      should be required\n- an alternative syntax, I want to find a nice alternative to bash/powershell/scripting\n  - simple and clean\n  - just enough symbols for identification\n  - clear separation between different syntax layers (for example, between an object and a type)\n  - somewhat user definable syntax\n  - pattern based syntax\n- ease of use\n- an easy to use \"batteries included\" standard library, but still explicit enough to not use that standard library when not needed\n\n## Type system\n\nThe type syntax layer should be indicated with `\u003ctype expression\u003e`\n\nExamples:\n\n```rs\ntype Username \u003cstring\u003e\ntype \u003cinfer A, B\u003e Either \u003cenum { A: A, B: B }\u003e\ntype \u003cinfer T\u003e Maybe \u003cenum { Some: T, None }\u003e\n\n// paths aren't bound by `/`, and can be represented/used in multiple forms\nuse std:unwrap\n\n// _ refers to the current self, although this may just be changed to self in the future\n// {} is used for interpolating variables, although some enclosure types are automatically interpolated like strings\n\nimpl \u003cunwrap\u003e for \u003cMaybe\u003e\n  def unwrap \u003cself\u003e\n    match {self} {\n      Maybe:Some:\u003cT\u003e =\u003e T,\n      Maybe:None =\u003e panic \"Unable to unwrap Maybe\"\n    }\n```\n\n## Layers concepts\n\nI have this idea in programming languages that there are dimensions to it, for example in some languages a type system might be it's own dimension.\n\nWith this concept in mind, I've tried to separate some of the dimensions/concepts (to some degree) out into consistent parts of the language.\n\n`\u003ctype\u003e` indicating types and `{value}` (typically) indicating values/expressions for a call being part of that\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbrecert%2Femb","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbrecert%2Femb","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbrecert%2Femb/lists"}