Skip to content

Miking Meeting Notes 2020

David Broman edited this page May 13, 2021 · 6 revisions

Meeting Notes 2020-02-19

Note-taker: Daniel Lundén

  1. Reviewing policy:
    • Write in Slack when PR ready, ask for review.
  2. New PRs:
    • [Accept] #36 Pretty printer for MExpr.
    • [Accept] #43 Replace environment with a context and add float arithmetic.
  3. Recursion schemes:
    • Read up and discuss on future meeting (Viktor lead?)
  4. Term equivalence:
    • Write separate eq checks for own types.
    • Have as a semantic function (+ ordering).
  5. k-CFA:
    • Seems like a good idea in general, will discuss further on future meeting (Daniel lead?)
  6. Mutability:
    • Implement everything with immutable data structures for now.
  7. Syntactic sugar (record with):
    • To be continued. Merge operator?
  8. Default values, types:
    • Will be discussed on Slack.

Upcoming meetings

2020-02-25, 13:00-15:00

  • Recursion schemes
  • k-CFA (edited)

Meeting Notes 2020-02-25

Note-taker: Viktor Palmkvist

Summary on the recursion part of the meeting today:

  • Have a semantic function for a single generic step, and a semantic function for a generic fold
  • smap : (focus -> a) -> term -> term[focus -> a] (The square brackets mean substitution, but we haven't really solved how this looks in the type system, since we don't have a typesystem) (For the example, replace term with Statement and focus with Expression)
  • sfold : (b -> a -> b) -> b -> term[focus -> a] -> b
  • concretely, we will initially implement these as sem smap_term_focus and sem sfold_term_focus
  • with these we can write, e.g., bottom-up fold as foldbu f = smap (foldbu f) >>> f (using >>> for left-to-right function composition), or counting the number of nodes as countNodes = foldbu (sfold (+) 1)

Meeting Notes 2020-03-04

Note-taker: Viktor Palmkvist

PRs:


Meeting Notes 2020-03-11

Note-taker: Oscar Eriksson

