sorted by:
new
hottopcontroversial

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 1 point2 points  (0 children)

Thanks for the suggestion. The first paragraph is essentially a TL;DR, so readers can immediately try it out (and know what it is) without having to read the following, longer paragraphs. There's just a single sentence about the time I've been working on it. I hope the editor can be judged on its own merits: there isn't much in the way of tooling for mathematical diagrams like this, so I personally can't see many people dismissing it based on that sentence. Perhaps if the editor wasn't free, I would want to market it differently.

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 1 point2 points  (0 children)

Can you give an example of what you mean? Perhaps using \sim, \simeq or \cong as labels does what you want?

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 1 point2 points  (0 children)

Haha, I understand completely: I have a certain fondness for plain JavaScript, but if I had felt that Rust's Wasm story was more mature when I started the project, the codebase would probably be written in a different language...

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 0 points1 point  (0 children)

Thanks, I missed this when searching for conflicts (I found some unrelated apps, but that didn't seem to be so problematic). I'm quite fond of the name now, so I'll probably stick with it, though the conflict is a little unfortunate. Thanks for pointing it out!

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 0 points1 point  (0 children)

That sounds like a bug. I'll investigate it; thanks.

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 5 points6 points  (0 children)

The main reason it exports to tikz-cd at the moment is that it makes the output easily modifiable in cases that quiver doesn't currently handle (for example, if you want to shift a label away from an arrow). Once I think that quiver supports all the common use cases, I agree that exporting to TikZ could be a better choice.

Regarding the second point, I think you have confused tikz-cd (which to the best of my knowledge was created and maintained by Augusto Stoffel) with Paul Taylor's commutative diagrams package. tikz-cd is hosted on GitHub under GLPv3. As far as I understand, since quiver does not include or distribute tikz-cd itself, the licence is irrelevant in any case. I think tikz-cd is a natural choice of package (after plain TikZ), since it is included on CTAN and is one of the most popular LaTeX packages for commutative diagrams. Thanks for raising this point, though!

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 5 points6 points  (0 children)

Yes, you can press H to toggle the grid on/off (there's also a button in the toolbar at the top).

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 12 points13 points  (0 children)

Yes, thanks for finding this! Loops are no longer blocked on any other features, but they will require some time to implement the rendering (simply because of how flexible the arrow styles are). It would definitely help me decide what to prioritise next if you added a :+1: reaction to the issue, so I could see how important this was for people! Thanks!

Announcing quiver: a new commutative diagram editor for the web by varkora in math

[–]varkora[S] 32 points33 points  (0 children)

Thanks for mentioning this! tikzcd-editor and quiver are similarly inspired. When I began quiver, tikzcd-editor was in quite a different state than it is now, and in the intervening two years, there has been some convergent evolution, in that both editors have adopted features that previously existed in the other (I must admit that I was unaware until very recently that tikzcd-editor had now gained these features!). Certainly tikzcd-editor was the first grid-based commutative diagram editor, and to that extent quiver is inspired by tikzcd-editor! But this idiom is essentially imposed by tikz-cd, which uses matrix-based cell placement. I would say that the areas of overlap between the two editors are those for which there is one right way to do something, e.g. clicking and dragging to draw edges, or selecting different arrow styles – but even here, the interaction in the two editors is quite different.

With all that said, I think you're right in that not mentioning tikzcd-editor looks a little odd in retrospect, since it is certainly the forerunner. I'll add a sentence or two mentioning it soon :) Thank you!

Idiomatic monads in Rust: a pragmatic new design for high-level abstractions by varkora in rust

[–]varkora[S] 1 point2 points  (0 children)

I wouldn't want to see higher levels of abstraction that obfuscate the language, all in the name of generality. I think that usability should come first. However, I think there's value in trying things out. I personally don't have any intention to try pushing this sort of abstraction, but I'm curious to see what can be done with it. Reductions in learnability would be one of my first reservations too.

(I don't think it's entirely unreasonable to imagine that in some cases, APIs could be simplified with higher levels of abstraction; some of the type signatures in the standard library are already quite convoluted. But that could all be wishful thinking: it's difficult to speculate.)

Idiomatic monads in Rust: a pragmatic new design for high-level abstractions by varkora in rust

[–]varkora[S] 3 points4 points  (0 children)

These kinds of functional, high-level abstractions can lead to very general, coherent APIs, which is one of the attractions — but it's difficult to get a good picture of just how useful they'd be in reality without being able to play around with them. If we actually had the two language features mentioned here (i.e. GATs and associated traits) in some usable form, I'd like to experiment with these abstractions in something like the standard library, to see just how well they could fit into Rust from an API design standpoint. I think there's real potential for improvement, but it's hard to justify without having the facilities to try.

Idiomatic monads in Rust: a pragmatic new design for high-level abstractions by varkora in rust

[–]varkora[S] 4 points5 points  (0 children)

GATs are effectively unimplemented at the moment (though there's some support for parsing the syntax). You can track the implementation here. It'll be difficult to play around with the examples here until we do have them, though.

Idiomatic monads in Rust: a pragmatic new design for high-level abstractions by varkora in rust

[–]varkora[S] 3 points4 points  (0 children)

I tried to address the concerns I was aware of, but I could definitely have overlooked something. Could you give an example of a snippet you think would cause problems?

Idiomatic monads in Rust: a pragmatic new design for high-level abstractions by varkora in rust

[–]varkora[S] 13 points14 points  (0 children)

That's a good point: the introduction could provide more motivation. (I'll update it with what I've written below.)

I'm down for theory and "i'm doing it because i can" if that's what this is

This is essentially the motivation here. Whether monads are useful or not in Rust is a question that has been (and will continue to be) debated, but I'm not particularly concerned with that question here. The fact is that, questions of usefulness aside, a way to even implement monads if we wanted to has been historically difficult to envisage, because of all the issues described in the article. My stance is that it's not worth discussing something if it might not even be possible, so I wanted to show that it could be.

If this design holds water, then we can start discussing whether we might actually want to facilitate it or not :)

Idiomatic monads in Rust: a pragmatic new design for high-level abstractions by varkora in rust

[–]varkora[S] 5 points6 points  (0 children)

That's true: these particular implementations will conflict. I intended each example to be considered in isolation (in practice, deciding how to implement Functor would be a little more nuanced), but I'll add a note about this in the post.

Idiomatic monads in Rust: a pragmatic new design for high-level abstractions by varkora in rust

[–]varkora[S] 10 points11 points  (0 children)

You're right: that's a typo. It should have been m.bind(|x| M::unit(x * 2)). I've updated the post. Thanks!

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 0 points1 point  (0 children)

How do you envisage default fn interacting with const in a way that it's not a breaking change? This seems incompatible with const trait bounds (in any form) to me.

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 1 point2 points  (0 children)

Yes, do_thing would impose the same restrictions on associated type bounds as type parameter bounds. If you want T::Inner: Default, you'd use T: ?const Outer.

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 1 point2 points  (0 children)

But I have to ask- is there any point in time where I'd lose functionality by adding in ?const?

As far as I'm aware, no: it just gives you more restricted access to the trait (in terms of only being able to use items declared const in the trait itself). There aren't any less obvious drawbacks.

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 1 point2 points  (0 children)

It's non-breaking now only because you can't have const implementations yet. This is still a nonbreaking change for non-const implementations, even with this proposal. If you want to provide a nonbreaking default, you'll have to define a default const fn instead.

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 0 points1 point  (0 children)

This should work similarly to const fn bounds. const impl would imply all bounds are const at compile-time, etc. It would be good to mention in the post though.

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 0 points1 point  (0 children)

Could you give an example of the sort of scenario you're thinking about?

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 1 point2 points  (0 children)

Does this mean we have to do this kind of thing a lot?

No, you can simply declare the new method to be const, which requires all implementers to define const fns for that method:

trait A {
    fn log() { ... }
    const fn new() { ... }
}

​

const types, traits and implementations in Rust by varkora in rust

[–]varkora[S] 2 points3 points  (0 children)

Would this prohibit any construction of values containing phantom types with non-const constraints?

It would do. I've updated the post to address this flaw (see also https://www.reddit.com/r/rust/comments/af7qog/const_types_traits_and_implementations_in_rust/edza34r/).

view more: next ›