Indexing from zero is consistent with the rest of Carp's indexing
behavior, so this should make the function more predictable. I've also
added a note to the docs about this.
with-copy better communicates that this macro will produce a function
that performs a copy--it doesn't cover the fact that it creates a
references to an anonymous function...but there's only so much we can
cover in a name.
I've also updated the documentation.
Like the previous two commits, this commit extends support for
reflection to yet another type, externally registered functions,
allowing us to support calls such as `(arity Int.+)`.
Just as the prior commit added support for capturing the arity of
registered commands, this one captures the arity of registered
primitives, enabling one to make calls such as `(arity defmacro)`, etc.
I have also moved the dummy argument name function into Util.hs since
it's used in both Commands.hs and Primitives.hs.
Previously, the command xobjs did not capture the arity of their
definitions. After this commit, they do, which enables us to surface
useful information about commands in reflective modules such as
core/Introspection.
Calls such as `(arity Dynamic.+)` and `(arity Dynamic.load)` will work
after this change.
It's a fairly common pattern in Carp to call a higher-order function on
some structure of values, such as an Array. However, these structures,
and their members, all have lifetimes under Carp's memory management
model, which means they expect functions that are mapped over them to
take *a reference to a value* rather than a pure value. Array.reduce is
one example of such a "referential" higher-order, the type of its
function argument is:
```
(Fn [a, (Ref b c)] a)
```
That is, this function takes some pure initial value, then expects to be
called against the members of an array, which are *references* to the
values that are alive throughout the Array's lifetime.
However, one often wants to use a function that operates on pure values
in such contexts, such as +, which forces the programmer to write
anonymous functions that handle copying referenced values to pass them
to the underlying "pure" function:
```
(Array.reduce &(fn [x y] (+ x @y)) 0 &[1 2 3])
```
So, in using some high-order function over some structure in Carp one
usually has to do two things:
1. Wrap the function in a ref
2. Handle copying references into values in order to pass them into some
simpler function that can also be used outside of memory-bound
contexts.
The `proxy` macro captures this pattern. It wraps a given function in a
referenced anonymous function and copies an argument of that function at
a designated position before calling the underlying function. For
example, with `proxy`, the above example becomes:
```
(Array.reduce (proxy + 2) 0 &[1 2 3])
```
The macro effectively gives a name to a common pattern--typically it
will only save the programmer a few characters, but it perhaps makes the
act of using a "function that doesn't care about references" in a
reference dominant context more apparent.
One can also use the macro to develop more specialized macros for
certain higher-orders, since these usually dictate where copying must be
performed. For instance, the `Array.reduce` function argument always
expects the referenced value to occur in the second position, thus one
could write:
```
(defmacro reducer [function] (eval (list proxy function 2)))
```
Then the above code becomes even simpler:
```
(Array.reducer (reducer +) 0 &[1 2 3])
```
Which roughly means, "use the + function (which has no concept of
references) in this reference dependent context".
N.B. The examples using `+` won't work as of now due to current bugs
related to calling `arity` directly on an interface--but a synonym for
plus `add` defined as an explicit function will make all the above work
as expected.
gensym-local is similar to gensym-with, with it's arguments reversed.
That is, rather than allowing the user to specify a custom qualifier, it
allows the user to specify a custom counter (or any symbol) and appends
this to the default gensym `gensym-generated` symbol.
This enables one to, e.g. map over an array and generate symbols:
```
(map gensym-local (map Symbol.from [1 2 3]))
=> (gensym-generated1 gensym-generated2 gensym-generated3)
```
Theoretically, passing `gensym` as-is to `map` would accomplish this
using the global gensym-counter, but the counter is not incremented on
subsequent calls. This function gives users more flexibility as well.
Even though `private?` has been around for a while, and we document the
behavior of `private` as marking a binding as private to a module--it
was never implemented as far as I can tell.
This implements private by adding a simple check to the evaluator. If a
binding is found in the global context, we check if it's marked as
private. If so, we inform the user that it can't be called from outside
of its module.
Note that we don't perform this check if the binding is found in the
internal env, since that means it's a function called within the same
module and thus is ok (even if marked as private).
After this change, something like the following works, granting us
proper encapsulation:
```
;; File Foo.carp
(deftype Foo [bar Int])
(private Foo.bar)
(defmodule Foo
(defn get [foo]
(Foo.bar foo))
)
;; Enter REPL
(load "Foo.carp")
(Foo.bar &(Foo.init 1))
The binding: Foo.bar is private; it may only be used within the module
that defines it. at REPL:1:2.
@(Foo.get &(Foo.init 1))
Compiled to 'out/Untitled' (executable)
1
=> 0
```
N.B. I also had to remove a private declaration from fmt-internal--this
declaration didn't really make much sense anyway, as fmt-internal is a
global function, so module-based privacy is not enforceable.
The opaque type is an uninhabited type with no constructors. Opaque can
be used to force some abstract type to range over a type constructor
without concerning oneself with the inhabitant of the constructor--in
other words, it may be used to enable a type to work for all inhabitants
and can express relationships between types. It can facillitate generic
programming.
Consider an example:
```
;; The type of indicies over containers of a single type argument
(deftype (Index (f Opaque) b) [at b])
(definterface tabulate (Fn [(Ref (Fn [(Index (f Opaque) b)] c))] (f c)))
(definterface positions (f (Index (f Opaque) b)))
(implements tabulate tabulate)
(defn tabulate [h]
(fmap h @&positions))
(deftype (Tuple a) [x a y a])
(defmodule Tuple
(sig positions (Tuple (Index (Tuple Opaque) Bool)))
(def positions (Tuple.init (Index.init true) (Index.init false)))
)
```
In the above example, the Opaque type allows us to define tabulate
generically defined over Tuples without having to ensure their
inhabitants match, allowing us to fully determine the resulting values
type via tabulate's function argument. Without Opaque, Index would
contain a generic type which would be unreseolved upon the call to
`tabulate`. It allows us to ensure the `positions` we call are the
positions of the correct constructor type `f` wihtout worrying having to
restrict ourselves to only calling `Indexes` over an `f` of a specific
type (e.g. `(f a)`)--in other words, it allows us to constrain
functions by constructor types only.
Thanks to Opaque, tabulate can generate an `(Array Int)`, `(Array
Bool)`, `(Array String)` all solely dependent on the return type of `h`.
Previously, introspecting an interface only returned `definterface` and
its name. We now return the form corresponding to the interface's types
signature, which enables us to introspect more effectively; e.g.
returning the appropriate arity of an interface.
Now that sigs work, turns out the signature for iterate-until and it's
definition don't match.
There was an extra argument in the sig, which I've removed. Adding a ref
to `result` also confused the type checker, since result technically has
two types in the definition whenever `b` is not a ref. I believe the
side effect of this change is that the `start` argument must now be a
`Ref`, but at least it's well-typed.
This is a work around for https://github.com/carp-lang/Carp/issues/776
the proper fix would be to allow range to take `(range 0 0 1)` inputs
but the decision about what the correct behavior should be hasn't been
made.
This change adds a new primitive Implements which changes interface
implementations from being implicit to being explicit. Going forward,
users will have to declare (implements <interface> <implementation>) to
explicitly add a function to an interface. This provides two benefits:
- Prevents unwitting name clashes. Previously, if one defined a function
that happened to have the same name as an interface, it was
automatically assumed the function implemented that interface when this
is not always the intention, especially in large programs.
- Name flexibility. One can now implement an interface with a function
that has a different name than the interface, which allows for greater
flexibility.
I've updated core to make the necessary calls to the new primitive.
Since str and copy are derived automatically for types, we treat these
functions as a special case and auto-implement the interfaces.
I accidentally broke `curry`, what better incentive for writing some
tests than preventing my own future silly mistakes :)
I also added and-internal because we cannot perform direct comparisons
on lists--so, instead we build member-wise comparisons by zipping, then
reduce the result using and.
I accidentally committed a change to the definition of curry that
severly alters how it functions! This commit fixed that, and adds a test
so that I don't unwittingly break it again :)
Originally, curry* required double quoting function arguments in some
cases, due to an eval and lack of quotes in the function body it
produces. This is not ideal, as having to type ''(form) is quite
esoteric. Now we handle the extra quoting in the function itself, so
that only one quote is required.
I also fixed the order of filter (which was reversing results).
