Commit Graph

6 Commits

Author SHA1 Message Date
Scott Olsen
e1943b29a9
Refactor: clean up Env module, store type environments in modules (#1207)
* refactor: major environment mgmt refactor

This big refactor primarily changes two things in terms of behavior:

1. Stores a SymPath on concretely named (non-generic) struct types;
   before we stored a string.
2. The SymPath mentioned in (1.) designates where the struct is stored
   in the current environment chain. Modules now carry a local type
   environment in addition to their local value environments. Any types
   defined in the module are added to this environment rather than the
   global type environment.

To resolve a type such as `Foo.Bar` we now do the following:

- Search the *global value environment* for the Foo module.
- Get the type environment stored in the Foo module.
- Search for Bar in the Foo module's type environment.

Additionally, this commit eliminates the Lookup module entirely and
refactors the Env module to handle all aspects of environment management
in hopefully a more reusable fashion.

I also took the opportunity to refactor primitiveDeftype in Primitives
and qualifySym in Qualify, both of which were hefty functions that I
found difficult to grok and needed refactoring anyway as a result of
lookup changes (lookups now return an Either instead of a Maybe).

Subsequent commits will clean up and clarify this work further.

This does include one minor regression. Namely, an implementation of
`hash` in core/Color that was maximally generic now needs type casting.

* refactor: clean up recent Env changes

This commit removes some redundant functions, unifies some logic, and
renames some routines across the Env module in efforts to make it
cleaner. Call sites have been updated accordingly.

* chore: format code with ormolu

* fix: update lookup tests

Changes references to renamed functions in the Env module.

* refactor: style + additional improvements from eriksvedang@

- Rename arrayTy -> arrayTyA in ArrayTemplates.hs to disambiguate.
- Add maybeId util function.
- Remove commented code.
- Refactor a few functions for readability.

* fix: fix type inference regression

Recent commits introduced one minor regression whereby an instance of
type inference in core/Color.carp no longer worked and required
explicit type annotation. The problem ultimately had to do with
qualification:

- Prior to the recent changes, type inference worked because the call in
  question was qualified to Color.Id.get-tag, fixing the type.
- Failing to copy over a local envs Use modules to function envs
  resulted in finding more than just Color.Id.get-tag for this instance.

We now copy use modules over to function envs generated during
qualification to ensure we resolve to Use'd definitions before more
general cases.

Similarly, I made a small change to primitiveUse to support contextual
use calls (e.g. the `(use Id)` in Color.carp, which really means `(use
Color.Id)`)

* chore: Update some clarificatory comments

* chore: fix inline comment
2021-05-19 19:20:48 +02:00
jacereda
32d7396174
chore: Fix hlint warnings (#1086) 2020-12-22 17:44:44 +01:00
Scott Olsen
ee0aa59c28
Primitive refactors (#1070)
* refactor: move primitive errors; refactor primtiveInfo

This commit is the first in what will hopefully be a series of helpful
primitive refactors. To start, we:

- Move some inline `evalError` strings into a `PrimitiveError` module,
  (similar to the `TypeError`/`Types` module relationship
- Add `Reifiable` instances for String and Int types to take these
  types to their XObj representation.
- Add info utility functions for converting Info data to an XObj
- Refactor the `info` primitive:

  - Use monadic combinators + `maybe` instead of nested cases.
  - Use helper lookup functions that take a *context*--nearly *all*
    lookup calls currently extract some env, typically without doing
    anything to it, to pass it to lookup. This is a sign the boundary is
    incorrect and lookups should take the context instead--this will allow
    us to eliminate a ton of local `globalEnv`, `typeEnv`, etc. bindings.
  - Don't print hidden bindings
  - Indent printed meta information.
  - Color bindings blue

* chore: format code

* refactor: improve names for lookups that take a context

* feat: print hidden binders when calling info

Someone calling info might be interested in hidden binders as well, for
debugging purposes, etc. To enable this, we provide a version of show
for binders that prints hidden binders.

I've also made the printing of meta values in info more generic.
2020-12-15 21:38:55 +01:00
Erik Svedäng
7920a751bf
refactor: Apply Ormolu auto-formatting (#1045) 2020-12-02 16:33:37 +01:00
scottolsen
a5ffb1b841 Reify: Add Unit as a special case
Unit's show implementation defaults to the empty list `()`--this
presents problems when validating types, since generic type members are
replaced by the reification (a type literal) of their arguments. In the
`Unit` case, `()` yields some surprising invalid types.

So, we reify UnitTy as `Unit` instead to ensure consistency. This
permits using  Unit as a member in generic types like Result.
2020-11-19 15:15:35 -05:00
scottolsen
25839de02d Enhance type reflection; get types of values, get kinds
Extends Carp's support for type reflection by returning types for
values as well as bindings.

`type` now also returns a valid Carp expression/s-expression and so its
output can be used as input to dynamic functions and macros (prior to
this commit, `type` printed the type to the REPL but did not return a
meaningful expression in Carp).

Here are a few illustrations of the behavior:

```
(def x 1)
;; type now returns an s-expression/symbol
(type x)
=> Int
;; It also works on values
(type 1)
=> Int
(type 2b)
=> Byte
(type "foo")
=> (Ref String <StaticLifetime>)
;; It works on more complex values as well
(type Maybe)
=> Module
(type Maybe.Just)
(Fn [a] (Maybe a) <StaticLifetime>)
;; reports honestly about polymorphism
(type (Maybe.Nothing))
=> (Maybe a)
(type (Pair.init 1 2))
=> (Pair Int Int)
;; What about the type of types?
(type (type 2))
=> Type
;; Or the type of types of types?
(type (type (type 2)))
=> ()
;; One more time!
(type (type (type (type 2))))
=> ()
;; so, () is the fixpoint of type, and is reached after two applications
(type zero)
;; the type of an interface is all of its implementations
=> (((Fn [] (Array a) <StaticLifetime>) (Fn [] Bool <StaticLifetime>) (Fn
[] Byte <StaticLifetime>) (Fn [] Char <StaticLifetime>) (Fn [] Double
<StaticLifetime>) (Fn [] Float <StaticLifetime>) (Fn [] Int
<StaticLifetime>) (Fn [] Int16 <StaticLifetime>) (Fn [] Int32
<StaticLifetime>) (Fn [] Int64 <StaticLifetime>) (Fn [] Int8
<StaticLifetime>) (Fn [] Long <StaticLifetime>) (Fn [] (Maybe a)
<StaticLifetime>) (Fn [] (Pair a b) <StaticLifetime>) (Fn [] (Quadruple
a b c d) <StaticLifetime>) (Fn [] String <StaticLifetime>) (Fn []
(Triple a b c) <StaticLifetime>) (Fn [] Uint16 <StaticLifetime>) (Fn []
Uint32 <StaticLifetime>) (Fn [] Uint64 <StaticLifetime>) (Fn [] Uint8
<StaticLifetime>)))
```

As shown in the example above, this change also includes a cosmetic
update to the representation of lifetime variables, which are surrounded
in <> to distinguish them from type variables.

This commit also adds a new `kind` primitive that reports on the kind of
a binding or value:

```
(def x 3)
(kind x)
=> Base
(kind 2)
=> Base
(kind Maybe.Just)
=> Higher
(kind (Maybe.Just 2))
=> Higher
```

`kind` and `type` both support interactive development in the repl, for
example, a user can rely on `kind` to check the kind of a type they plan
on using in an interface that demands a higher-kinded argument.

Likewise, they both also support developing macros based on type
information.
2020-10-02 17:48:58 -04:00