3 ms·

``` let outer = args .get("outer") .unwrap_or(&"1.0".to_owned()) .parse() .unwrap(); ``` Is this the syntax you want users

``` let outer = args .get("outer") .unwrap_or(&"1.0".to_owned()) .parse() .unwrap(); ``` Is this the syntax you want users to write? I...don't find it very readable.

properparity 5y ago
Oh jesus, the model code is in rust? I was assuming a dsl with kernel in rust.
- sitkack 5y ago
  I don't think that is a big issue at this time. The Rust code would be building a data model in memory, one could easily do an internal DSL or call it from an external language.
  - hannobraun 5y ago
    Exactly. All a model does, is build a C-ABI-compatible data structure. And even though Rust is currently the only language supported, Fornjot is architected to be language-agnostic. I don't think Rust is the ideal language for this problem, but with Fornjot itself written in Rust, it was the easiest one to support. Gotta start somewhere.
adamsvystun 5y ago
They have to start with what's the easiest to implement, and if their kernel is in Rust, then the easiest frontend is in Rust. From their FAQ [1]: > Fornjot is architected to be language-agnostic, and adding support for other languages should be relatively straight-forward, actually. Hopefully one day, there will be a selection of interoperable Fornjot frontends, so you can choose the best language for your model. [1] https://www.fornjot.app/faq/ https://www.fornjot.app/faq/
hannobraun 5y ago
Well, no. But it's what we currently have. As adamsvystun notes, I have to start somewhere. Making models more convenient to define is planned (https://github.com/hannobraun/Fornjot/issues/72 https://github.com/hannobraun/Fornjot/issues/72), support for other modeling languages is on the wishlist (https://github.com/hannobraun/Fornjot/discussions/146 https://github.com/hannobraun/Fornjot/discussions/146).
- smallerfish 5y ago
  Maybe you can document your ideal so that you have something to work towards?
  - hannobraun 5y ago
    Some of that documentation exists in the issue tracker. But that vision is something I refine as I learn more about use cases and the problem space. So it's not like I can just write down the ideal state right now :-)

``` let outer = args .get("outer") .unwrap_or(&"1.0".to_owned()) .parse() .unwrap(); ``` Is this the syntax you want users to write? I...don't find it very readable.

properparity 5y ago

Oh jesus, the model code is in rust? I was assuming a dsl with kernel in rust.

sitkack 5y ago
I don't think that is a big issue at this time. The Rust code would be building a data model in memory, one could easily do an internal DSL or call it from an external language.
- hannobraun 5y ago
  Exactly. All a model does, is build a C-ABI-compatible data structure. And even though Rust is currently the only language supported, Fornjot is architected to be language-agnostic. I don't think Rust is the ideal language for this problem, but with Fornjot itself written in Rust, it was the easiest one to support. Gotta start somewhere.

adamsvystun 5y ago

They have to start with what's the easiest to implement, and if their kernel is in Rust, then the easiest frontend is in Rust. From their FAQ [1]: > Fornjot is architected to be language-agnostic, and adding support for other languages should be relatively straight-forward, actually. Hopefully one day, there will be a selection of interoperable Fornjot frontends, so you can choose the best language for your model. [1] https://www.fornjot.app/faq/ https://www.fornjot.app/faq/

hannobraun 5y ago

Well, no. But it's what we currently have. As adamsvystun notes, I have to start somewhere. Making models more convenient to define is planned (https://github.com/hannobraun/Fornjot/issues/72 https://github.com/hannobraun/Fornjot/issues/72), support for other modeling languages is on the wishlist (https://github.com/hannobraun/Fornjot/discussions/146 https://github.com/hannobraun/Fornjot/discussions/146).

smallerfish 5y ago
Maybe you can document your ideal so that you have something to work towards?
- hannobraun 5y ago
  Some of that documentation exists in the issue tracker. But that vision is something I refine as I learn more about use cases and the problem space. So it's not like I can just write down the ideal state right now :-)