yuxshao / makergame Goto Github PK

We should allow statements like int x = 3 (call it a vdecldef). It's so much more awkward to split it up. We should also consider more carefully what can go into the condition of the if and while statements, as well as the initializer of the for. From looking at what clang does, I think it makes sense to have the following:

• if and while conditions can contain either a vdecldef or an expr (currently they take exprs).
• for initializers can contain either a vdecl or vdecldef or expr_opt (an expr or nothing; currently they take just an expr_opt)

we need one that doesn't use core because the versions are all screwy

rendering without giving a new sprite/sound every time there's a call

we should have a separate lib that doesn't make SFML calls to be used for testing

now that we have foreach loops break statements would be very helpful to stop iteration in any of the three loop structures. i think it'll be a common use case too e.g. if we have thousands of objects and want to just select any one.

Should we allow statements after a return in the same basicblock?

Some milestones for Hello World:

• Open a window
• Handle the most basic event (closing the window)
• Loop through a predetermined block of code while the window's open

From Hello World, I think we could choose to move in one of two ways:

Integrating more with SFML:

• Drawing a predetermined thing to the screen
• Playing a predetermined sound
• Programmatically playing a sound
• Programmatically drawing a sprite

Language features:

• Game object semantics (somewhere along this is figuring out the data structure for objects)
• • Adding
• • Removing
• • References, checking existence?
• Other datatypes like strings (goes with loading things?)
• Other features - pointers, heap?

We should have stuff like +=, -=, *=, /=, along with ++ and --. It's a little annoying to write stuff like i = i + 1 all the time.

Not sure what'd be the best way to go about doing this, but maybe we could start with fixed-size arrays, with arrays of different lengths being incompatible with each other. To figure out what'd actually be useful we should implement some game that relies on arrays like Tetris... maybe

a way to get a boolean to tell if an object has been destroyed or not. use id field

We should allow ints in float operations. We should decide whether or not this is implicit. In any case, we need some external/built-in functions for conversion.

If implicit: LLVM is strongly typed so we need to figure out -when- we can convert an int to a float in semant, then actually do the conversion in codegen. We can try to follow a (subset of?) what C++ does which does implicit conversions when a conversion from T1 to T2 exists and:

• An actual of type T1 is assigned to formal T2
• A value of type T1 is assigned to a value of type T2

Since operators aren't exactly functions in our language (yet), this can also happen when a value of type T1 is an operand of an operator expecting a type T2.

I'm in favour of allowing just the assignment conversion since that's when it's really explicit. Or else not allow it at all. Or maybe just warning against all implicit conversions.

It'd be good if we could allow duplicate variables and interweave variable declarations statements. This would involve changing Ast.block to be just a single list rather than a record of two, and computing scopes after every statement in the codegen.

An object pointing to 'none' would be helpful - id 0 pointer 0

It'd be nice to declare things like int x = 3; in the global scope as long as the RHS is constant (I guess, a literal or any composition of such).

we should have foreach (object o) { ... /* e.g. destroy o */ } and maybe also allow declaring variables with type object.

It'd make sense for makergame programs to include a bunch of built-in functions declared in some file. In this respect it'd be nice to allow files to include other files, and then possibly have the compiler always include some default library file. For now at least it's annoying to include end_game in every test, but it needs to be declared since the compiler has hardly any built-in functions (so far just print, but that will be removed shortly too).

If we're going to have library functions it might be nice to separate them from regular ones, say with namespaces like in C++. I propose the following syntax:

// lib.mg
// declaring namespaces
namespace ns = {
  int x;
  int compute() { ... }
  player { int y; ... }
}

// using things in namespaces
void main () {
  ns::player p = create ns::player;
  p.y = 3;
  ns::x = 4;
}

// putting namespace contents into scope
// (if it's not hard maybe make it so that this doesn't put
// ns in scope for the entire file, but only starting here)
using namespace ns;
void compute () {
  player p = create player;
  p.y = 3;
  x = 4;
}

And with separate files:

// fills namespace lib with contents of lib.mg (sort of literally replaces
// 'open ...' with the contents of the file, surrounded by braces)
namespace lib = open "lib.mg";
void hello () { lib::compute(); }

// puts everything in lib in scope of this file. equivalent to:
// namespace lib = open "lib.mg";
// using namespace lib;
using open "lib.mg";

void hello () { compute(); }

Like in C++, if any identifier could possibly resolve to multiple globals we raise an error.

ghost and pacman for slides and first page

The way objects are structured right now makes it really amenable to single-parent inheritance that's essentially an object having a single member of its parent. Not sure how overloading would work though.

What do you guys think about the following changes?

• Event declaration: event create(...) { ... } instead of CREATE(...) { ... }
  • Additionally, allow function definitions in objects. (So events are really just the same as void-returning functions, possibly taking arguments in the case of create - but I think it's good to have distinction visible in the code)
• Game object type declaration: object Player { ... } instead of player { ... }
• Creation and destruction: e.g. p = create Player(...); and destroy p instead of create(Player) and destroy(p).

All three changes make things just slightly easier to parse. Do any of them look worse in your opinions?

Should we allow stuff like void main () { int x; x = 3; int x; x = 5; } since x is declared twice? C++ disallows this. Either way we should document our decision in our LRM

gameobj that doesn't expose draw, etc. instead has default x and y variables, speeds, sprite information.

okay I think the right way to do this is to add an additional entry to the vtable expressly for disconnecting nodes and setting id to 0 (in case of room changes), and a way to delete an object without calling its destroy event. Turns out game maker has a similar concept: the cleanup event

Though a user technically won't ever need it, it might be a good idea to allow member functions (public like everything else for now at least). A few implications:

• Writing this all the time is sort of clumsy in events. With member functions it'll be even clumsier. Would it be a good idea to also put into scope the current object's member variables?
• It would make sense to distinguish between member functions and events using an event keyword as in #3 (if we use a C++-like syntax for functions).

Floating point types and literals are currently in master. But you can't do anything to them other than pass them to (possibly external) functions and print. Once logic and arithmetic with floats is done, close this issue.