* refactor: add type candidates for validation
This commit adds a new module and type, the TypeCandidate, which
represents a potentially valid or invalid type. We use it as the
input for both type validation routines and type binding generation. The
type also allows us to unify the structure of sum types and product
types in an xobj agnostic way, paving the way for future simplification
of binding generation for type definitions.
This commit also removes SumtypeCase.hs, since it's no longer needed.
* refactor: add template generators; update type templates
This commit builds on the TypeCandidate data structure further by
providing "template generators" that work on candidates. Using
generators, templates for type functions ("methods") can be written
almost completely declaratively. Generators also remove some of the
typical boilerplate involved in creating templates from lists of tokens
and enable us to unify several of the generic and concrete templates for
types.
Generators can act on type candidates or their fields (for
field-specific functions). In general, this approach makes the
generation of type templates more structured. A type candidate now
contains all the information a generator needs to create appropriate
templates, thus it is a single and well-defined input for validation and
generation of user defined types.
This commit also updates the Deftype templates to use template
generators.
* refactor: use template generators for sumtype templates
This fixes an issue where by types with fields registered in modules
weren't emitted with their module paths. This makes the behavior between
RegisterTypeWithoutFields and RegisterTypeWithFields the same. They both
account for the current module path in which the type is registered and
output the emitted typedef appropriately.
This fix also eliminates the need for a workaround in core/Pattern.carp.
We previously had to register MatchResult with an override because of
the old behavior, but now the override is no longer needed (since
MatchResult is defined as PatternMatchResult in its source header). The
call (register MatchResult) within (defmodule Pattern) emits
"PatternMatchResult" by default since we now account for module paths
for registered types.
Historically, we did not support calling (register-type) within a
module--while there were instances of such calls (even in our core
library!) they were not properly handled in two ways:
1. They weren't added to the right place in the type environment.
2. Their corresponding emitted code wasn't correct.
This commit enables registering types in modules by making a few fixes:
1. Fix the logic in environment mutations -- before, adding a type to an
environment would result in traversing the environment chain
incorrectly. This is now fixed (we traverse modules and retrieve a
type environment only at the end of the traversal).
2. Fix the typedef emission for registered types--it previously emitted
the C code for the type path, not for the type definition (it called
pathToC not tyToC).
This will now allow authors of wrapper libraries to add more structure
to their Carp wrapper APIs.
This commit also adds a test to check the behavior.
* feat: add box templates and box type
This commit adds an implementation of Boxes, memory manged heap
allocated values.
Boxes are implemented as C pointers, with no additional structure but
are treated as structs in Carp. To facilitate this, we need to add them
as a clause to our special type emissions (TypesToC) as they'd otherwise
be emitted like other struct types.
Co-authored-by: Veit Heller <veit@veitheller.de>
* fix: slight memory management fix for Box
Make sure we free the box!
* test: add tests for box (including memory checks)
* Revert "fix: Ignore clang nitpick"
This reverts commit 70ec6d46d4.
* fix: update example/functor.carp
Now that a builtin type named Box exists, the definitions in this file
cause a conflict. I've renamed the "Box" type in the functor example to
remove the conflict.
* feat: add Box.peek
Box.peek allows users to transform a reference to a box into a a
reference to the box's contained value. The returned reference will have
the same lifetime as the box. This function allows callers to manipulate
the value in a box without re-allocation, for example:
```clojure
(deftype Num [val Int])
(let-do [box (Box.init (Num.init 0))]
(Num.set-val! (Box.peek &box) 1)
@(Num.val (Box.peek &box)))
```
This commit also includes tests for Box.peek.
Co-authored-by: TimDeve <TimDeve@users.noreply.github.com>
Co-authored-by: Veit Heller <veit@veitheller.de>
Co-authored-by: Erik Svedäng <erik@coherence.io>
Co-authored-by: TimDeve <TimDeve@users.noreply.github.com>
Adds -c|--emitcname flag to headerparse to always emit the C identifier
in `register` definitions (useful when the register will be in a
module).
Fixes a bug where the kebab case flag would not output C identifiers
making the emitted C identifiers not match with the ones in the headers.
Adds docs entry about headerparse in CInterop doc.
Makes headerparse emit `CChar` instead of `Char` when encountering a
signature containing `char`.
Previously, the forms cast to the type Unit would still result in
variable assignment emissions, which produces invalid C.
Consider the case:
```clojure
;; type of System.exit is (Int -> a)
(defn main []
(the () (System.exit 0)))
```
This previously produced bad variable assignments. It now works as
expected and emits only the function call.
* Bug fix for #1064 and #843
Removes broken fix for #843 in Emit.hs, thus fixing #1064. And then
this commit focuses on fixing the memory management side of things,
so that we don't add deleters for symbols in the left-hand-side of
match case expressions if we are matching on a ref (e.g. using
match-ref).
* Add sumtype memory tests
* fix: Don't pass 'If' to InvalidObj when Obj actually is 'Mod'
* fix: Better error message
* fix: Better error
* fix: Show the name of the module in the error message
* fix: Use `root` to get correct location for InvalidObj error
* fix: keep old xobj for now
* fix: don't instantiate dummy fields for external types
For ANSI C compatibility reasons, we add a dummy field for memberless
types defined in Carp (see commit 59ef5bbf2b). When registering a type
with no fields, `(register-type A [])`, we'd also attempt to set our
dummy field in the Carp generated initializer for the type. However, the
registered type is totally opaque from the perspective of Carp, and we
can't assume it has a field corresponding to our dummy field.
This commit changes our handling of __dummy in initializers to avoid
setting it for registered types.
* feat: automatically implement str and prn for registered types
This commit makes the auto-generated str and prn functions for
registered types implement the str and prn interfaces, removing the need
for users to call implements on these functions explicitly.
It alters the signature of `autoDerive` in Primitives.hs slightly to
make it more flexible (since registered types have no delete or copy
functions that we can add to the implementation lists of these
interfaces).
* docs: add docs on register-type to CInterop.md
The new documentation clarifies the usage of `register-type` and accounts
for the changes in the prior two commits.
* fix: fix function signatures for generic memberless initers
Filter out dummy field arguments.
* docs: Add details about type name overrides to CInterop.md
* docs: clarify that users can implement delete for registered types
This commit builds on the emit-c feature by permitting C typed values to
be used anywhere in Carp code.
For example, if one wants to use the literal C macro `EDOM`:
```clojure
(register EDOM C "EDOM")
(Int.+ 1 EDOM)
=> 34
```
when compiled, this will produce the call:
```c
Int__PLUS(1, EDOM)
```
So it provides a quite flexible means of using C macros directly. It is,
of course, also radically unsafe. Anyone registering and using values of
the C type better be cautious.
One can get pretty crazy with this feature:
```clojure
(register comment-it C "// commented out;")
(Int.+ 1 comment-it)
=> int _11 = Int__PLUS_(1, // commented out;)
int* _12 = &_11; // ref
String _13 = IntRef_str(_12);
```
This commit fixes issue #1302, whereby types defined in modules were not
recognized as valid member types by our validation routines.
We simply need to account for types defined in modules in the global
env, threading the global env along through validation (previously we
only passed the top-level type env, which contains no modules).
A call to sequence in our handling of polymorphics would result in
discarding legitimate interface implementation results in rare cases.
Calling rights instead fixes the issue. We also need to take the union
of the results to ensure we account for cases such as polymorphically
realized interfaces (e.g. the `prn` function for a (Maybe String), other
wise, we don't resolve to concrete polymorphics for types that have
ad hoc polymorphic members.
Fixes#1307
* refactor: refactor concretize module
This commit primarily refactors the concretize module, breaking out the
local definitions for visit functions into top level functions that are
hopefully easier to change. I've also modified some monadic code in the
interest of terseness.
This commit adds some additional patterns for XObj forms as well.
* refactor: Only export called functions in Concretize
Adds an export list to Concretize so that the module encapsulates those
functions that are only used internally within the module.
* refactor: better names in concretize functions
Clarify the names of variables in visitor type functions.
* refactor: ensure findType returns a type
Adds an additional check to findType that ensures the retrieved binder
is in fact a type and not another object. This is necessary for certain
contexts like type concretization since modules may also be designated
by symbols that refer to types.
* fix: ensure nested polymorphic types are emitted
This commit fixes an issue whereby nested polymorphic types would not be
emitted by the compiler, even though their member functions were
emitted.
In order to support this, we need to update a couple of functions to
take the global environment (to find nested types, which live in
modules) in addition to the top level type environment. Additionally, we
had to update scoring to account for nested names.
fixes#1293
* test: add tests for nested polymorphic types
Adds regression tests to ensure nested polymorphic types are concretized
and emitted correctly.
* refactor: refactor concretize module
This commit primarily refactors the concretize module, breaking out the
local definitions for visit functions into top level functions that are
hopefully easier to change. I've also modified some monadic code in the
interest of terseness.
This commit adds some additional patterns for XObj forms as well.
* refactor: Only export called functions in Concretize
Adds an export list to Concretize so that the module encapsulates those
functions that are only used internally within the module.
* refactor: better names in concretize functions
Clarify the names of variables in visitor type functions.
Previously, there was an edge case whereby types that depended on other
types that were not scored yet and functions that in turn depended on
these types could be assigned the same score. When this happened, we'd
sometimes incorrectly emit functions before the struct types they
depended on.
Since functions are always at the bottom of a type hierarchy (they
always depend on their members), there's a simple fix: we just add 1 to
ensure functions are emitted after type declarations in all possible
cases.
* feat: add machine-info primitive draft
* feat: rename machine-info to structured-info
* fix: use the right primitive name in structured-info error
* refactor: remove unnecessary code
* refactor: Tiny cleanup before we begin
* refactor: Moved module finding to its own local function
* feat: save-docs-internal is now a binary command
* feat: This seems to work
* fix: Cleaned up the code, save-docs now emit one module per file listed
* refactor: Mid-refactor save point.
* feat: Code compiles
* refactor: Remove unused imports
* refactor: Move functions out of massive `manageMemory` block
* refactor: Move out even more functions from `manageMemory`
* refactor: Made most patterns match on "head form" of each s-expression
e.g. (if a b c) matches on 'if', 'a', 'b' and 'c'
* refactor: Use the pattern synonyms in Memory
* refactor: Remove a little cruft
* refactor: whenOK function
* refactor: Use 'whenRight' functions to avoid directly matching on Either
* docs: Comment the 'getConcretizedPath' function
* refactor: Move functionFinding-functions into Polymorphism module
* fix: render submodules in html docs
* fix: also render deeply nested modules
* feat: no prefixes in nested submodule doc rendering
* fix: fix text alignment of module index for sdl
* feat: make submodules expandable
The previous pattern matching changes introduced a subtle error in the
evaluator's handling of function applications, we used the same Resolver
for both lists and symbols, where previously we hadn't. Restoring the
old resolution selection and adding a new clause to capture forms like
((defn f [] 2)) restores the correct functioning in the repl.
Importantly, forms such as ((defn foo [x] x) 3), should only be resolved
when the defn form is the result of expanding a symbol.
Eventually, resolving defns to anonymous functions might simplify this
case.
Fixes#1237
* chore: Abuse deftemplate to get rid of Address
* chore: Avoid semicolon at end of define
* fix: address should be useable as an argument to a HOF
* chore: adapt examples to new address signature
* fix: Remove Address from typeOf
* fix: Remove more uses of Address
* fix: Remove more mentions of address in the Haskell code
* fix: Remove test that ensure you can't take the address of non-symbols
* refactor: Moved `address` to Pointer.carp
* refactor: Move address into Pointer module
Co-authored-by: Jorge Acereda <jacereda@gmail.com>
* chore: Re-format Haskell code
* fix: Unify aupdate and aupdate! with other update functions
* fix: Re-add comment
* fix: Also make StaticArray.aupdate! adhere to the normal update signature
* fix: Failing test
This fix is a close cousin of the one that allowed let bindings to
shadow global commands. We now allow function arguments to shadow
commands as well by using a local lookup preference for argument names,
making functions such as:
```
(defndynamic foo [car]
(Symbol.prefix car 'foo)
```
work as anticipated. I've also removed unused code from `apply`.
Fixes#1057
* fix: don't expand inner module macros on first pass; privacy
This commit changes the behavior of expansions to avoid expanding module
expressions until we're actually processing the module in question.
Previously, the following form would be entirely expanded at the time of evaluating A:
```clojure
(defmodule A <- current environment
(some-macro) <- expand
(defmodule B
(some-macro f) <- expand, current env is A, *NOT* B.
so if this expands to
(private f)
(defn f ....)
the f of the expansion is added to *A*, and we have a duplicate
ghost binder.
)
(defn foo [] B.f) <- expand, B.f does not exist yet, any meta on the
binding will be ignored, permitting privacy errors since expansion
ignores undefined bindings, instead, we'll look this up at eval time,
and not check privacy as doing so would cause problems for legitimate
cases.
)
```
This meant that if the macro happened to have side-effects, e.g. calling
`meta-set!` we'd produce side-effects in the wrong environment, A,
resulting in duplicate bindings, missing bindings at evaluation time,
and other problems.
Now, we instead process the form as follows:
```clojure
(defmodule A <- current environment
(some-macro) <- expand
(defmodule B
(some-macro f) <- wait
)
(defn foo [] B.f)
)
;; step 2
(defmodule A
(foo-bar ) <- previously expanded macro
(defmodule B <- current environment
(some-macro f) <- expand
)
....
)
```
In general, this prevents the generation of a bunch of unintentional and
incorrectly added bindings when calling `meta-set!` from various macros.
Additionally, privacy constraints are now carried across nested modules:
```
(defmodule A
(defmodule B
(private f)
(defn f [] 0)
)
(defn g [] (B.f)) ;; Privacy error!
)
```
This change also fixed an issue whereby recursive functions with `sig`
annotations could trick the compiler. Again, this had to do with the
unintentionally added bindings stemming from expansion of nested module
expressions via meta-set.
Fixes#1213, Fixes#467
* fix: ensure we check privacy against the path of found binders
* fix: don't shadow local bindings with dynamics
This commit adds a new lookup preference to the evaluator, LookupLocal,
and uses it to lookup bindings in the scope of let forms. This fixes an
issue whereby our original bias toward dynamic bindings would prevent
users from shadowing dynamic bindings with local bindings of the same
name. Before the following code returned `command c`:
```
(defdynamic test-val (let [c (car (list 1 2 3))]
c))
```
It now returns `1`.
I also fixed a small issue with top-level (as in, without a
corresponding function environment) let forms (they'd cause a crash for
lack of an environment parent).
Fixes#659
* refactor: only prefer local lookups for shadows
The prior commit introduced a local lookup preference into the evaluator
in order allow for shadowing of global names in local scopes (like let
bindings). However, this introduced prohibitive performance costs,
especially for dynamic functions.
To mitigate this, we only perform local-biased lookups for a set of
known-shadows. Since we know the names of local bindings at form
evaluation time, we can restrict our local lookup bias to these paths
only. This greatly reduces the performance penalties initially incurred
by the change.
I've also refactored some of the lookup code for clarity.
* fix: support recursive let bindings
Previously, the bodies of anonymous functions bound to a let name did
not have access to their names, making recursion such as:
```
(let [f (fn [x] (if (= x 1) x (f (dec x))))] (f 10))
```
impossible. We now equip evaluation of let bindings with an additional
recursion environment making this possible. The example above will now
resolve to `1`.
Fixes#1133
