jmeaster30 / ocean Goto Github PK

Allow for linking to other hydro source code

Need to avoid name collisions, should we allow aliasing? or some kind of prefixing?

import 'otherSource.h2o'

There is a potential issue with how I am setting the parent scope when creating new scopes.

Currently, I am making a copy of the parent scope and setting that on the subscope.

However, this could cause an issue with type constraints since we may need to update an unknown type in a higher scope with new type information we got in a subscope.

Rename AllocMap to AllocLayout so the intent of what the function does is more clear

Should the member names be configurable at runtime?
I think probably no but it does seem interesting as a concept

We need to build up symbol tables and do some semantic analysis.

• Type checking (straight forward we don't have a super varied number of types but we do have custom types which may be tricky)
• Semantic analysis (honestly I think this is just checking for a main function and making sure the inputs and outputs are good)

I do want the main function to take in some object that encodes the command line arguments instead of just an array of strings and then can output another object that can be passed into some other program

But for now we can just ignore the inputs and the outputs and just look for the main function

I think I was expecting the namespacing variables to take care of these but I need to consider the implications of that further.

There is a work around where you can cast a literal value of the base type though so it isn't super urgent

We are parsing macros but they do nothing (tbf nothing does anything at the time of writing this)

I would like macros to do...

Definitely:

• compile time/runtime assertions on code values
• injecting explicit hydro code into ocean code

Easy and Some Ideas

• documentation generator
• testing (fuzz, unit, etc.)

Probably Difficult and Not Many Ideas

• ast transformation/analyzers
• code generation

I like this feature of c++ so I do feel like I would like to have this in ocean.

Ideas:
op<+>: (a: i32, b: i32) -> (c: i32) { c = a * b; } Would we want to restrict the types that are being overridden??

Basically just function declaration but the function name is op<OPERATOR>

I probably would imagine we could override '()', '[]', and '.' but I don't know how it would work to implement. That being said, I haven't started that so I can probably just figure it out then and make the feature work in as many situations as possible now

I want multiple inheritance too so we need to have a list of inherited types

This will also involve modifying the typeMatching to check inherited types for the stuffs

I want the ability to do object destructuring on tuples and arrays in:

• let statements
• for loops
• function parameters?

Examples:

• remove the first element of the array and store it in "first" then take the remainder of the array and store it in "rest"
  let [first, ...rest] = [1, 2, 3, 4]

• when looping over hash maps you get a tuple of the key and the value, object destructuring will let you take it apart easily

for (key, value) in myHashMap {
   // do stuff
}

I am thinking the array type doesn't look very good
current:
test: i32[5] = 1...5
test: i32[][]

ideas:
test: array<i32> = 1...5
test: i32<5> = 1...5
test: array<array<i32>>
test: i32<5><5>

I want the ability to set up markers for the profiler to run and gather metrics on a custom range of instructions

For now, the start and end must be in the same function.

I like the style of code where if there is an if else block and then the if condition is never negated. We do this in a few places so we should fix it.

Ex:
NO

if !myvariable {
  //some stuff
} else {
  //other stuff
}

YES

if myvariable {
  //other stuff
} else {
  //some stuff
}

The code that links the modules together feels a little hacky.

Need to also resolve modules from across source files and make it relative to the source.

When one type is a subset of the other the type will match when it should be a loose match.

Need to make the match types keep in mind the direction. The lhs type should match the rhs type when the lhs type is a subset of the rhs type

Writing out some of the instructions is a bit tedious so it would be nice to use the builder pattern and allow for a simpler way to declare functions

There is an ambiguity here where we are getting mixed up with decimal numbers.

let a = (123, (456, 789))
a.1.0

That a.1.0 gets parsed as (MemberAccess (Var 'a') (Number '1.0')) instead of (MemberAccess (MemberAccess (Var 'a') (Number '1')) (Number '0'))

I would like to have a binary format that is easier to load

Need to develop and document the binary format

I have a few issues with function syntax that I would like to resolve. I implemented it like it currently is just for the ease but while working on some test files I found these workarounds to be a little annoying.

• The colon between the function signature and the function body
• When functions don't return anything, you should be able to omit the arrow and the return list so the function will look like:

func (value: string) {
    # do some operation
}

• This is not that bad and I likely wont do this one but my original design of the language didn't require the initial 'func' keyword to start off the function.

Need to throw exceptions in certain cases when invalid bytecode is sent to the executor

The user should not be able to cause an exception to be thrown unless they hand write bad bytecode

Execution will completely stop when thrown

Currently you can only use newlines in weird situations and it is inconsistent.

We should be able to use newlines after all operators and probably in certain other situations

I want to be able to pass a function into another function and call it so we would need a function type

ideas:
func<i32, i32 -> i32, i32> a function that takes two i32's as parameters and returns two i32's as output
func<i32, i32 -> auto> a function that takes two i32's as parameters and returns whatever but it is determined at compile time
func<auto -> auto> a function that takes whatever determined at compile time and returns whatever determined at compile time
func<auto<T> -> T> a function that takes whatever determined at compile time and returns the same type

Current the macros do nothing and are just comments that exist in the code.

Here is a list of ideas for what macros code do:

• including other files (we could make this work multiple ways. I think I would want it to parse and generate the IR for the whole file and then we would only need the top level symbol table for type checking with the other files)
• injecting IR directly into the source code (I want to design an IR that is as close to the target assembly as we can get it sort of like how llvm does stuff but then you can inject it directly into the source code (this may make any analysis slightly more difficult but I don't have any of that planned out yet so we can make it work))
• code expansion stuff (like define a macro function that expands out into code after the parse phase but before the semantic analysis / typechecking phase)
• documentation (we can have the compiler compile code documentation and we can have our own markdown format)
• AST transformations (I haven't thought about this a lot. I just think it would be neat like we can define some AST form and then we can show what that form transforms into. This would require some way of formatting text to directly build out the tree)

Step backwards will rely on recording the exact history of the ExecutionContexts. Then we can continue execution at an old ExecutionContext.

Requirements for this to work:

• Ability to continue execution from any existing ExecutionContext
• Continuing execution must act exactly the same as if we never stopped (Barring some external effects that are out of hydro's control)
• All state must be tracked in the ExecutionContext
  • random state (tracking this will let us replay the exact randomness)
  • console output

I want the ability to modify the values on the stack including pushing and popping.

This would definitely cause issues if not being conscious of how the program will react to the changed state. But similar to the modifying variables I don't think I am worried about it being fool proof

'op' optional underscore symbol optional underscore function

defines function to run for the supplied operator symbol. The underscores mark if the operator is the prefix, postfix, or infix version.

The types that the operator takes in and the type the operator produces is defined by the supplied function.

I would like the ability to explicitly define a type as a tuple instead of relying on type inference

I want to have some tests written before we go much further.

I do trust the parser though but it would be good to check just in case. Especially the operation precedence.

I will need to consider that we will want to be running tests that will run external programs in the future but maybe for now we just worry about writting some catch2 tests or whatever.

There is no way to declare an array (or even allocate an array which wasn't implemented yet) in hydro pl.

Use this syntax for declaring arrays

[1 2 3 4 5]

It would be nice to be able to declare a layout as well

Use this syntax for declaring layouts

{
    x 1234
    y 4321
}

Analyze the module for:

• all identifiers must be defined (variables/members/modules)
• make sure function pointers actually point to functions that exist
• type checking
• stack underflows
• labels
• anything else that would throw an exception

I have seen in many languages such as Python, C#, and jakt (and probably many more) operators that are words instead of symbols and in some cases either use the spelled-out operator or the symbolic operator.

I really like this option since it makes things more readable.

So, for the following operators I would like to add spelled-out alternatives to the symbolic operator:

• ! -> not
• && -> and
• || -> or
• ^^ -> xor
• .. -> to

It may be fun to add spelled-out versions of each operator just to see how it is

Finish these todos (more will probably be added in the future) (also some of these aren't marked as todos but are related)

• Finish namespacing in custom types
• Finish namespace in variables (this will include enums however enums COULD be handled with member access)
• Figure out if we want to create an errored function type if one of the params or returns are errored
• Make unary expressions look up overloaded operators
• Make binary expressions look up overloaded operators
• Make the unary add/minus operator change unsigned numbers to signed numbers (especially minus)
• In typeMatch function make sure we match on custom types
• Finish ObjectValue typechecking
• Finish Call typechecking
• Finish Assignment typechecking

I want to be able to hot swap code while the debugger is running

I could probably recompile a part and have some command that specifically replaces the module/function. Need to track source files per module.

Further expansion on the syntax highlighter to provider better editor support

Realized there is no need for strings specifically and we can just use Unsigned8s in an Array to get the same effect

Currently, we just panic when it gets to an invalid token. It would be nice if it was able to parse the whole program and report all of the invalid tokens and the same time.

This would probably require adding error versions of each node.

I disabled it on line 319 of the parser because I wasn't sure how it would work with the symbol table stuff.

It probably is really simple but I just need to consider how to implement it more

need to add getStart and getEnd functions to the astNode that returns pairs where the first part is the linenum and the second part is the colnum.

We should be able to give it the whole program and get the index of the first thing in the file and the last thing in the file (like skip whitespaces at the beginning and end)

We should be able to get any subtree and get the proper start and end

This may need to add some stuff to the parser

Need to add a base type for enums so we can declare a type that the enum is wrapped around like an i32 or a byte then we can do operations on the enums as if they were the base types

currently you can only make a regular array literal but we need the ability to add hash array literals (arrays that have an index type that is not unsigned integers)

Syntax Idea :

let hash: i32[string] = [
    "test": 123, 
    "another": 555
]

We can either generate an IR that we simulate or we can do a tree walking interpreter.

• IR
  • pro: we will have to generate this in the future anyway
  • pro: can be faster
  • con: will take longer
• Tree walk
  • pro: very easy
  • con: we can't do much (if any) optimizations
  • con: we want to keep the interpreter in the system even when the compiler is working so making it too simple now would mean we have more work to do later.

This would be a new token so a parser change is necessary

a hex literal would be a "0x" followed by at least 1 pair of hex digits (case insensitive)

the type would be the unsigned chain of integers

Make it so we can modify variables that are in the current context.

Not sure the usefulness of this but it would be neat. It probably would cause issues unless we type checked it but not sure how much I care about it being fool proof

When we go to typecheck the body of a function, we don't actually have the function name.....

I want to both interpret and compile the source code. But I want to start with a basic interpreter first.

Then we can write functionality tests to make sure the interpreter and the compiler match exactly

Need syntax highlighting

I only really use vscode so I will do that first but I may come back and do syntax highlighting for other editors as well

• VSCode
• Vim
• Emacs
• Others

This is a checklist of what is left on the parser based on the things I want to implement now

• Error
  • This should not just be at the statement level
• Continue
• Break
• Return
• PackDec
  • Default Values
• UnionDec
• VarDec
• CastDec
• Use
• Macros
• If
  • else if
  • else
• For
• While
• InfiniteLoop
• Expression
• Function
  • default parameter values I don't really wanna do this
  • varargs
  • Return expressions
• Binary
  • default
  • range
  • array
  • multiplicative
  • additive
  • bitwise
  • logical
  • shift
  • comparison
  • equality
  • assignment
• Prefix
• Postfix
• Member
• ArrayAccess
• CastExp
• Literal
  • array
  • tuple
• subexpression
• Var
• FunctionCall
• Type
  • Auto
  • Comp
  • Sub
  • Func
  • Base
  • Lazy
  • Ref
  • Optional
  • Array
    • Index type

Like the title. This makes it so the time spent in the debug console is added into all of the running timers which is undesirable.

We set up subset matching so i8's match to i32 and i32's don't match to i8 and etc.

This is how I want to do type inference in Hydro but the function tracking does exact matches instead.

Possibly need a custom matching function to use for the hash map

Want a debugging mode

Add a breakpoint instruction that when hit will pause execution and allow the user to run some commands on the hydro code

• Breakpoint instruction
• Set breakpoints from debug command line
• #46
• view variable values
• #47
• view stack
• #48
• continue execution
• dump stack trace
• profile instruction
• step forward
• #49
• #50

I would like to be able to write out hydro code without requiring me to manually type out the binary representation.