4 ms·

What is it that gives you problems? The first example mainly uses a method chaining style of programming which might throw you off? Or maybe the use of lambdas?

• mjburgess 3y ago
  I've included just a light rephrasing below, of the first part of the first link -- but with a better design we could radically reduce it much more. Nevertheless, I find the below less of a visual assault, use rustpython_vm.. builtins.PyDictRef, py_compile, py_serde, scope.Scope use rustpython_vm.. InitParameter, Interpreter, PySettings, VirtualMachine use rustpython_vm.pyobject.. ItemProtocol, PyObjectRef, PyResult use logic.. ProgramError, ProgramResult setup_scope :: (vm: ref VirtualMachine) -> PyDictRef = let code = vm.new_code_object(run py_compile( file = "stdlib/rumblelib.py", module_name = "rumblelib" )) let attrs = vm.ctx.new_dict() let run : () -> PyResult[None] = fn return? attrs.set_item("__name__", vm.ctx.new_str(own "<robot>"), vm) return? vm.run_code_obj(code, Scope.with_builtins(PyNone, clone attrs, vm)) let sys_modules: PyDictRef = v unwrap vm.get_attribute(vm.sys_module.clone(), "modules") .downcast() .ok() .expect("sys.modules should be dict") return? sys_modules.set_item("rumblelib", clone attrs as object, vm) return ok(None) vm.unwrap_pyresult(run) return attrs py_to_serde(type T) :: (py: ref PyObjectRef, vm: ref VirtualMachine) -> ProgramResult[T] let val = return? py_serde.serialize(vm, py, serde_json.value.Serializer) let out = return? serde_json.from_value(val) return ok(out)
  • laeri 3y ago
    The `return?` idea of yours is nice as the `?` operator at the end might be overlooked but is a significant control flow operation. Some of your potential syntax changes seem less readable but they might look nicer to you such as changing `attrs.clone().into_object()` into `clone attrs as object`. You probably come from a python background I would assume but the rust version is easier to parse and understand but maybe to you not visually appealing. Having an explicit return argument I could understand. I found this weird in the beginning but this is something I got accustomed. Not sure why square brackets should be favored instead of angle brackets. The imports in the Rust version are also very explicit and fine I think. Replacing `()` with `None` seems silly, same with replacing `Ok` with `ok`. Maybe the `py_to_serde` arguments of the function definition spanning 4 lines could be considered unastethically pleasing. This is something I noticed quite a lot with Rust code. Fmt also seems to break to multiple lines quite fastly when writing function or method definitions.
    • mjburgess 3y ago
      I find `<>` are visually distracting and take up far too visual space for their importance. `F[X]` is less arresting than `F<X>`, the thin vertical lines melt-away easier. I replaced () with `None` (& with ref, ! with run, etc.) because I want code to read like english (ie., literate) all other things being equal. I dont find `()` "pays the cost" of illegibility by syntactical convenience. Changing "operator-like methods" to operator words would have a radical impact on the parsing precedence and "overall look" of the lang. ... so `clone ...` would be more readable if those changes were made. The advantage of many keyword primitives is that you dont keep reusing the same syntax for everything... syntax is there to support expression. I think more is better. `Ok()` to `ok()` was more a broad notational philosophy of basic type constructors being unobtrusive. Scala has gone from C-like (v2) to python-like (v3) syntaxes --- and I think the ML-ish whitespace, python-ish "beat poetry" approach is mostly just better. I buy some arguments that symbolic redundancy can help (ie., both indent and use symbols)... but Rust's syntax philosophy is clearly to "keep adding symbols", and I dislike it. C uses symbols, but I do think C is quite beautiful mostly -- because it's so simple. Rust is creaking under the weight of its size and symbolic choices
      • 3y ago