kanaka/mal
1
1
Fork 0
mirror of https://github.com/kanaka/mal.git synced 2024-09-11 21:57:38 +03:00
Code Issues Projects Releases Wiki Activity
412e50e306
mal/impls/vala/step5_tco.vala

234 lines
9.3 KiB
Vala
Raw Normal View History

Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
class Mal.Main : GLib.Object {
static bool eof;
static construct {
eof = false;
}
public static Mal.Val? READ() {
string? line = Readline.readline("user> ");
if (line != null) {
if (line.length > 0)
Readline.History.add(line);
try {
return Reader.read_str(line);
} catch (Mal.Error err) {
GLib.stderr.printf("%s\n", err.message);
return null;
}
} else {
stdout.printf("\n");
eof = true;
return null;
}
}
public static Mal.Val eval_ast(Mal.Val ast, Mal.Env env)
throws Mal.Error {
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
var roota = new GC.Root(ast); (void)roota;
var roote = new GC.Root(env); (void)roote;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
if (ast is Mal.Sym)
return env.get(ast as Mal.Sym);
if (ast is Mal.List) {
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
var result = new Mal.List.empty();
var root = new GC.Root(result); (void)root;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
foreach (var elt in (ast as Mal.List).vs)
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
result.vs.append(EVAL(elt, env));
return result;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
}
if (ast is Mal.Vector) {
vala: avoid half-constructed vectors being garbage-collected. The clause in eval_ast() which evaluates each element of an input vector into an output vector was holding the intermediate results in an ordinary GLib.List, and putting them all into a vector at the end of the evaluation. But that meant that nothing was preventing all those values from being garbage-collected half way through. Now we make an output Mal.Vector at the start of the process, and point a GC.Root at it to ensure it stays around until we've finished putting items in it. This fixes the vala part of #418, I think.
2019-07-16 23:10:02 +03:00
var vec = ast as Mal.Vector;
var result = new Mal.Vector.with_size(vec.length);
var root = new GC.Root(result); (void)root;
for (var i = 0; i < vec.length; i++)
result[i] = EVAL(vec[i], env);
return result;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
}
if (ast is Mal.Hashmap) {
var result = new Mal.Hashmap();
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
var root = new GC.Root(result); (void)root;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
var map = (ast as Mal.Hashmap).vs;
foreach (var key in map.get_keys())
result.insert(key, EVAL(map[key], env));
return result;
}
return ast;
}
private static Mal.Val define_eval(Mal.Val key, Mal.Val value,
vala: remove a redundant parameter
2019-07-15 23:46:55 +03:00
Mal.Env env)
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
throws Mal.Error {
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
var rootk = new GC.Root(key); (void)rootk;
vala: remove a redundant parameter
2019-07-15 23:46:55 +03:00
var roote = new GC.Root(env); (void)roote;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
var symkey = key as Mal.Sym;
if (symkey == null)
throw new Mal.Error.BAD_PARAMS(
"let*: expected a symbol to define");
vala: remove a redundant parameter
2019-07-15 23:46:55 +03:00
var val = EVAL(value, env);
env.set(symkey, val);
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
return val;
}
public static Mal.Val EVAL(Mal.Val ast_, Mal.Env env_)
throws Mal.Error {
// Copy the implicitly 'unowned' function arguments into
// ordinary owned variables which increment the objects'
// reference counts. This is so that when we overwrite these
// variables within the loop (for TCO) the objects we assign
// into them don't immediately get garbage-collected.
Mal.Val ast = ast_;
Mal.Env env = env_;
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
var ast_root = new GC.Root(ast); (void)ast_root;
var env_root = new GC.Root(env); (void)env_root;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
while (true) {
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
ast_root.obj = ast;
env_root.obj = env;
GC.Core.maybe_collect();
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
if (ast is Mal.List) {
unowned GLib.List<Mal.Val> list = (ast as Mal.List).vs;
if (list.first() == null)
return ast;
var first = list.first().data;
if (first is Mal.Sym) {
var sym = first as Mal.Sym;
switch (sym.v) {
case "def!":
if (list.length() != 3)
throw new Mal.Error.BAD_PARAMS(
"def!: expected two values");
return define_eval(list.next.data, list.next.next.data,
vala: remove a redundant parameter
2019-07-15 23:46:55 +03:00
env);
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
case "let*":
if (list.length() != 3)
throw new Mal.Error.BAD_PARAMS(
"let*: expected two values");
var defns = list.nth(1).data;
env = new Mal.Env.within(env);
if (defns is Mal.List) {
for (unowned GLib.List<Mal.Val> iter =
(defns as Mal.List).vs;
iter != null; iter = iter.next.next) {
if (iter.next == null)
throw new Mal.Error.BAD_PARAMS(
"let*: expected an even-length list" +
" of definitions");
vala: remove a redundant parameter
2019-07-15 23:46:55 +03:00
define_eval(iter.data, iter.next.data, env);
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
}
} else if (defns is Mal.Vector) {
vala: expose length/get/set methods for Mal.Vector. Partly, this makes the external API less cumbersome. Mostly, it hides the details of the class's implementation, which I'm about to want to change.
2019-05-12 12:27:30 +03:00
var vec = defns as Mal.Vector;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
if (vec.length % 2 != 0)
throw new Mal.Error.BAD_PARAMS(
"let*: expected an even-length vector" +
" of definitions");
for (var i = 0; i < vec.length; i += 2)
vala: remove a redundant parameter
2019-07-15 23:46:55 +03:00
define_eval(vec[i], vec[i+1], env);
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
} else {
throw new Mal.Error.BAD_PARAMS(
"let*: expected a list or vector of definitions");
}
ast = list.nth(2).data;
continue; // tail-call optimisation
case "do":
Mal.Val result = null;
for (list = list.next; list != null; list = list.next)
result = EVAL(list.data, env);
if (result == null)
throw new Mal.Error.BAD_PARAMS(
"do: expected at least one argument");
return result;
case "if":
if (list.length() != 3 && list.length() != 4)
throw new Mal.Error.BAD_PARAMS(
"if: expected two or three arguments");
list = list.next;
var cond = EVAL(list.data, env);
list = list.next;
if (!cond.truth_value()) {
// Skip to the else clause, which defaults to nil.
list = list.next;
if (list == null)
return new Mal.Nil();
}
ast = list.data;
continue; // tail-call optimisation
case "fn*":
if (list.length() != 3)
throw new Mal.Error.BAD_PARAMS(
"fn*: expected two arguments");
var binds = list.next.data as Mal.Listlike;
var body = list.next.next.data;
if (binds == null)
throw new Mal.Error.BAD_PARAMS(
"fn*: expected a list of parameter names");
for (var iter = binds.iter(); iter.nonempty(); iter.step())
if (!(iter.deref() is Mal.Sym))
throw new Mal.Error.BAD_PARAMS(
"fn*: expected parameter name to be "+
"symbol");
return new Mal.Function(binds, body, env);
}
}
var newlist = eval_ast(ast, env) as Mal.List;
unowned GLib.List<Mal.Val> firstlink = newlist.vs.first();
Mal.Val firstdata = firstlink.data;
newlist.vs.remove_link(firstlink);
if (firstdata is Mal.BuiltinFunction) {
return (firstdata as Mal.BuiltinFunction).call(newlist);
} else if (firstdata is Mal.Function) {
var fn = firstdata as Mal.Function;
env = new Mal.Env.funcall(fn.env, fn.parameters, newlist);
ast = fn.body;
continue; // tail-call optimisation
} else {
throw new Mal.Error.CANNOT_APPLY(
"bad value at start of list");
}
} else {
return eval_ast(ast, env);
}
}
}
public static void PRINT(Mal.Val value) {
stdout.printf("%s\n", pr_str(value));
}
public static void rep(Mal.Env env) throws Mal.Error {
Mal.Val? val = READ();
if (val != null) {
val = EVAL(val, env);
PRINT(val);
}
}
public static int main(string[] args) {
var env = new Mal.Env();
vala: implement a garbage collector. This fixes a lot of memory leakage due to me having relied on the Vala reference-counting system to do my memory management. The most obvious bad result of that design decision was the memory leak from Mal.Nil pointing to itself as metadata. But fixing that didn't solve the whole problem, because other kinds of reference cycle are common. In particular, the idiom `(def! FUNC (fn* (ARGS) BODY))`, for defining a function in the most obvious way, would create a cycle of two objects: from the outer environment in which FUNC is defined, to the function object for FUNC itself, back to that same environment because it was captured by FUNC. And _either_ of those objects could end up being the only element of the cycle referred to from the rest of the system: it could be the environment, if nothing ever uses that function definition, or it could be the function, if that function object is looked up and returned from an outer function that was the last user of the environment. So you can't break the cycle in the way that reference counting systems would like you to, by making a well-chosen one of the links weak: there's no universally right choice for which one it needs to be. So I've fixed it properly by writing a simple garbage collector. In Vala's ref-counted environment, that works by being the only thing allowed to hold an _owning_ reference to any derivative of GC.Object. All the normal kinds of link between objects are now weak references; each object provides a gc_traverse method which lists all the things it links to; and when the garbage collector runs, it unlinks any unwanted objects from its big linked list of all of them, causing the one owned reference to each one to disappear. Now the perf3 test can run without its memory usage gradually increasing.
2019-05-12 12:05:34 +03:00
var root = new GC.Root(env); (void)root;
Add an implementation written in Vala. I needed to learn Vala in order to work on an existing program written in it, and since Ben Harris had been enthusing about mal to me recently, I thought this would be a good way to learn the language. In other words, this is my first Vala project, so I can't promise it's perfectly idiomatic by the standards of experienced Vala programmers! Also, the style isn't all that consistent. For example, sometimes I implement a function for every value type by adding a method to the Mal.Val base class, and sometimes instead I do it by having a function (e.g. pr_str) dynamically test all the possible subtypes in a chain of else-ifs. Those decisions were partly because of the source file structure required by this project (pr_str is supposed to live in its own file); partly because for my own learning goals I wanted to try both strategies and find out how easy they both were; and mostly just because of indecision and bad planning.
2019-05-10 11:34:20 +03:00
Mal.Core.make_ns();
foreach (var key in Mal.Core.ns.get_keys())
env.set(new Mal.Sym(key), Mal.Core.ns[key]);
try {
EVAL(Mal.Reader.read_str("(def! not (fn* (a) (if a false true)))"),
env);
} catch (Mal.Error err) {
assert(false); // shouldn't happen
}
while (!eof) {
try {
rep(env);
} catch (Mal.Error err) {
GLib.stderr.printf("%s\n", err.message);
}
}
return 0;
}
}
Reference in New Issue Copy Permalink