profile
viewpoint
Brendan Zabarauskas brendanzab @yeslogic Melbourne, Australia http://voyager3.tumblr.com I'm a poly-paradigm developer, primarily interested in how how type systems can be used as tools for thought. he/him 👨‍🎨👨‍💻👨‍🔬

brendanzab/codespan 322

Beautiful diagnostic reporting for text-based programming languages.

brendanzab/approx 82

Approximate floating point equality comparisons and assertions

brendanzab/algebra 53

Abstract algebra for Rust (still very much a WIP!)

brendanzab/color-rs 44

A library that provides types and conversions for working with various color formats.

brendanzab/chronicle 34

An event sourced CQRS framework for Rust

brendanzab/bullet-rs 9

Bindings and wrapper for the Bullet physics C API.

brendanzab/elm-stlc 7

Bidirectional type checker for the simply typed lambda calculus

brendanzab/Derelict3 2

A collection of dynamic D bindings to C libraries, useful for multimedia and game development.

brendanzab/efl-rs 2

Servo-specific wrapper for the relevant components of the Enlightenment Foundation Libraries.

brendanzab/elm-compiler 1

Compiler for the Elm programming language. Elm aims to make web development more pleasant. Elm is a type inferred, functional reactive language that compiles to HTML, CSS, and JavaScript.

startedj3-fortran/fortran_proposals

started time in an hour

startedconal/agda-cat-linear

started time in 5 hours

startedbanacorn/agda-mode-vscode

started time in 6 hours

startedGrokmoo/thyme

started time in 11 hours

PR opened yeslogic/fathom

Implement struct terms and eliminations

Closes #247.

+1188 -489

0 comment

80 changed files

pr created time in 11 hours

create barnchbrendanzab/fathom

branch : struct-terms

created branch time in 11 hours

issue openedyeslogic/fathom

Struct terms and eliminations

For example:

struct Point : Type {
    x : Int,
    y : Int,
}

origin : Point = struct {
    x = 0,
    y = 0,
};
origin_x = origin.x;
origin_x = origin.y;

created time in 11 hours

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha 0672dd0cc286279714f62de0bb512971c23b88af

Add some aspirational examples

view details

push time in 11 hours

delete branch brendanzab/fathom

delete branch : dependent-structs

delete time in 11 hours

delete branch brendanzab/fathom

delete branch : dependent-format-types

delete time in 11 hours

delete branch brendanzab/fathom

delete branch : host-structs

delete time in 11 hours

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha 7f414967606a0fc5eff264ead8c7617feece178d

Implement non-format struct types I had originally hard-coded the `struct` syntax to define struct formats. This changes it so that we now elaborate to either a struct type or a struct format in the core language depending on an annotation. Not supplying an annotation is an error.

view details

push time in 12 hours

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha e9265bfbfcf6272d580578f77d3cdc18823f8b12

WIP: Implement non-format struct types I had originally hard-coded the `struct` syntax to define struct formats. This changes it so that we now elaborate to either a struct type or a struct format in the core language depending on an annotation. Not supplying an annotation is an error.

view details

push time in 13 hours

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha 400dad83e2bd8e6da35338b6d483436f3a150d23

Remove unecessary colon

view details

Brendan Zabarauskas

commit sha 2313784df2eb2f8b0ad76046f3b85c1388882452

Rename failing tests appropriately These were marked as ‘fail_’ rather than ‘pass_’

view details

Brendan Zabarauskas

commit sha d7a9fb84d690f3394d4b30491a6d1f45d1ce1a38

Remove some unecessary tests These were leftover after removing the Rust backend (see a3547d7219c1890a15c149b8e588a62350421ab0), and are no longer really applicable.

view details

Brendan Zabarauskas

commit sha 846dead9c6039357d89b41477d10b043475d51f3

Fix annotation spacing in struct tests

view details

Brendan Zabarauskas

commit sha 4203b2cf65578ad0beece0ab89e88763a30153d7

WIP: Implement non-format struct types I had originally hard-coded the `struct` syntax to define struct formats. This changes it so that we now elaborate to either a struct type or a struct format in the core language depending on an annotation. Not supplying an annotation is an error.

view details

push time in 13 hours

startedtweag/nickel

started time in 19 hours

push eventpikelet-lang/pikelet

Brendan Zabarauskas

commit sha 8bf3edd38cca20a03237852a9159f7730d877b3a

Add TODO comments to REPL

view details

push time in a day

startedyizhouzhang/olaf-coq

started time in 2 days

delete branch brendanzab/pikelet

delete branch : mdbook-docs

delete time in 2 days

push eventpikelet-lang/pikelet

Brendan Zabarauskas

commit sha fa034af124ab504cb9b34a6fea6aec590d72d1fe

