{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":249287295,"defaultBranch":"master","name":"Interpreter","ownerLogin":"Rhovas","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2020-03-22T22:50:18.000Z","ownerAvatar":"https://github.com/avatars/u/48461744?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1689121541.0","currentOid":""},"activityList":{"items":[{"before":"3ada88f83432ed44d089f76f7069f7758dcfcdbf","after":"e227c6b1042d38a6e7cbe13fd0982ebe5bef5bd3","ref":"refs/heads/master","pushedAt":"2024-07-06T23:57:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Remove Type.component from non-Reference types\n\nThis field is an artifact from the original design for types (particularly generics). Most uses are for support unique behavior with specific types (e.g. Integer/Dynamic) or displaying a \"base type\" name within errors (which in hindsight doesn't seem accurate for non-Reference types anyways).","shortMessageHtmlLink":"Remove Type.component from non-Reference types"}},{"before":"5e46f128051f13f30bf049b55cc212603d760502","after":"3ada88f83432ed44d089f76f7069f7758dcfcdbf","ref":"refs/heads/master","pushedAt":"2024-06-08T03:53:27.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Update dependencies (Kotlin v2, Kotest, Gradle)","shortMessageHtmlLink":"Update dependencies (Kotlin v2, Kotest, Gradle)"}},{"before":"9209a6beb53cd67551ced9b66cab67ff2c2a626b","after":"5e46f128051f13f30bf049b55cc212603d760502","ref":"refs/heads/master","pushedAt":"2023-12-22T04:38:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Split analysis into an independent multi-phase approach\n\nThis is a major change to the analyzer that has been a long time coming. The\nanalyzer previously used a 3-phase approach (analyze + declare/define). Each\nphase has been split into it's own class and a new Registration phase has been\nadded. The goal of this change is to support modules (aka multi-file analysis)\nwhich requires multiple analyzers to advance through phases in lockstep.\n\nAfter significant consideration, I believe a four-phase approach is sufficient:\n 1. Registration, which defines types globally such that they can be imported\n    and referenced by other files.\n 2. Declaration, which declares a component type (generics and inherits) such\n    that the type hierarchy is defined and subtype checks are supported.\n 3. Definition, which defines a component type with associated methods following\n    inheritance. This phase MUST be called in the order of the type hierarchy\n    (to be implemented with modules).\n 4. Analysis, which contains the bulk of analysis over executable code.\n\nI am convinced each phase is necessary (and that phase 3 must follow DAG\ntraversal of the type hierarchy), however I am not convinced that these are the\nonly phases needed (hence, motivation for splitting these up as well).\n\nThis has been largely strewn together in the \"simplest\" way possible at the\nexpense of future abstractions, and the general approach should be reviewed\nafter modules are implemented and the bigger picture is a bit clearer.\n\nThank god for tests.","shortMessageHtmlLink":"Split analysis into an independent multi-phase approach"}},{"before":"f6d32a4b1ee16f810a3e933e6b4cec51b6ee6bc4","after":"9209a6beb53cd67551ced9b66cab67ff2c2a626b","ref":"refs/heads/master","pushedAt":"2023-11-27T02:21:06.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Implement source-level component/function hoisting\n\nThis is a starting point for hoisting leading to multi-file compilation\n(modules) to enable recursive references. Long term, a better approach may be to\nchunk statements into hoistable sections which prevents using a function before\nit is defined (e.g. accessing variables not yet initialized).","shortMessageHtmlLink":"Implement source-level component/function hoisting"}},{"before":"7e0afe738346c21ee3edaa103e5d336adfc71bce","after":"f6d32a4b1ee16f810a3e933e6b4cec51b6ee6bc4","ref":"refs/heads/master","pushedAt":"2023-11-26T08:13:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Update dependencies (Kotlin 1.9.21, Kotest 5.8.0)\n\nUpdates Kotlin/Kotest. A Kotlin JS bug requires changing RhovasSpec to be an\nopen (not abstract) class; not ideal but ultimately not blocking:\nhttps://youtrack.jetbrains.com/issue/KT-63399.","shortMessageHtmlLink":"Update dependencies (Kotlin 1.9.21, Kotest 5.8.0)"}},{"before":"025ebfb890ab755ea4089dad217bbca8b6aace4c","after":"7e0afe738346c21ee3edaa103e5d336adfc71bce","ref":"refs/heads/master","pushedAt":"2023-10-11T07:31:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Remove usages of delegate inheritance\n\nDelegation is powerful, however there are quirks related to overriding methods\nimplemented by delegation. This can lead to contract splicing, as overriden\nmethods cannot be accessed by the implementation in the delegate (hence, the\nimplemented interface contract is \"spliced\" between the delegate and the class\nitself. This was an issue experienced when adding a new default method to\nFunction, as it defaulted to calling the delegate rather than calling the\noverriden method in the defining class.\n\nNote this is not claiming delegation itself is bad, just that this specific case\nof delegation when some delegated methods are overridden can lead to this issue\nof contract splicing.","shortMessageHtmlLink":"Remove usages of delegate inheritance"}},{"before":"c65007c76b41c9d291026d630d275e21682d2b0b","after":"025ebfb890ab755ea4089dad217bbca8b6aace4c","ref":"refs/heads/master","pushedAt":"2023-10-07T04:31:27.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Update RosettaCodeTests infrastructure, sync task solutions\n\nThis is preparation for future RosettaCode examples. The infrastructure now\nsupports stdin data and solutions have been updated to match the exact\nrequirements of their corresponding task. Tests have been moved/renamed to match\nthe exact RosettaCode task path, which helps with standardization and allows\nlinking to the actual task.\n\nRosettaCode itself has also been updated to contain these solutions.","shortMessageHtmlLink":"Update RosettaCodeTests infrastructure, sync task solutions"}},{"before":"7438a58a72774c5257d8ae4b5fe1687005ef7e4e","after":"c65007c76b41c9d291026d630d275e21682d2b0b","ref":"refs/heads/master","pushedAt":"2023-10-06T02:46:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Fix component generics being defined within static functions\n\nStatic functions are not attached to a component instance and thus shouldn't\nhave access to generics defined by the component. As there is no instance\nparameter, this generic is not guaranteed to be used and thus should not be\ndefined. This also allows static functions to 'shadow' component generics, as\nmight be desirable within a factory method.","shortMessageHtmlLink":"Fix component generics being defined within static functions"}},{"before":"5c009df9389c7a9d44709925ae8f84fdec3a85f9","after":"7438a58a72774c5257d8ae4b5fe1687005ef7e4e","ref":"refs/heads/master","pushedAt":"2023-09-24T20:35:27.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Fix generics with method/component shadowing (#27)\n\nThis fixes an issue with methods shadowing component generics. Because the\ncomponent type (with generics) is part of the `this` parameter, the method\ngeneric is instead bound to the value of the shadowed generic in `this`. The\nroot cause of this problem is relying on the name for identification rather than\nsomething like a unique id, so afterwards this restriction could be lifted.","shortMessageHtmlLink":"Fix generics with method/component shadowing (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"1761948752\" data-permission-text=\"Title is private\" data-url=\"https://github.com/Rhovas/Interpreter/issues/27\" data-hovercard-type=\"issue\" data-hovercard-url=\"/Rhovas/Interpreter/issues/27/hovercard\" href=\"https://github.com/Rhovas/Interpreter/issues/27\">#27</a>)"}},{"before":"b60a44d5406d2b456e55602dca6afa21e0d971c3","after":"5c009df9389c7a9d44709925ae8f84fdec3a85f9","ref":"refs/heads/master","pushedAt":"2023-09-21T22:12:37.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Fix order of generics/Dynamic cases during subtyping/unification (#29)\n\nThe order should always be bound generics first (to avoid overwriting existing\nconstraints) followed by Dynamic (to bind Dynamic before other types like Any).\nThis does not address test coverage over the types bound to generics which is\nthe larger issue that needs to be addressed here.","shortMessageHtmlLink":"Fix order of generics/Dynamic cases during subtyping/unification (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"1770728579\" data-permission-text=\"Title is private\" data-url=\"https://github.com/Rhovas/Interpreter/issues/29\" data-hovercard-type=\"issue\" data-hovercard-url=\"/Rhovas/Interpreter/issues/29/hovercard\" href=\"https://github.com/Rhovas/Interpreter/issues/29\">#29</a>)"}},{"before":"854bf4eabfbdc31aa317d6376b1469a72f1a7efa","after":"b60a44d5406d2b456e55602dca6afa21e0d971c3","ref":"refs/heads/master","pushedAt":"2023-09-21T07:58:55.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Refactor Type.Reference to use generic Maps, fix generic analysis order\n\nThis makes Type.Reference consistent with Component/Function generics as in the\nprevious commit. During initialization, Type.GenericDelegate uses the hardcoded\nnames of generic types to construct the generics map correctly (as the names are\nnot available on the component yet). An alternative idea is to define the names\nwhen constructing the Component, however this didn't appear to offer any\nadvantages and the core problem of initialization order is still present.\n\nAdditionally, this fixes the analysis order for generics to be after defining\nthe type for cases where the component is self-referenced as a generic bound.\n\nThis also changes Type.Generic to use a default of null (like Type.Variant) for\nease of use.","shortMessageHtmlLink":"Refactor Type.Reference to use generic Maps, fix generic analysis order"}},{"before":"deaffdc8d584e3bf5ee64410cb917c00bea2b32c","after":"854bf4eabfbdc31aa317d6376b1469a72f1a7efa","ref":"refs/heads/master","pushedAt":"2023-09-21T03:25:52.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Validate redefined generics, refactor initialization for LinkedHashMap generics\n\nThis adds validation for redefined generic types. Additionally, component and\nfunction declaration have been converted to use LinkedHashMaps for generics to\nstore the types in an easily-accessible name format. This is a can of worms in\nthe type system and exposes many problems related to initialization order with\ngeneric types (namely, types need to be registered and may be accessed prior to\ngeneric initialization completing). Library initialization has been split into\ndeclare and define phases (similar to standard analysis) to assist with this.","shortMessageHtmlLink":"Validate redefined generics, refactor initialization for LinkedHashMa…"}},{"before":"d5a15bdad1a07e06f65ae059d609c4314de72f6f","after":"deaffdc8d584e3bf5ee64410cb917c00bea2b32c","ref":"refs/heads/master","pushedAt":"2023-09-20T03:00:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Implement user-defined generics for components, fix related bugs\n\nThis allows defining components with generic types, which is already supported\ninternally but not exposed by the language. The implementation is\nstraightforward, but also fixes two bugs exposed by new test cases with generics\nhere (see below). Furthermore, the existing implementation for function generics\n(and now component generics) does not support lower bounded varargs due to being\nunable to identify which bound (lower and upper) is the generic type being\ndefined. There was an idea to allow apostrophes to implicitly declare generics\n(as in 'T) which resolves this problem and may be added in the future. In\naddition, generic definitions need to validate generic names are unique.\n\nThis also fixes two bugs. First, a few isSubtypeOf/isSupertypeOf calls within\nthe Type implementation did not pass the existing map of generic bindings, thus\npreventing generics from being applied correctly during resolution. Second, the\ncheck for existing property definitions used the type properties helper, which\nchecks the entire inheritance tree and thus does not work with inheritance\n(mainly for interface properties). However, this also needs to check for setter\ndefinitions and override restrictions in the same way as normal methods.","shortMessageHtmlLink":"Implement user-defined generics for components, fix related bugs"}},{"before":"593a90079a2d9ef1784b29e82d1dc31809075b1c","after":"d5a15bdad1a07e06f65ae059d609c4314de72f6f","ref":"refs/heads/master","pushedAt":"2023-09-18T03:28:09.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add Function.isResolvedBy for generic-safe resolution handling\n\nThis helper checks function resolution in a way that is generic-safe. Namely,\ngeneric constraints must be tracked across arguments and any variants introduced\nduring resolution collapsed to their bounds at the end. This function is only\nused in two places currently, however it is likely to be reused as part of\nreified generics in the Evaluator.","shortMessageHtmlLink":"Add Function.isResolvedBy for generic-safe resolution handling"}},{"before":"bad849f0f3f811424e8c8365be0b30c043bbec71","after":"593a90079a2d9ef1784b29e82d1dc31809075b1c","ref":"refs/heads/master","pushedAt":"2023-09-17T03:29:25.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add Context.generics for runtime generics, fix stdlib type checking (#28)\n\nThis replaces Context.arguments with Context.generics, since the only use of\narguments was to extract runtime generic types for constructing return values.\nThese generics are computed following the same rules as Scope resolution, but\nusing runtime types. Consequently, the type checking peformed when invoking\nnative functions should now validate generic relations as well (this is more of\nan improvement as part of reified generics than an outright fix, but a key step\ntowards safety here).\n\nNote that runtime times are still lacking as the Evaluator itself is using type\nerasure; this only fixes the handling for the standard library.","shortMessageHtmlLink":"Add Context.generics for runtime generics, fix stdlib type checking (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"1762392486\" data-permission-text=\"Title is private\" data-url=\"https://github.com/Rhovas/Interpreter/issues/28\" data-hovercard-type=\"issue\" data-hovercard-url=\"/Rhovas/Interpreter/issues/28/hovercard\" href=\"https://github.com/Rhovas/Interpreter/issues/28\">#28</a>"}},{"before":"4caba915c5f3ded63fa57d520e6d5899d4f4fbf6","after":"bad849f0f3f811424e8c8365be0b30c043bbec71","ref":"refs/heads/master","pushedAt":"2023-09-16T06:22:02.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add IR context to standard library errors (Resolves #3)\n\nFollowing the introduction of a Context receiver for standard library functions,\nthis updates the Evaluator require/error calls used to access the current IR\n(stored on the stack) for error handling. Consequently, errors will properly\nidentify the input range of the function invocation in diagnostics (rather than\nsimply showing the first line).\n\nNote that this does not allow extracting the IR of individual arguments. This\nwould be nice to have following a proper push-pull context system over the\nevaluator (like in the analyzer) as overall this system needs TLC anyways.","shortMessageHtmlLink":"Add IR context to standard library errors (<span class=\"issue-keyword tooltipped tooltipped-se\" aria-label=\"This commit closes issue #3.\">Resolves</span> <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"1224028531\" data-permission-text=\"Title is private\" data-url=\"https://github.com/Rhovas/Interpreter/issues/3\" data-hovercard-type=\"issue\" data-hovercard-url=\"/Rhovas/Interpreter/issues/3/hovercard\" href=\"https://github.com/Rhovas/Interpreter/issues/3\">#3</a>)"}},{"before":"2daad357f252c459e872290ea83fafacb5b2ae4c","after":"4caba915c5f3ded63fa57d520e6d5899d4f4fbf6","ref":"refs/heads/master","pushedAt":"2023-09-16T02:51:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Use reified generics to transform native arguments to avoid manual casts\n\nThis abstraction is a little hacky, but makes the standard library\nimplementation significantly easier to work with for passing arguments with\nunwrapped types. Using reified generics, the argument types are extracted as\neither the wrapped Object or unwrapped Object.value, thus avoiding the need to\nmanually extract/cast value in the implementation.\n\nFunctions that require extracting generic types from arguments can always access\nthe raw argument via Context.arguments, which is passed as an implicit receiver.\nLong-term, the idea is this Context can be used for additional helpers such as\naccessing generic types, checking require preconditions, and passing IR context.\n\nAdditionally, a few typing issues with the standard library have been fixed,\nnamely: Decimal rem/mod, String.to(Decimal), Iterable.for, and Map.remove.","shortMessageHtmlLink":"Use reified generics to transform native arguments to avoid manual casts"}},{"before":"f7c6b4efb77f07f50bb3183d1ac1126ec0201568","after":"2daad357f252c459e872290ea83fafacb5b2ae4c","ref":"refs/heads/master","pushedAt":"2023-09-05T23:07:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Replace direct uses of Type.Struct with helpers\n\nThe Type.STRUCT helpers are more convenient, simplify call sites, and provide a\nbetter overall abstraction. This is in preparation for enforcing Struct field\norder (via LinkedHashMap), so the fewer direct uses the better.","shortMessageHtmlLink":"Replace direct uses of Type.Struct with helpers"}},{"before":"a6fc6519f68af55bff75ce9851c0a0f4afa4ecde","after":"f7c6b4efb77f07f50bb3183d1ac1126ec0201568","ref":"refs/heads/master","pushedAt":"2023-09-01T02:33:22.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add language/syntax support for non-reference types (Resolves #18)\n\nSpecifically, allows defining Nullable (?), Tuple, Struct, and Variant types.\nCurrently, Tuple/Struct types can only be defined within generics (e.g.\nTuple<[X, Y, Z]>) for reasons of minimizing ambiguity (e.g. type literals).","shortMessageHtmlLink":"Add language/syntax support for non-reference types (<span class=\"issue-keyword tooltipped tooltipped-se\" aria-label=\"This commit closes issue #18.\">Resolves</span> <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"1714815614\" data-permission-text=\"Title is private\" data-url=\"https://github.com/Rhovas/Interpreter/issues/18\" data-hovercard-type=\"issue\" data-hovercard-url=\"/Rhovas/Interpreter/issues/18/hovercard\" href=\"https://github.com/Rhovas/Interpreter/issues/18\">#18</a>)"}},{"before":"b243b9721a8c1939d0b605583c3f6cd555c9e3a5","after":"a6fc6519f68af55bff75ce9851c0a0f4afa4ecde","ref":"refs/heads/master","pushedAt":"2023-08-19T06:11:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add README section for running Rhovas locally (latest changes)\n\nFollowing an initial release of Rhovas, the plan is to keep the online editor\non the latest release (better consistency with docs, less chance of regressions,\nand it has to be manually updated anyways). Therefore, testing unreleased\nfeatures (e.g. inheritance) requires running Rhovas locally with the latest\nchanges from master. This adds a corresponding instruction section with the\nnecessary commands for quick reference.","shortMessageHtmlLink":"Add README section for running Rhovas locally (latest changes)"}},{"before":"9e91c4c85a2f4e80b98635346444af76606343ef","after":"b243b9721a8c1939d0b605583c3f6cd555c9e3a5","ref":"refs/heads/master","pushedAt":"2023-08-13T19:02:41.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Rename Modifiers.Inheritance.DEFAULT to FINAL and set constructor defaults\n\nQuick rename for clarity and provides default values as with other environment\nclasses. The original intent of DEFAULT was to make it clear that it was the\n\"unspecified\" option; but it's better to have these named properly and the\nconstructor default helps to convey FINAL is the default anyways. If there's a\nstuation where an option can both be the default and explicitly specified, then\nit may be worth revisting this (e.g., allowing `final func`).","shortMessageHtmlLink":"Rename Modifiers.Inheritance.DEFAULT to FINAL and set constructor def…"}},{"before":"533f4b51e881b3485f90f7eeb6e1913fab551422","after":"9e91c4c85a2f4e80b98635346444af76606343ef","ref":"refs/heads/master","pushedAt":"2023-08-13T06:55:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add analysis checks for method overrides including abstract methods\n\nThis adds two categories of checks around inheritance. First, methods must\nspecify an `override` modifier if and only if overriding an inherited method.\nSecond, inherited methods must be overridden if they are abstract and the\ninheriting component is not.\n\nThe implementation for this uses a messy hack with Scope generics. The component\nscope now has a parent scope (`inherited`) which contains all inherited methods.\nFor concrete components, the child Scope.Definition will have a parent\nScope.Declaration by casting away generic safety. After validating overrides,\nany abstract methods in the parent will be overriden in the child\nScope.Definition and thus cannot be resolved at runtime (currently abstract\nfunctions are Definitions with empty bodies anyways, but this may change). This\nis undoubtably hacky, but it solves the problem well and keeps inherited methods\nseparate while working naturally with scope resolution at runtime.\n\nThis also solves an issue where the default Struct initializers couldn't be\noverriden since any new definitions would overlap with existing ones, whereas\nnow the default initializers are part of the inherited scope and thus properly\nact as a fallback if not overridden.","shortMessageHtmlLink":"Add analysis checks for method overrides including abstract methods"}},{"before":"497257098ea6f48fe78200c50b3a1ba6b9a74a1a","after":"533f4b51e881b3485f90f7eeb6e1913fab551422","ref":"refs/heads/master","pushedAt":"2023-08-07T01:55:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add runtime check for concrete Object.type, fix Struct inheritance\n\nThis checks any runtime object is a concrete (not abstract) type, aka has a\nDefinition scope. Additionally, Struct should not be abstract but rather virtual\ndue to struct literals (like Tuple).","shortMessageHtmlLink":"Add runtime check for concrete Object.type, fix Struct inheritance"}},{"before":"bec434aaadad663dd124b55e92222a1ddf6c5ad8","after":"497257098ea6f48fe78200c50b3a1ba6b9a74a1a","ref":"refs/heads/master","pushedAt":"2023-08-07T00:59:28.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Convert Variable/Function constructors to use default arguments\n\nThis continues the trend of moving towards defaults for better visibility of\nmeaningful values. These now work the same as the Library initializer helpers,\nwhich requires named arguments to be used. Furthermore, parameters and returns\nmust always be specified since they're almost always used and tends to be better\nfor clarity. Overall this is an increase to real estate, but should help with\nreadability, consistency, and messy one-liners.\n\nIt's always possible to add secondary constructors if needed, but for now let's\nsee how this plays out and how much I like the named arguments approach. Similar\nchanges to the AST/IR at some point will feed back into this as well.","shortMessageHtmlLink":"Convert Variable/Function constructors to use default arguments"}},{"before":"eb60d1711d596a065e3386f2d20b2f87372cc548","after":"bec434aaadad663dd124b55e92222a1ddf6c5ad8","ref":"refs/heads/master","pushedAt":"2023-08-06T20:35:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Compute Scope instance using inheritance for Component initialization\n\nThis changes Component.scope from a constructor parameter to computed field\n(based off whether the component is abstract). This reduces the number of\ninvariants that need to be managed externally and there is currently no reason\nto have this in the constructor.\n\nFurthermore, modifiers has been changed to an optional argument (keeping it as\nan argument for when additional modifiers like visibility/override are added).\nIn the past I've intentionally avoided default arguments to prefer specifying\nthem explicitly (particularly as non-test code generally shouldn't use them\nanyways), but as these options grow that significantly hampers the clarity of\nwhich values are meaningful or not. Moving forward, defaults will be more common\nand the standard will be to match presence/absence in source code - e.g.\ndefaulting modifiers to the same values as when not specified in the source code\nis a good balance as it's consistent with Rhovas itself (thus, predictable) and\ntest coverage is sufficient for accidental use of defaults.","shortMessageHtmlLink":"Compute Scope instance using inheritance for Component initialization"}},{"before":"a1f973c77af5a2c618772ec8e83ee481d30e80d6","after":"eb60d1711d596a065e3386f2d20b2f87372cc548","ref":"refs/heads/master","pushedAt":"2023-08-06T09:15:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Cleanup Scope casts via manual In/Out parameters\n\nKotlin doesn't have a way to indicate a parameter in both in/out (aka, bounded\non both sides) so this introduces a workaround by manually specifying both via\nseparate generic types. This makes generic uses a bit unwieldy, but removes the\nneed for a bunch of unnecessary casts as use-site which is worth it.","shortMessageHtmlLink":"Cleanup Scope casts via manual In/Out parameters"}},{"before":"d3a7a5798799fb01875b322f42e98a7ee665cf6a","after":"a1f973c77af5a2c618772ec8e83ee481d30e80d6","ref":"refs/heads/master","pushedAt":"2023-08-06T08:34:18.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Split Type.Base into separate Component classes to support Declarations\n\nThe existing Type.Base class was built on the assumption that all types use a\nDefinition scope (which was a fair simplification for the time). In preparation\nfor abstraction methods, this has been split into separate Component classes\nthat allow Scope.Declarations to be used. This comes with a hefty refactor, but\nthe end result is better and also helps with some other issues (e.g. storing the\ncomponent in IR minimizes hacky lookups for the type and also ensures tests show\ninherited types in the error message, which was an annoying quirk previously).\n\nOutside the main inheritance work, it would also be beneficial to enforce\nDefinition scopes at runtime (e.g. Object.type should not be abstract) and there\nare a few TODO notes related to this split that leads into modularity.","shortMessageHtmlLink":"Split Type.Base into separate Component classes to support Declarations"}},{"before":"5f6c70b1015775c8eb7ca60f173240d736c785ae","after":"d3a7a5798799fb01875b322f42e98a7ee665cf6a","ref":"refs/heads/master","pushedAt":"2023-08-05T03:11:37.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Implement interfaces and validate struct/class/interface inheritance\n\nThis adds support for interfaces (currently implemented to basically be the\nsame as abstract classes). All components can implement any number of interfaces\nand classes may optionally extend a single class. There are a few opportunities\nto unify/abstract shared logic here better; parsing seems worthwhile right now\nwhile the rest should wait until inheritance is finished.\n\nAs with classes, all defined methods are inherited and there is no validation\nor restrictions implemented for methods (e.g. overriding). Specific to\ninterfaces, there are also no checks for problems caused by multiple inheritance\n(e.g. diamond problem). This will likely involve revisting the Type.Base\napproach to split off Concrete (Scope.Definition) and Abstract\n(Scope.Declaration) types.","shortMessageHtmlLink":"Implement interfaces and validate struct/class/interface inheritance"}},{"before":"051abfba65ee34dec21edf5164daeb5418779fa6","after":"5f6c70b1015775c8eb7ca60f173240d736c785ae","ref":"refs/heads/master","pushedAt":"2023-08-01T22:22:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Add inheritance modifiers, implement inherits type validation\n\nThis adds modifiers for inheritance (virtual/abstract) that are used with\ncomponents/methods for inheritance. This covers syntax support (which is helpful\nfor writing accurate programs even if the validation comes later) and validates\nthe inherited component permits inheritance. For now, interfaces are considered\nabstract classes (approach TBD once interfaces are added).\n\nThere is no validation for methods (e.g. override). The current approach for\ninheriting methods doesn't work with this; as it effectively inherits any parent\nmethods that are undefined. Instead, a different approach that handles\ninheritance first followed by method definition needs to be done (or a fully\nseparate validation approach).\n\nAdditionally, note the require precondition added to Type - my hope is that\nmore of these kinds of preconditions can be explicitly specified moving forward.\nThis is mainly limited by hacks from standard library initialization.","shortMessageHtmlLink":"Add inheritance modifiers, implement inherits type validation"}},{"before":"c9d8b664d9fca814825e4461b506a18096c5a64f","after":"051abfba65ee34dec21edf5164daeb5418779fa6","ref":"refs/heads/master","pushedAt":"2023-07-30T17:48:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"WillBAnders","name":"Blake Anderson","path":"/WillBAnders","primaryAvatarUrl":"https://github.com/avatars/u/35618116?s=80&v=4"},"commit":{"message":"Implement core inheritance and initializer support\n\nThis is a first pass at inheritance which should cover the core functionality\n(inheritance of fields/methods and constructors). The main limitations right now\nare with restrictions (e.g. interfaces, virtual/abstract classes and methods,\netc.) and initializers (quirks with initializing fields and maintaining proper\nsubtyping in the parent class).","shortMessageHtmlLink":"Implement core inheritance and initializer support"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEeJ_vxQA","startCursor":null,"endCursor":null}},"title":"Activity · Rhovas/Interpreter"}