- what exactly the
run_liftandeval_statefunctions do - how the
modifyandgetfunctions know which effect to use - what
let eff_open : Eff [| eff_1 : Eff1 | r |] () = ...means. what does the()at the end of the type mean, and is...some kind of expression or a placeholder?
what exactly the run_lift and eval_state functions do
They run/evaluate the effects and output (return) the result
how the modify and get functions know which effect to use
That is encoded in their type signature https://gluon-lang.org/doc/nightly/std/std/effect/state.html#value.modify
1 reply
1 reply
what let eff_open : Eff [| eff_1 : Eff1 | r |] () = ... means. what does the () at the end of the type mean, and is ... some kind of expression or a placeholder?
Eff a is a monad just like IO is a monad, so Eff a b is a monad that evaluates to b just as IO b is a monad that evaluates to b
I want to type-check a Gluon function with runtime-defined simple record type.
So I iterate over function arguments and compare them using ==.
It works with basic types but not with records.
If I print both expected and function ArcTypes with Debug fmt, I see that both are the same, only Symbol addresses are different.
I generate expected ArcType using following code:
pub fn get_gluon_type(vm: &Thread, t: &ConfigArgsType) -> ArcType {
.......
ConfigArgsType::Struct(item_types) => {
let mut fields = Vec::new();
for i in item_types {
let name = gluon::base::symbol::Symbol::from(i.name.as_str());
fields.push(gluon::base::types::Field::new(
name,
get_gluon_type(vm, &i.arg_type),
));
}
let type_cache = vm.global_env().type_cache();
type_cache.record(Vec::new(), fields)
}
......
}What am I doing wrong?
Symbol has pointer equality, so having the same stringified name is not enough
Symbol::from should probably be removed, I think it is only used for tests
Symbol as those should be compared by string
== compares them by string
fn gluon_type_compare(got_type: &ArcType, expected_type: &ArcType) -> bool {
if got_type.is_non_polymorphic_record() && expected_type.is_non_polymorphic_record() {
let got_type_iter = got_type.row_iter();
let expected_type_iter = expected_type.row_iter();
if got_type_iter.len() != expected_type_iter.len() {
return false;
}
for (got, expected) in got_type_iter.zip(expected_type_iter) {
if !got.name.name_eq(&expected.name) {
return false;
}
if got.typ != expected.typ {
return false;
}
}
} else {
if got_type != expected_type {
return false;
}
}
true
}
gluon-lang/gluon#858
In the end it links to this merged PR (gluon-lang/gluon#861), does that mean that gluon is as fast as lua now?
And what about compilation speed/latency for recompilation? I found this comment: https://www.reddit.com/r/rust/comments/rto49q/rune_vs_rhai/hqv3olz/
Gluon is pretty good other than it's not that easy to work with and takes a long time to compile/link.
How long does it take to compile/link a program that consists of N lines (or N symbols/definitions)?
:point_up: February 20, 2019 2:12 PM
I'd like to get it to the point that you could load a file of precompiled gluon just as easily as a normal script file
And the standard library should be distributed in precompiled form as well so that user scripts could avoid that cost
So currently the whole std lib is recompiled whenever a user script is recompiled? Does that mean the gluon edit/compile cycle is too slow for livecoding?