| Age | Commit message (Collapse) | Author |
|---|
|
+ Apparently I forgot how shell quoting works, lol
|
|
+ Makes vec example actually memory safe, which is cool
+ Specify owner > sub relationships with ">" in closure parameter
lists, uses the same group idea as closure calls
+ Relies on users implementing functions in a consistent manner,
since you can kind of do whatever with pointers. Presumably
there would be a stdlib of vec/map/set etc. which applications
could then use and by proxy be memory safe. Although some more
checks wouldn't hurt, I suppose?
+ Not sure I like having reference invalidation be 'just a move',
seems to work alright but the semantics of it are a bit muddy.
|
|
+ Compiler works fine, example was borked :)
+ Although, not a very good example I must admit, it bashes a hole into
my nice memory analysis plan :(
|
|
|
|
+ Doesn't quite work yet, but compiles fine. Some issues were in the
example itself, heh
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ Fixes tail call analysis that was accidentally broken by
64146b46da45ce69ab380add00459f7b60fe9196
+ Kind of wasteful to first allocate empty node and then just throw it
away, but I don't have any better ideas at the moment
|
|
|
|
+ Currently requires a lot of unnecessary `forget` statements,
but at least some can likely be eliminated by doing some
basic origin analysis, kind of like with groups
|
|
|
|
+ Hopefully shows that useful programs can be implemented with
the rules present
+ Still missing at least external functions with non-void returns
|
|
+ Big commit, scary
+ Some details still a bit up in the air, mainly about move checking
structure member access ('register' types are freely copied I guess,
same as in rust? How about user types?)
|
|
|
|
+ Still not quite as robust as I'd like (and the autovectorization
problem persists) but at least there shouldn't be a risk of
overwriting a field following the parameters
|
|
+ C allows for a bit more control, and we can manually handle closure
contexts. For example `examples/fib.fwd` now works for effectively any
`n`, pretty cool.
+ Fairly slow Fibonacci, I must admit. Initial profiling indicates it's
mainly due to branch mispredictions, but I'll have to look into this a
bit deeper.
+ The code is a bit hacked together, for now I'm more interested in
getting things working, I'll worry about making things pretty later.
+ For testing, there's also initial support for modules, just so I can
print stuff to the terminal
+ This commit is way too big, lol
|
|
|
|
|
|
|
|
|
|
|
|
+ Returning blocks don't want to show moves for subsequent statements,
but do want to show them for possible closure callers above.
|
|
|
|
+ Probably kind of silly since I'll probably not use the C++ backend in
the future but at least it's a bit easier to read what's going on
+ Total move checking doesn't seem to work in if statements, will have
to fix at some point
|
|
|
|
|
|
|
|
|
|
+ Enough that examples still compile, but missing references etc.
|
|
+ Missing implementations for most things, but it already highlights
an oversight in my initial plan, namely that currently, a function
might call multiple of its closures, meaning that a closure wouldn't
be allowed to move a value. I'm debating whether to check that only
one closure from a parameter list is called at a time or if I should
do what Hylo does and add in some kind of 'subscript' that's like a
function but has slightly different rules?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ Hopefully it generalizes well, but at least it does use both lifetime
and ownership intermixed
|
|
+ Useful for guard statements, not entirely sure about the final syntax
but at least they're possible
|
|
|
|
|
|
|
|
+ No actual type checking is implemented as of yet, but with references
and pointers I should be able to start playing around with checking
move semantics and so on
+ Might at some point also look into type propagation for let,
annoying to have to specify the same thing twice.
|
|
|
|
|
