There are several things yet to be considered:

• [ ] Every file in docs/ starts with

  <iframe src="./.ibox.html?raw=true" style="border:none; position:fixed; width:40px; right:0; z-index=999;"></iframe>
  

  MDL doesn't like that because:

  • It's inline HTML
  • The first line should be a top-level heading

  Maybe the documentation renderer could add that?

• [ ] docs/15 Examples/15.3 Calculating Pi.md has an embedded YouTube video:

  <iframe title="YouTube video player" src="https://www.youtube.com/embed/sFun7N9OpiQ"
  width="560" height="315" frameborder="0" allowfullscreen
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"></iframe>
  

  which MDL doesn't like as it's inline HTML Daedalus seems to already support embedded local videos, maybe it could also have YouTube/Vimeo/etc. support? Although this is a Daedalus issue.

• [ ] Every second-level heading (## Something) is followed by a ---, for example docs/01 Introduction.md (permalink):

  ## Characteristics
  
  ---
  

  Maybe this could be done by easy CSS like in GitHub? A bit modified example:

  h2 {
      padding-bottom: .3em;
      border-bottom: 1px solid gray;
  }
  

  But there's one exception which confuses me in docs/05 Syntax and Semantics/5.1 Syntax.md:

  ## Sub-expressions without the braces
  
  There exists a shorthand for sub-expressions which can be used as the **_last_** argument. The  
  

  It's the only place where h2 isn't followed by an hr.

could this also be hacktoberfest-accepted?

Goal

Alter the Expecting enum from parsing to use bitflags, indicating it could be composed of more than a single variant.

https://github.com/kdr-aus/ogma/blob/a1952df8534562c486145e6ee1400ad5a213a6f3/ogma/src/lang/syntax/parse.rs#L112

Current Behaviour

open executions-lt.csv | filter mean = -1 | filter conf != 1.01 | grp coin  | append --fiat { get value | fold 0 { + $row.sell-fiat | - $row.buy-fiat } } | append --trades { get value |:Table len } | append --avg { get value | let {len} $l | fold 0 + $row.ret-pct | / $l }

Altering the last get value to get:Table value it compiles.

Expected Behaviour

Reproduction Steps

Additional information

Goal

Constrain the type system such that all defs have a known input type.

Benefits

More robust type inference is the major goal here. By knowing the set of concrete types that a def is expecting, only that set of types has to be tested.

Concerns

Agnostic defs

Many defs are input agnostic. This will still be a requirement. The proposed solution is to force the input to be Nil. Unfortunately, this will break how the current type inference flows types. The convention will break certain patterns, for example:

# This would previously work, and list out along folder `foo-bar`.
\ 'foo' | ls { + '-bar' }

# Now the concatenation would have to occur sooner, be bound to a variable, and then passed as an argument.
\ 'foo' | + '-bar' | let $x | ls $x

Since this pattern becomes unwieldy with the change, it might be worthwhile adding a definition which can handle this:

\ 'foo' | + '-bar' | zog ls $z
                     ^^^ --- ^ a def which stores input in $z and calls `ls` with Nil input

Another approach would be to consider defs with Nil input types to be agnostic. It is rare to actually switch input to Nil to call a def, so rather than having a distinction between Nil and anything, combine the two and add a special variable (or literal?) which can be populated with the output of the previous block. This approach may grate with the goal of reducing type inference complexity. The issue is the coercion to any output type, it makes the type inference unconstrained.

def foo Nil (len:Num) { \ $len | + 2 }

ls | foo { \#i | len }

Maybe a combination?

To keep the input type as a constraint, a defining characteristic of the call needs to be present. The input def (\) would be a good candidate. Parsing would need to be altered to such that trailing characters are taken as a def identifier.

def foo Nil (len:Num) { \ $len | + 2 }
                         ^ a space is now necessary

ls | \foo { \ $prev | len }
     ^^^^     ^^^^ store output of previous block in `$prev`
     `foo` is known to be called with `Nil`.

# Another way to write this
ls | len | \foo $prev

The let def

The let def is special, since it is required to be general.

• [x] #109
• [x] #110
• [ ] #111
• [ ] #112

This should not 'compile' since the output of the fold is a string, but it is expecting a tuple.

Instead, it generates a runtime error. This is a bug, needs to fail compilation.

# Convert a number to hexadecimal string with `pad` padding.
def to-hex Num (pad:Num) {
    let $n | range 0 $pad | fold {Tuple '' $n} {
        let #i.t0 $s #i.t1 $n | \$n | mod 16
        | if {=0} '0' {=1} '1' {=2} '2' {=3} '3' {=4} '4' {=5} '5' {=6} '6' {=7} '7'
             {=8} '8' {=9} '9' {=10} A {=11} B {=12} C {=13} D {=14} E F
        | + $s | rev
    }
}

Goal

Hi - I'm JT and I work on the Nushell project. We just found out about this project, very cool! Are interested in coming to say "hi" on the Nushell discord, by chance? We've got a channel called #external-collab where folks interested in this area can collaborate with each other, brainstorm ideas, etc.

Goal

Build a structure by walking filesystem hierarchy for *.ogma files.

Aspects to Develop

• Structure could be BTreeMap<PathBuf, Vec<File>>
• PathBuf is used as partition name/path
• Clashes with name.ogma and name/foo.ogma should error out with informative error message
• Set up a partition test hierarchy which tests all this things

Goal

For use with partitions, but could also be used with the batch system. Parse a file into a list of directives, list of types, list of impls, and list of exprs. The types, impls, and exprs can all support doc comments.

Aspects to Develop

• [x] Develop parser
• [ ] Replace batch parser with this parser

Goal

Similar to the current Definitions, initialise ogma defined defs. Will have to go through the partitions system to add these items to the root.

Aspects to Develop

• [ ]

Goal

Given a set of imports, resolve all the dependencies. Resolving means to parse/add and make available in the Defintions.

Aspects to Develop

• Lazily parse/add dependencies
• Completely based off import directives
• Globs may require parsing/add all items (depending on glob matches)
• Probably use a stack based system
• Will need cycle detection
  • foo imports bar which imports foo

Goal

Using the structure build from #175, add each item into the partition graph structure.

Aspects to Develop

• Testable in memory
• Tests for item name clashes within a partition
• Items do not need to be parsed/compiled, this can be done lazily (however the code snippets would need to be stored)
• Check for partition name validity

Goal

Currently, defs are detected at the parsing stage, using the known defs list. With the introduction of partitions and lazy parsing of those partitions, this quickly becomes tricky to determine which def needs to get parsed first.

A more structured approach to the parsing may be required, one which scans the partition tree first, setting up pointers to potential defs (fairly easy with the def keyword).

Ultimately, thought needs to go into how much of the partition tree needs to be fully parsed and memoised. I would prefer a lazy approach which only parses the referenced defs, with some caching to avoid continually hitting the disk.

Goal

If #169 gets merged, rework the completions code to match on whether the expecting contains a flag, rather than value matching with the flags themselves.

\ 2 | foo 'hasdfg' ┃4 ┃>> \ 2 | foo 3 ┃4 ┃>> foo --help ┃ ┃Help: foo ┃ ┃--> shell:0 ┃ ┃ | ---- Input Type: ---- ┃ ┃ | user defined implementation in shell ┃ ┃ | def foo (a) { + $a } ┃ ┃ | ┃ ┃ | Usage: ┃ ┃ | => foo a ┃ ┃ | ┃ ┃ | ---- Input Type: Number ---- ┃ ┃ | user defined implementation in shell ┃ ┃ | def foo Num (a) { + 2 } ┃ ┃ | ┃ ┃ | Usage: ┃ ┃ | => foo a ┃ ┃ ┃ ┃>> def foo Num (a) { + 2 } ┃ ┃() ┃ ┃>> \ 'Hello' | foo ' Jason' ┃ ┃Hello Jason ┃ ┃>> \ 2 | foo 3 ┃ ┃5 ┃ ┃>> def foo (a) { + $a } ┃ ┃()