Move back to using mdBook for documantation mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for [preprocessors](https://rust-lang.github.io/mdBook/for_developers/preprocessors.html) which could be handy if we want to generated some sort of hyperlinked language specification.

view details

Brendan Zabarauskas

commit sha 04b2489c4868cf58bb7d09afc318f4a46f3bb3db

Merge pull request #232 from brendanzab/mdbook-docs Move back to using mdBook for documantation

view details

push time in 2 days

PR merged pikelet-lang/pikelet

Move back to using mdBook for documantation

mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for preprocessors which could be handy if we want to generated some sort of hyperlinked language specification.

+5778 -11374

0 comment

69 changed files

brendanzab

pr closed time in 2 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha fa034af124ab504cb9b34a6fea6aec590d72d1fe

Move back to using mdBook for documantation mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for [preprocessors](https://rust-lang.github.io/mdBook/for_developers/preprocessors.html) which could be handy if we want to generated some sort of hyperlinked language specification.

view details

push time in 2 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 15c3c0fe9b218244ca98b02e1974ae5eda95eeec

Move back to using mdBook for documantation mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for [preprocessors](https://rust-lang.github.io/mdBook/for_developers/preprocessors.html) which could be handy if we want to generated some sort of hyperlinked language specification.

view details

push time in 2 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 5c57642a12b190d47b6abbd2b4836105a2168fa6

Move back to using mdBook for documantation mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for [preprocessors](https://rust-lang.github.io/mdBook/for_developers/preprocessors.html) which could be handy if we want to generated some sort of hyperlinked language specification.

view details

push time in 2 days

startedztellman/rhizome

started time in 2 days

startedHoTT-Intro/Agda

started time in 2 days

startedmniip/ZF

started time in 2 days

startedjonsterling/dreamtt

started time in 3 days

startedjonsterling/dreamtt

started time in 3 days

startedranjitjhala/sprite-lang

started time in 3 days

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha f5e2918f42a1c4018aee7c162392f21c0d8b02f2

WIP: Implement struct types

view details

Brendan Zabarauskas

commit sha 7b2633cb7d80a2e379d58503242180d40080426d

WIP: Implement struct terms

view details

push time in 3 days

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha 252aa9bf5d94fd863a76129896733398ec7989d0

WIP: Implement struct types

view details

Brendan Zabarauskas

commit sha d6cf3fd82b83230f19475c6ae52ab38e29cf0eef

WIP: Implement struct terms

view details

push time in 3 days

startedrust-crdt/rust-crdt

started time in 3 days

Pull request review commentyeslogic/fathom

WIP: Implement struct types

 impl<'me> Context<'me> {                         None => self.synth_type(file_id, &alias.term),                     }; -                    // FIXME: Avoid shadowing builtin definitions-                    match self.items.entry(alias.name.data.clone()) {-                        Entry::Vacant(entry) => {-                            let item_data = core::ItemData::Alias(core::Alias {-                                doc: alias.doc.clone(),-                                name: alias.name.data.clone(),-                                term: Arc::new(core_term),-                            });+                    let item_data = core::ItemData::Alias(core::Alias {+                        doc: alias.doc.clone(),+                        name: alias.name.data.clone(),+                        term: Arc::new(core_term),+                    }); -                            let core_item = core::Item::new(item.range(), item_data);-                            core_items.push(core_item.clone());-                            self.types.push((entry.key().clone(), r#type));-                            entry.insert(core_item);-                        }-                        Entry::Occupied(entry) => {-                            let original_range = entry.get().range();-                            self.push_message(SurfaceToCoreMessage::ItemRedefinition {-                                file_id,-                                name: alias.name.data.clone(),-                                found_range: item.range.clone(),-                                original_range,-                            })-                        }-                    }+                    (&alias.name, item_data, r#type)                 }-                ItemData::Struct(struct_type) => {-                    // Field names that have previously seen, along with the source-                    // range where they were introduced (for diagnostic reporting).-                    let mut seen_field_names = HashMap::new();-                    // Fields that have been elaborated into the core syntax.-                    let mut core_fields = Vec::with_capacity(struct_type.fields.len());--                    for field in &struct_type.fields {-                        let field_range = field.name.range().start..field.term.range().end;-                        let format_type = Arc::new(Value::FormatType);-                        let r#type = self.check_type(file_id, &field.term, &format_type);--                        match seen_field_names.entry(field.name.data.clone()) {-                            Entry::Vacant(entry) => {-                                core_fields.push(core::TypeField {-                                    doc: field.doc.clone(),-                                    name: field.name.data.clone(),-                                    term: Arc::new(r#type),-                                });--                                entry.insert(field_range);-                            }-                            Entry::Occupied(entry) => {-                                self.push_message(SurfaceToCoreMessage::FieldRedeclaration {-                                    file_id,-                                    name: entry.key().clone(),-                                    found_range: field_range,-                                    original_range: entry.get().clone(),-                                });-                            }-                        }-                    }+                ItemData::StructType(struct_type) => {+                    let (_, r#type) = self.synth_type(file_id, &struct_type.type_);+                    let item_data = match r#type.as_ref() {+                        Value::Sort(Sort::Type) => self.is_struct_type(file_id, struct_type),+                        Value::FormatType => self.is_struct_format(file_id, struct_type),+                        r#type => todo!("expected Type or Format"),

Need a proper diagnostic here.

brendanzab

comment created time in 3 days

PullRequestReviewEvent

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha 4406e2993194784ae85ae3aaa1ca8669a46622d5

WIP: Implement struct types

view details

Brendan Zabarauskas

commit sha ea3238f5e01196f4e657383d7474545a898d56e5

WIP: Implement struct terms

view details

push time in 4 days

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha c86e099cf67baebff1dee07f3d133c3013b048d3

WIP: Implement struct types

view details

Brendan Zabarauskas

commit sha c8b3ec0a8f61380ddb183babeff9839c97185db6

WIP: Implement struct terms

view details

push time in 4 days

push eventbrendanzab/fathom

Brendan Zabarauskas

commit sha 603e6ff2134dc67e3af3fde06504347651a4c255

WIP: Implement struct types

view details

Brendan Zabarauskas

commit sha 7f9fb51828620c8c9e20fb7f45e08571fc9dd1e0

WIP: Implement struct terms

view details

push time in 4 days

PR opened yeslogic/fathom

Add some aspirational examples
+124 -0

0 comment

4 changed files

pr created time in 4 days

create barnchbrendanzab/fathom

branch : examples

created branch time in 4 days

PR opened yeslogic/fathom

WIP: Implement struct types

This makes a distinction between struct types and struct formats in the core language. Originally we only supported formats.

Posting this as a WIP… got some work to do though.

  • [ ] Elaborate struct terms
  • [ ] Tests
  • [ ] Diagnostics
  • [ ] Evaluation rules
+454 -206

0 comment

52 changed files

pr created time in 5 days

create barnchbrendanzab/fathom

branch : struct-types

created branch time in 5 days

startedvrahli/NuprlInCoq

started time in 5 days

startedDreamLinuxer/FracAncilla

started time in 6 days

startedzetzit/zz

started time in 6 days

issue commentbrendanzab/approx

Support for slices?

Ahh - once we have const generics we can implement it for fixed size arrays. We could also do what the standard library used to do and implement the traits for fixed size arrays of length 0 to 32. In the mean time you might be able to do:

assert_abs_diff_eq!([1.0, 2.0, 3.0].as_ref(), [1.0, 2.0, 3.0].as_ref());

This converts both sides to `&[{float}].

bluenote10

comment created time in 7 days

startedzserge/awfice

started time in 7 days

startedtrikita/slide-html

started time in 7 days

startedBlaisorblade/dot-iris

started time in 7 days

startedAirblader/i3

started time in 7 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 5893c85bcfb91cb6c351e28c1cf4da88887d0c7a

WIP: Move back to using mdBook for documantation mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for [preprocessors](https://rust-lang.github.io/mdBook/for_developers/preprocessors.html) which could be handy if we want to generated some sort of hyperlinked language specification.

view details

push time in 7 days

issue commentbrendanzab/approx

Support for slices?

Yeah, this seems like it would be really useful!

bluenote10

comment created time in 8 days

starteddtolnay/paste

started time in 8 days

issue openedMichael-F-Bryan/mdbook-linkcheck

"Potential incomplete link" warnings generated for checklists

I get the following warning when I run mdbook-linkcheck on a markdown file with a checklist:

warning: Potential incomplete link
   ┌─ development/roadmap.md:19:5
   │
19 │   - [x] Comments
   │     ^^^ Did you forget to define a URL for `x`?
   │
   = hint: declare the link's URL. For example: `[x]: http://example.com/`

It seems to be fine with unchecked list items, eg: - [ ] Blah.

created time in 8 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 55aea6040b59b17682a60a4d25c20da196a72f32

WIP: Move back to using mdBook for documantation mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for [preprocessors](https://rust-lang.github.io/mdBook/for_developers/preprocessors.html) which could be handy if we want to generated some sort of hyperlinked language specification.

view details

push time in 8 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 84cff643d627b91e22cc24424bbeaafb9e21f03b

WIP: Move back to using mdBook for documantation mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for [preprocessors](https://rust-lang.github.io/mdBook/for_developers/preprocessors.html) which could be handy if we want to generated some sort of hyperlinked language specification.

view details

push time in 8 days

PR opened pikelet-lang/pikelet

WIP: Move back to using mdBook for documantation

mdBook seems somewhat simpler and more lightweight than Docusaurus, so I’m thinking it might just be good to go with it for now! It also has support for preprocessors which could be handy if we want to generated some sort of hyperlinked language specification.

+561 -528

0 comment

44 changed files

pr created time in 8 days

create barnchbrendanzab/pikelet

branch : mdbook-docs

created branch time in 8 days

startedmsp-strath/ask

started time in 9 days

startedrobrix/silkscreen

started time in 9 days

pull request commentpikelet-lang/pikelet

Allow dependencies between record term elements

So yeah, I think I'm understanding the issue now - it's just I found the previous examples didn't capture this.

The problem is that some annotations in let bindings need to access the contents of a definition in order to be able to be considered valid types. Even before checking the body of the definition. Splitting the definitions from the typing annotations as is done when desugaring let expressions to records means that the typing annotations can no longer access the definitions. This reduces what you can express with let bindings, unless you can figure out some way to expose the definitions of fields in the record types, which is what the linked resources you mentioned in your original comment address.

brendanzab

comment created time in 9 days

pull request commentpikelet-lang/pikelet

Allow dependencies between record term elements

Or maybe I need some example where refl : Id A a true is used in some part of an annotation. So that in order for the annotation to be a valid type, you'd need to know the definition of a?

brendanzab

comment created time in 9 days

pull request commentpikelet-lang/pikelet

Allow dependencies between record term elements

So the Id A a true needs the definition of a in the type, but it's not - it's been split off into the record constructor expression:

(record {
    A = Bool,
    a = true,
    p = refl,
    body = p,
} : Record {
    A : Type,
    a : A,
    p : Id A a true,
    body : Id A a true,
}).body

I guess I'm still a bit confused because even so, by the time you are checking the field p = refl with the goal Id A a true, don't you have the following in the context:

  • A : Type = Bool
  • a : A = true

The same would go for the field body = f with the goal Id A a true, where you have the following in the context:

  • A : Type = Bool
  • a : A = true
  • p : Id A a true = refl

Or should I not be adding the definitions to the context when checking record constructor expressions like this? Sorry for my slowness - still getting to grips with dependent types!

brendanzab

comment created time in 9 days

pull request commentpikelet-lang/pikelet

Allow dependencies between record term elements

Ah yeah, in the original statement I was referring to elaborating to 'record terms' - ie. 'record constructor expressions' - not record types. 😅 Taking into account the extended scoping rules would elaborating let expressions into record constructors + projection be possible? Ie.

let {
    A : Type = Bool
    f : A -> A = not
} in f True

would be elaborated to:

(record {
    A = Bool,
    f = not,
    body = f true,
} : Record {
    A : Type,
    f : A -> A,
    body : Bool,
}).body
brendanzab

comment created time in 9 days

pull request commentpikelet-lang/pikelet

Allow dependencies between record term elements

Ah dang, that's disappointing! Yeah I had remembered that it was an issue for doing it with the function application style, but for some reason had thought I might be able to get away with it for records. Thanks for the pointers to the relevant information!

So should I be concerned if something like this type checks and runs fine in my language?

(record {
    A = Bool,
    f = fun a => a,
    body = f true,
} : Record {
    A : Type,
    f : A -> A,
    body : Bool,
}).body
brendanzab

comment created time in 9 days

pull request commentpikelet-lang/pikelet

Unfold escaping levels when reading back values

Note that the naive patch-job of an escape check in this PR doesn't actually solve the issue when other bindings are in scope, echoing what Andras was talking about before. For example in the prelude.pi example I get:

error: mismatched types
  ┌─ examples/prelude.pi:7:42
  │
7 │     compose = fun A B C => dep-compose A (always B) (always (always C)),
  │                                          ^^^^^^^^^^ expected `Fun (t : dep-compose) -> Type`, found `Fun (B-1 : Type) -> Fun (t : always) -> Fun (t-1 : dep-compose) -> always`

Here the type of always B is misbound due to local bindings being present in the record term. Ie. the input type points to dep-compose, rather than B.

brendanzab

comment created time in 9 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 3232101455783cbbef3d079997af8bba6b7f87f7

Allow dependencies between record term elements This allows the elements of record terms to depend on each other. For example, this expression is now valid: ``` record { x = 1, y = x } : Record { x : S32, y : S32 } ``` This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term: ``` record { Elem = String, elem = record {}, } : Record { Elem : Type, elem : Elem, } ``` This is because `Elem` is not bound in the record term! Now we render the following error: ``` error: mismatched types ┌─ examples/escaping-local.pi:3:12 │ 3 │ elem = record {}, │ ^^^^^^^^^ expected `String`, found `Record {}` ``` This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in [1ML]. For example: ``` let { x : S32 = 1, y : S32 = x * 2, } in y - x ``` Could be sugar for: ``` (record { x = 1, y = x * 2, body = y - x } : Record { x : S32, y : S32, body : S32 }) .body ``` [1ML]: http://mpi-sws.org/~rossberg/1ml/ This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax. It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid: ``` record { y = 1, x = 2 } : Record { x : S32, y : S32 } ``` I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

view details

Brendan Zabarauskas

commit sha ef8ae350840a3a64c3a4418ca612180959463b7b

Merge pull request #230 from brendanzab/record-term-bindings Allow dependencies between record term elements

view details

Brendan Zabarauskas

commit sha 19c2aa66de9b97b6d5468c0e62e6e413babf23d0

Improve variant names for Unfold type

view details

Brendan Zabarauskas

commit sha 129adc3d871892fcec34e77f8f9cd9a146658c2b

Improve docs for stuck and unstuck values

view details

Brendan Zabarauskas

commit sha cdd94c11c17e17023432b70c28f901bc400e63dc

Improve function naming

view details

Brendan Zabarauskas

commit sha ac3a977a4460a9c08ddc40d071bf50733ffbe48f

Formatting improvements

view details

Brendan Zabarauskas

commit sha 7498d2df333be12c4eae7a39917d3ded0ddc2e85

Merge pull request #231 from brendanzab/semantics-cleanups Various cleanups to the semantics module

view details

Brendan Zabarauskas

commit sha a019de7e626e4919113a10c51fcb4045498a23f3

Unfold escaping levels when reading back values

view details

push time in 9 days

Pull request review commentpikelet-lang/pikelet

Allow dependencies between record term elements

 record {     id = fun A a => a,     always = fun A B a b => a,-    compose = fun A B C a-b b-c a => b-c (a-b a),+     dep-compose = fun A B C a-b a-b-c a => a-b-c a (a-b a),-    flip = fun A B C a-b-c a b => a-b-c b a,+    compose = fun A B C a-b b-c a => b-c (a-b a),+    -- FIXME: Variable binding bug+    -- compose = fun A B C => dep-compose A (fun a => B) (fun a b => C),+    -- compose = fun A B C => dep-compose A (always B) (always (always C)),

I've posted more details here: https://github.com/pikelet-lang/pikelet/pull/229#issuecomment-706497438

brendanzab

comment created time in 9 days

PullRequestReviewEvent

create barnchbrendanzab/pikelet

branch : unfold-escaping-locals

created branch time in 9 days

pull request commentpikelet-lang/pikelet

Unfold escaping levels when reading back values

Hmm, I'm actually running into escaping locals in the types of function eliminations as well! This seems to be the source of the bug found in https://github.com/pikelet-lang/pikelet/pull/230#discussion_r502153985. For example, given the following function:

(fun A a => a : Fun (A : Type) -> A -> A) S32

I'd expect to synthesize S32 -> S32. But instead I synthesize the following type:

FunctionType(
    Unstuck(
        Local(LocalLevel(0)),
        [],
        LazyValue(OnceCell(
            Stuck(Global("S32", UniverseOffset(0)), []),
        )),
    ),
    Closure {
        universe_offset: UniverseOffset(0),
        values: Locals[
            Stuck(Global("S32", UniverseOffset(0)), []),
        ],
        term: Local(LocalIndex(1)),
    },
)

Note the escaping level, Local(LocalLevel(0)), in the annotation of the function type. This was bound when I applied the S32 to the ⟨[], A -> A⟩ closure, but is now no longer present!

brendanzab

comment created time in 9 days

delete branch brendanzab/pikelet

delete branch : semantics-cleanups

delete time in 10 days

push eventpikelet-lang/pikelet

Brendan Zabarauskas

commit sha 19c2aa66de9b97b6d5468c0e62e6e413babf23d0

Improve variant names for Unfold type

view details

Brendan Zabarauskas

commit sha 129adc3d871892fcec34e77f8f9cd9a146658c2b

Improve docs for stuck and unstuck values

view details

Brendan Zabarauskas

commit sha cdd94c11c17e17023432b70c28f901bc400e63dc

Improve function naming

view details

Brendan Zabarauskas

commit sha ac3a977a4460a9c08ddc40d071bf50733ffbe48f

Formatting improvements

view details

Brendan Zabarauskas

commit sha 7498d2df333be12c4eae7a39917d3ded0ddc2e85

Merge pull request #231 from brendanzab/semantics-cleanups Various cleanups to the semantics module

view details

push time in 10 days

PR opened pikelet-lang/pikelet

Various cleanups to the semantics module
+18736 -16379

0 comment

195 changed files

pr created time in 10 days

create barnchbrendanzab/pikelet

branch : semantics-cleanups

created branch time in 10 days

delete branch brendanzab/pikelet

delete branch : unfold-escaping-locals

delete time in 10 days

PR closed pikelet-lang/pikelet

Unfold escaping levels when reading back values

This occurs because we are attempting to use ‘glued evaluation’ for local variables, not just top-level definitions. For example we run into a runtime panic when trying to print an error message for the following term:

record {
    Elem = String,
    elem = record {},
} : Record {
    Elem : Type,
    elem : Elem,
}

We'd like to render an error message for record {} which is expected to be of type String. The type we are checking against is:

Value::Unstuck(Head::Local(LocalLevel(0)), [], Value::Stuck(Head::Global("String"), []))

So we'd assume we could render an error like:

error: mismatched types
  ┌─ examples/escaping-local.pi:3:12
  │
3 │     elem = record {},
  │            ^^^^^^^^^ expected `Elem`, found `Record {}`

But instead we actually get an unwrap panic in read_back_spine with Unfold::None because LocalLevel(0) is bound in the record type, but not in record term itself.

To remedy this we now check that the level is valid relative to the environment size, and unfolding if not. This results in the following error message (note that we now render String instead of attempting to render the original binding):

error: mismatched types
  ┌─ examples/escaping-local.pi:3:12
  │
3 │     elem = record {},
  │            ^^^^^^^^^ expected `String`, found `Record {}`

I fear this might be a band-aid solution however. We might need to use fresh ids for local variables in values instead of levels (like in Sixty does), in order to be absolutely sure that we don't accidentally compare variable that originate from different scopes.

+65 -23

9 comments

3 changed files

brendanzab

pr closed time in 10 days

pull request commentpikelet-lang/pikelet

Unfold escaping levels when reading back values

Closed by #230, which implements @AndrasKovacs' suggestion. 😃

brendanzab

comment created time in 10 days

delete branch brendanzab/pikelet

delete branch : record-term-bindings

delete time in 10 days

push eventpikelet-lang/pikelet

Brendan Zabarauskas

commit sha 3232101455783cbbef3d079997af8bba6b7f87f7

Allow dependencies between record term elements This allows the elements of record terms to depend on each other. For example, this expression is now valid: ``` record { x = 1, y = x } : Record { x : S32, y : S32 } ``` This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term: ``` record { Elem = String, elem = record {}, } : Record { Elem : Type, elem : Elem, } ``` This is because `Elem` is not bound in the record term! Now we render the following error: ``` error: mismatched types ┌─ examples/escaping-local.pi:3:12 │ 3 │ elem = record {}, │ ^^^^^^^^^ expected `String`, found `Record {}` ``` This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in [1ML]. For example: ``` let { x : S32 = 1, y : S32 = x * 2, } in y - x ``` Could be sugar for: ``` (record { x = 1, y = x * 2, body = y - x } : Record { x : S32, y : S32, body : S32 }) .body ``` [1ML]: http://mpi-sws.org/~rossberg/1ml/ This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax. It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid: ``` record { y = 1, x = 2 } : Record { x : S32, y : S32 } ``` I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

view details

Brendan Zabarauskas

commit sha ef8ae350840a3a64c3a4418ca612180959463b7b

Merge pull request #230 from brendanzab/record-term-bindings Allow dependencies between record term elements

view details

push time in 10 days

PR merged pikelet-lang/pikelet

Allow dependencies between record term elements

This allows the elements of record terms to depend on each other. For example, this expression is now valid:

record { x = 1, y = x }
    : Record { x : S32, y : S32 }

This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term:

record {
    Elem = String,
    elem = record {},
} : Record {
    Elem : Type,
    elem : Elem,
}

This is because Elem is not bound in the record term!

Now we render the following error:

error: mismatched types
  ┌─ examples/escaping-local.pi:3:12
  │
3 │     elem = record {},
  │            ^^^^^^^^^ expected `String`, found `Record {}`

This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in 1ML. For example:

let {
    x : S32 = 1,
    y : S32 = x * 2,
} in y - x

Could be sugar for:

(record { x = 1, y = x * 2, body = y - x }
    : Record { x : S32, y : S32, body : S32 })
        .body

This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax.

It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid:

record { y = 1, x = 2 }
    : Record { x : S32, y : S32 }

I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

Closes #229.

+373 -236

0 comment

16 changed files

brendanzab

pr closed time in 10 days

issue commentyeslogic/fathom

Command-line interface

I'd imagine that eventually you might be able to encode and decode formats from this mode, and maybe step through how data is decoded interactively? But that's more thinking long term.

mikeday

comment created time in 10 days

issue commentyeslogic/fathom

Command-line interface

I was considering switching to pikelet interactive though, in my quest to remove confusing acronyms 😅

mikeday

comment created time in 10 days

issue commentyeslogic/fathom

Command-line interface

I just have it as a subcommand in Pikelet, ie. pikelet repl. Could be handy for quickly checking things? It's not too difficult to implement a rudimentary one. Here's how I do it in Pikelet: https://github.com/pikelet-lang/pikelet/blob/next/pikelet-cli/src/repl.rs

mikeday

comment created time in 10 days

issue openedyeslogic/fathom

Dependent record formats and record types

This will allow dependent record formats to have field dependencies, which correspond to how records are parsed in a binary format. For example:

Points : Format = {
    len : U32Be,
    data : FormatArray len { x : U32Be, y U32Be },
};

Note that len is bound as len : Repr U32Be in the typing context.

Unlike DDC we aim to preserve as much dependency information in the host language as possible. To that end Repr will interpret dependent record formats into dependent record types (as opposed to a non-dependent records).

created time in 10 days

issue openedyeslogic/fathom

Built-in 'Repr' function

This converts binary format descriptions into their host representation types. This will be important once we want to implement dependent record formats.

Initially this would correspond with the following implementation:

Repr : Format -> Type
Repr U8     = Int
Repr U16Le  = Int
Repr U16Be  = Int
Repr U32Le  = Int
Repr U32Be  = Int
Repr U64Le  = Int
Repr U64Be  = Int
Repr S8     = Int
Repr S16Le  = Int
Repr S16Be  = Int
Repr S32Le  = Int
Repr S32Be  = Int
Repr S64Le  = Int
Repr S64Be  = Int
Repr F32Le  = F32
Repr F32Be  = F32
Repr F64Le  = F64
Repr F64Be  = F64
Repr { l₀ : t₀, ... lₙ : tₙ } 
            = { l₀ : Repr t₀, ... lₙ : Repr tₙ }

For example:

Point : Format = {
    x : S32Be,
    y : S32Be,
};

origin : Repr Point = {
    x = 0,
    y = 0,
};

created time in 10 days

issue openedyeslogic/fathom

Non-dependent structural record types and terms

For example:

Point : Type = {
    x : Int,
    y : Int,
};

origin : Point = {
    x = 0,
    y = 0,
};

created time in 11 days

issue openedyeslogic/fathom

Non-dependent structural record formats

For example:

Point : Format = {
    x : S32Be,
    y : S32Be,
};

created time in 11 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 3232101455783cbbef3d079997af8bba6b7f87f7

Allow dependencies between record term elements This allows the elements of record terms to depend on each other. For example, this expression is now valid: ``` record { x = 1, y = x } : Record { x : S32, y : S32 } ``` This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term: ``` record { Elem = String, elem = record {}, } : Record { Elem : Type, elem : Elem, } ``` This is because `Elem` is not bound in the record term! Now we render the following error: ``` error: mismatched types ┌─ examples/escaping-local.pi:3:12 │ 3 │ elem = record {}, │ ^^^^^^^^^ expected `String`, found `Record {}` ``` This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in [1ML]. For example: ``` let { x : S32 = 1, y : S32 = x * 2, } in y - x ``` Could be sugar for: ``` (record { x = 1, y = x * 2, body = y - x } : Record { x : S32, y : S32, body : S32 }) .body ``` [1ML]: http://mpi-sws.org/~rossberg/1ml/ This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax. It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid: ``` record { y = 1, x = 2 } : Record { x : S32, y : S32 } ``` I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

view details

push time in 11 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha b8c9bb7d01211c98e4d67e0532d4c1b241032743

Allow dependencies between record term elements This allows the elements of record terms to depend on each other. For example, this expression is now valid: ``` record { x = 1, y = x } : Record { x : S32, y : S32 } ``` This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term: ``` record { Elem = String, elem = record {}, } : Record { Elem : Type, elem : Elem, } ``` This is because `Elem` is not bound in the record term! Now we render the following error: ``` error: mismatched types ┌─ examples/escaping-local.pi:3:12 │ 3 │ elem = record {}, │ ^^^^^^^^^ expected `String`, found `Record {}` ``` This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in [1ML]. For example: ``` let { x : S32 = 1, y : S32 = x * 2, } in y - x ``` Could be sugar for: ``` (record { x = 1, y = x * 2, body = y - x } : Record { x : S32, y : S32, body : S32 }) .body ``` [1ML]: http://mpi-sws.org/~rossberg/1ml/ This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax. It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid: ``` record { y = 1, x = 2 } : Record { x : S32, y : S32 } ``` I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

view details

push time in 11 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha d7ab59c45930986be41b064fed4fe4697a281414

Allow dependencies between record term elements This allows the elements of record terms to depend on each other. For example, this expression is now valid: ``` record { x = 1, y = x } : Record { x : S32, y : S32 } ``` This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term: ``` record { Elem = String, elem = record {}, } : Record { Elem : Type, elem : Elem, } ``` This is because `Elem` is not bound in the record term! Now we render the following error: ``` error: mismatched types ┌─ examples/escaping-local.pi:3:12 │ 3 │ elem = record {}, │ ^^^^^^^^^ expected `String`, found `Record {}` ``` This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in [1ML]. For example: ``` let { x : S32 = 1, y : S32 = x * 2, } in y - x ``` Could be sugar for: ``` (record { x = 1, y = x * 2, body = y - x } : Record { x : S32, y : S32, body : S32 }) .body ``` [1ML]: http://mpi-sws.org/~rossberg/1ml/ This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax. It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid: ``` record { y = 1, x = 2 } : Record { x : S32, y : S32 } ``` I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

view details

push time in 11 days

Pull request review commentpikelet-lang/pikelet

Allow dependencies between record term elements

 record {     id = fun A a => a,     always = fun A B a b => a,-    compose = fun A B C a-b b-c a => b-c (a-b a),+     dep-compose = fun A B C a-b a-b-c a => a-b-c a (a-b a),-    flip = fun A B C a-b-c a b => a-b-c b a,+    compose = fun A B C a-b b-c a => b-c (a-b a),+    -- FIXME: Variable binding bug+    -- compose = fun A B C => dep-compose A (fun a => B) (fun a b => C),+    -- compose = fun A B C => dep-compose A (always B) (always (always C)),

This uncovered a variable binding bug that was added in 1afb4761667825afb5b380534392f4450194addd - serves me right for not having a more comprehensive test suite! 🤦‍♂️

It means that dependent functions are completely broken:

> (fun A a => a : Fun (A : Type) -> A -> A)
fun A a => a : Fun (A : Type) -> Fun (t : A) -> A
> (fun A a => a : Fun (A : Type) -> A -> A) S32
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', pikelet/src/lang/core/semantics.rs:481:52

I'll have to track this down in a later PR, but for now I've commented this stuff out.

brendanzab

comment created time in 11 days

PullRequestReviewEvent

PR opened pikelet-lang/pikelet

Allow dependencies between record term elements

This allows the elements of record terms to depend on each other. For example, this expression is now valid:

record { x = 1, y = x }
    : Record { x : S32, y : S32 }

This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term:

record {
    Elem = String,
    elem = record {},
} : Record {
    Elem : Type,
    elem : Elem,
}

This is because Elem is not bound in the record term!

Now we render the following error:

error: mismatched types
  ┌─ examples/escaping-local.pi:3:12
  │
3 │     elem = record {},
  │            ^^^^^^^^^ expected `String`, found `Record {}`

This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in 1ML. For example:

let {
    x : S32 = 1,
    y : S32 = x * 2,
} in y - x

Could be sugar for:

(record { x = 1, y = x * 2, body = y - x }
    : Record { x : S32, y : S32, body : S32 })
        .body

This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax.

It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid:

record { y = 1, x = 2 }
    : Record { x : S32, y : S32 }

I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

+320 -213

0 comment

16 changed files

pr created time in 11 days

push eventbrendanzab/pikelet

Brendan Zabarauskas

commit sha 9a1fbe25ec43d513834fe50d7aa872c8ffcd7d9b

Allow dependencies between record term elements This allows the elements of record terms to depend on each other. For example, this expression is now valid: ``` record { x = 1, y = x } : Record { x : S32, y : S32 } ``` This has the helpful side-effect of fixing the scoping glued levels in record terms. Before this change we would trigger a runtime panic on rendering the error message for the following term: ``` record { Elem = String, elem = record {}, } : Record { Elem : Type, elem : Elem, } ``` This is because `Elem` is not bound in the record term! Now we render the following error: ``` error: mismatched types ┌─ examples/escaping-local.pi:3:12 │ 3 │ elem = record {}, │ ^^^^^^^^^ expected `String`, found `Record {}` ``` This also paves the way for allowing us to elaborate let-expressions into record terms in the core language, as is done in [1ML]. For example: ``` let { x : S32 = 1, y : S32 = x * 2, } in y - x ``` Could be sugar for: ``` (record { x = 1, y = x * 2, body = y - x } : Record { x : S32, y : S32, body : S32 }) .body ``` [1ML]: http://mpi-sws.org/~rossberg/1ml/ This change also brings the typing rules of record terms closer to that of function terms with labelled parameters, which I think is aesthetically appealing, and could eventually help us bring functions and records much closer together in terms of typing rules and syntax. It does however mean that we no longer allow for out-of order elements in record terms. For example the following is no longer valid: ``` record { y = 1, x = 2 } : Record { x : S32, y : S32 } ``` I'd like to eventually lift this restriction however, but it might require us to do some topological sorting of field elements in the elaborator.

view details

push time in 11 days

create barnchbrendanzab/pikelet

branch : record-term-bindings

created branch time in 11 days

delete branch yeslogic/fathom

delete branch : paul/book-pedantry

delete time in 11 days

pull request commentyeslogic/fathom

docs: Small fixes as i look through the book.

Thanks!

toothbrush

comment created time in 11 days

push eventyeslogic/fathom

Paul

commit sha 6bc29463a6e1be927f81bed4f3e2caf7cd9765b0

docs: Rename inconsistent usage of `Pixel` to `RgbPixel`.

view details

Paul

commit sha 42516934f1096f9d14ea656dd7723d6d4e9d4921

docs: Call out spec header more prominently.

view details

Brendan Zabarauskas

commit sha e952ce922895c0ea63c44e24cbe98b82bccbeda7

Merge pull request #240 from yeslogic/paul/book-pedantry docs: Small fixes as i look through the book.

view details

push time in 11 days

PR merged yeslogic/fathom

docs: Small fixes as i look through the book.

Description

As i find them, i'm fixing small typos and inconsistencies.

+4 -4

1 comment

2 changed files

toothbrush

pr closed time in 11 days

more