PRs

  • Add lambda lifting in MCore https://github.com/miking-lang/miking/pull/46 We like it - merge Going forward:
    • To be able to handle partial applications over constants we can use eta-expansion.
    • Add test: evaluate lifted to non-lifted.
  • Add missing parenthesis in pretty printer for TmApp https://github.com/miking-lang/miking/pull/56 We like it - merge
  • Implemented non-observable unique symbols https://github.com/miking-lang/miking/pull/54 Fix: Change gensymb to gensym then: We like it - merge
  • Failed const app error point to app rather than arg declaration https://github.com/miking-lang/miking/pull/55/commits We like it - merge
  • From Last time
  • CSeq in Const contains Expr, do we want to only have TmSeq instead? (it's in Expr) We want operators over consts to be closed. We have to look at this further and we do not want this duplication in the CSeq case.
  • Put editor support in separate repositories? Under miking organization? Yes, add as task. Name repo as miking-.
  • Columns in board We suggest that we keep done and remove pull-request column so that done includes tasks that have an associated PR. (edited)

Meeting Notes 2020-03-18

Note-taker: Linnea Ingmar

  • From next week and onward: we will have two 1 hour meetings per week. Tuesdays and Thursdays 15-16 by default.
  • Went through the board and discussed what everyone is working on
  • Created a Wiki to put documentation such as Recursion Cookbook. Anyone logged into GitHub can edit, but we assume this is not a problem.
  • PRs -- General comment: Always check on GitHub that PRs can be rebased. -- #57 Bug fix in lambda lifting. https://github.com/miking-lang/miking/pull/57 We like it, merge! -- #59 Reuse of generated arguments within the same scope. https://github.com/miking-lang/miking/pull/59 We like it, merge! -- #58: Forward mode auto diff. https://github.com/miking-lang/miking/pull/58 Needs a review. David volunteers.
  • Oscar presented Forward Mode Auto Differentiation.
  • Documentation of code: at least, give an overview description in the top of the file. If relevant, include sources of implementation, e.g. reference to papers.
  • Follow up discussion on whether to remove CSeq. Agreed to do so!
  • Follow up discussion on column in board: agreed to remove pull-request column.
  • Next meeting: Linnea and Viktor go through thoughts on benchmarking framework. Use merge sort as example. (edited)

Meeting Notes 2020-03-24

Note-taker: John Wikman

Attendees: David Broman, Viktor Palmkvist, Linnea Ingmar, Daniel Lundén, Oscar Eriksson, Klas Segeljakt, John Wikman Pull requests

  • Review and discussion postponed to next meeting due to time shortage.

Code formatting conventions

  • Try to keep to 80 characters per line until further notice. Can exceed 80 characters if it aid readability.
  • Scope indentation should be 2 spaces. Formally voted in favor of by 6 out of 7 attendees.
  • This will be handled by an automatic formatter in the end.

Remove the Const from the AST

  • An idea brought forward was to remove the Const type from the AST and replace all removed functionality by Expr constructs. E.g. TmConst (CInt) would become TmInt and TmConst (CAddi) would become TmIntrinsic (Addi).
  • This idea was positively received by the attendees.
  • Also discussed how to keep gti, lti, neqi, eqi (etc.) in the environment, but in the end that these could be mapped differently to the builtin intrinsics.

Option to output desugared program in boot

  • It would be nice to have the option in boot to output the program as it looks after the MLang flattening and desugaring has been applied. Would be passed an an argument option.
  • We like it, Daniel will implement it if it doesnt take up too much time.

Factor out convenience functions

  • Take the convenience functions from lamlift.mc that are used to create an AST without a parser and move them to a separate file under the stdlib/mexpr.
  • We like it, John will implement it.

Benchmarks

  • Viktor and Linnea presented their current progress on the benchmark setup.
  • The benchmarks will be kept in a separate repository from the miking repository. This will contain benchmarks written in MCore as well as the same tests implemented in other languages for comparison.
  • Two approaches of how to organize the benchmarks were presented: A flat structure or a hierachical structure where datasets and test configuration can be inherited from the higher level.
  • The discussion leaned towards using some form of hierachy for the structure, but not too hierarchical as some benchmarks might be very specific and not share much configuration or datasets with other benchmarks.
  • The tool to manage these testcases would be developed by ourselves. Go was brought up as a candidate language to develop the tool in due to its cross-platform support, but Rust was brought up as a preferrable alternative.
  • Some remarks brought forth was that this setup should take into account factors such as architectures, compilers, and compiler flags.
  • The benchmark system will be split into 3 separate repostirories: one for the benchmarks, one for the tool, and one for the results.
  • Will start sketching on the benchmark structure until next meeting.

Meeting Notes 2020-03-27

Note-taker: Viktor Palmkvist


Meeting Notes 2020-03-31

Note-taker: Daniel Lundén

Pull requests

Discussions

  • Lists/sequences/vectors/universal collections
    • John needs fast concat.
    • Oscar needs fast random access.
    • Temporary solution: finger trees or other more efficient data structure? Oscar will look at it.
  • Merging semantic functions with nested patterns
    • Discussions lead by Viktor. Viktor and Elias will look at it further? (edited)

Meeting Notes 2020-04-02

Note-taker: Elias Castegren

Pull requests

Discussions

  • Elias’ issue https://github.com/miking-lang/miking/issues/67 regarding matching on primitives and sequences in semantic functions
    • Some of the features asked for has already been implemented for MExpr (matching on sequences and primitives). Viktor writes a reply to the issue mentioning this. It still needs a translation from MLang though.
    • Viktor pointed out that this is very similar to the problems encountered when doing extensible lexing and parsing. The solution we come up with (whether it is a compiler feature or a programming pattern) should be applicable to both.
  • Oscar’s experiments with Finger Trees, from Batteries
    • Should provide faster random access and concatenation (compared to lists).
    • Needs exposing more constant functions to be efficient.
      • We went through the interface and decided on which functions to have.
    • Oscar would like to have a Map type, since Finger Trees does not help with this. We might add a special case for Oscar’s use-case, to allow us to punt on design decisions regarding, e.g., type classes.
  • Discussion on Git(Hub) hygiene
    • We decided to use the “Squash and merge” feature of GitHub. This makes the heading of the resulting commit the title of the PR, and the body the concatenation of the commits. This means we should be careful to write informative PR titles (and ideally also informative commit messages).

Meeting Notes 2020-04-07

Note-taker: Oscar Eriksson

PRs

https://github.com/miking-lang/miking/pull/71

  • We like it, merge

https://github.com/miking-lang/miking/pull/70

  • Replace patterns implementation data-structure with sequence.
  • Move init, head, tail, last to stdlib
  • Elias reviews

https://github.com/miking-lang/miking/pull/72

  • Merge with pprint.ml
  • Viktor reviews

https://github.com/miking-lang/miking/pull/21

  • Add andThen
  • replace Dyn with lower case parameters, then: accept

Conventions

Make conventions page at Wiki (Oscar) So far, we have adopted the following conventions:

  • Type parameters should be lower-case
  • CamelCase
  • 2 space indent
  • 80 char width (if possible)

Meeting Notes 2020-04-09

Note-taker: Viktor Palmkvist


Meeting Notes 2020-04-14

Note-taker: Linnea Ingmar

  • PRs
  • Discussion about generating unique variable names
    • Three alternatives: 1. “Locally Nameless”, 2. a mapping from AST with strings->AST with symbols, or 3. the AST nodes have both a string and a symbol.
    • We will probably go with the last alternative, unless any problems arise.
    • Elias and David will think more about consequences on the type system etc. of this.
    • Daniel’s problem solved by fresh function in eval.mc for now.

Meeting Notes 2020-04-23

Note-taker: Elias Castegren

Pull Requests

Discussions

  • We decided to introduce a construct #label (symmetric to #var and #con) for specifying record labels which are not syntactically correct (e.g. numeric values).
  • We decided to have maintainers for the repos of different editing modes, for updating them when the language evolves. Elias takes the Emacs mode, Daniel takes the Vim mode and John takes the Sublime mode.
  • We discussed if let _ = ... in ... should be valid or not. We decided to punt on the decision.

Meeting Notes 2020-04-30

Note-taker: Viktor Palmkvist

PRs - David: mention of removal of de bruijn indices in boot, which might be merged in-between meetings. - Oscar: https://github.com/miking-lang/miking/pull/83 - We like it, merge - Daniel: look at https://github.com/miking-lang/miking/pull/86, though it's not intended to be merged at this point

  • Discussion
    • WebAssembly: not really looked at yet, but definitely an interesting target. Analogues to John's compilation to GPU.
    • Daniels questions: see response by Elias above, but briefly: things are in progress and those questions are explicitly in the case studies we're considering.

Meeting Notes 2020-05-05

Note-taker: Oscar Eriksson

PRs


Meeting Notes 2020-05-12

Note-taker: Linnea Ingmar

PRs

  • MExpr simplifications https://github.com/miking-lang/miking/pull/89
    • Proposal: remove unit keyword (@vipa volunteered to fix)
    • We like it (merged during meeting)
  • We will move Miking meetings to 14
  • Discussion on benchmark ideas for decision points
    • Viktor: pattern matching: use memoization or not
    • Oscar: Sorting of equations and variables, and representation of data
    • Klas: window aggregation algorithms
    • John: choice to run on a GPU or CPU
    • Daniel: choice of inference algorithms
    • Use refinement types for performance (choice of AVX instructions)
    • Compile javascript to webassembly or not
    • Some related works suggested by Elias

Meeting Notes 2020-05-14

Note-taker: Elias Castegren

Pull Requests

  • https://github.com/miking-lang/miking/pull/90 (David)
    • Constructors are no longer first-class (they need to be fully applied). Constructor definitions statically define a unique symbol, rather than it being handled dynamically. Constructor and variable names now live in the same namespace.
    • David will revert the change regarding namespaces. Variables and constructors will be syntactically distinct.
    • Viktor will finish his review.
    • We will revisit this PR next week.
  • https://github.com/miking-lang/miking/pull/91 (Viktor)
    • Semantic functions now have nested, order-independent patterns. There is also support for and-patterns, or-patterns and not-patterns. Ambiguous patterns (where two patterns are unordered by specificity but are still overlapping) are considered a compilation error.
    • Viktor will write a few more test cases.
    • Elias will have a look at the PR.
    • We will revisit this PR next week.

Discussions

  • We need a story for writing test cases which fail due to compilation errors, or test cases that depend on a specific output.
  • We should put Linnea’s lstlisting under github.com/miking-lang/

Meeting Notes 2020-05-19

Note-taker: Daniel Lundén

Pull requests

Discussions

  • We will start implementing many things in MCore from now on, rather than in boot.
  • We will not add Ragnar stuff to boot parser because of bootstrapping issues.
  • Postpone comment discussion; Elias will create issue on Github.

Meeting Notes 2020-05-26

Note-taker: Oscar Eriksson

https://github.com/miking-lang/miking/pull/94 Change to nested patterns, then we like it, merge


Meeting Notes 2020-05-28

Note-taker: Elias Castegren

Pull Requests

  • No pull requests today!

Discussions

  • We discussed the syntax of comments.
    • We decided to punt on decisions regarding the precise syntax for documentation, etc., but we noted that we should keep it in mind for the decision.
    • We said that whatever we pick should ideally also be compatible with Ragnar in the future.
    • We discussed whether we should optimize for free-standing block comments or for commenting out code inline. Most people agreed that the latter is done rarely.
    • Some more suggestions were put forth, summarized in the GitHub issue: https://github.com/miking-lang/miking/issues/95