Replies: 8 comments 13 replies
-
|
Hi @llogiq, glad to hear that you're trying out Koto! I'm sorry that the docs are missing here, I started a documentation effort on the I agree that making custom types is a bit cumbersome at the moment, especially without a guide.. My thinking is that I'd like to make sure the fundamentals are correct and the implementation straight-forward, and then some more ergonomic helpers can be added to make usage a bit friendlier. I'll try to clarify the current approach:
If I understand you correctly you'd rather expect that the If I've got that right I think I would rather extend the type via an embedded Does that make sense? I can see some value in inverting the approach here, it might make the expected usage more explicit (although maybe utilities and docs will help there). |
Beta Was this translation helpful? Give feedback.
-
|
Adding a |
Beta Was this translation helpful? Give feedback.
-
|
Yes I can see an advantage there, it'd be cheaper to clone the interface map than having to rebuild it for each new value. |
Beta Was this translation helpful? Give feedback.
-
|
I have started a WIP PR #64. Do you think this is the right direction? |
Beta Was this translation helpful? Give feedback.
-
|
Yes I think this is roughly how I would expect it to look, I appreciate you diving in! I'm still unsure if I want to proceed in this direction though. The main concern I have is that this will introduce a new object-like-thing to Koto, and I’d like to avoid that if possible. I'm thinking about an alternative solution which would be to extend
/// The Map value type used in Koto
#[derive(Clone, Debug, Default)]
pub struct ValueMap {
data: Arc<RwLock<ValueMapContents>>,
immutable_data: Option<Arc<RwLock<ValueHashMap>>>,
external_data: Option<Arc<RwLock<dyn ExternalValue>>>,
};…and Something I like about this is that modules like could expose their features as immutable. It’s never really felt right that there’s nothing to stop a user from saying …and I haven’t figured out a few details of the expected behaviour of map operations over a mix of mutable and immutable entries (like how map operations should apply), but I’d need to start playing with some examples to get a feel for the right direction. |
Beta Was this translation helpful? Give feedback.
-
|
The downside of this would be another layer of indirection (and a map) for each ExternalValue. I might live with that, but I'd like to try this variant, too and see how large the overhead really is. I think the only thing left in this PR is the method call protocol. Can you give me a pointer where in the code to change this? |
Beta Was this translation helpful? Give feedback.
-
I think the only additional indirection here would be the I think the key thing for me is to make sure that the semantics of an external value type are clear to the user. So far this has been achieved by wrapping up external values in Maps, so I'm trying to see if that can be maintained before extending the number of concepts in the language. Types with overloaded operators are just Maps, modules are just Maps, etc.. Now, it could be that behind the scenes there are different flavours of Map (data-only, overloaded operators, immutable, externally defined value), and then conversions happen on demand based on usage. I went in this direction with Number (which switches between Int and Float) and I have in mind potential optimizations along these lines for List (e.g. a List of Numbers takes up less space than a List of Values). So I wouldn't be too worried about performance at this stage, I'd prefer to focus on getting the general design right before optimizing.
You'll need to extend |
Beta Was this translation helpful? Give feedback.
-
|
I understand that you want to keep the language simple, and yes, allowing an enum of Single-key-value, map would make most of the overhead moot. There would still be some memory overhead, but I think that shouldn't affect us too badly. But that's just conjecture at this point, we'll know when the measurement's in. Thanks, I'll look into |
Beta Was this translation helpful? Give feedback.
-
|
It occurred to me that having a non-optional I'm still mulling over the options here, I haven't decided if I'm comfortable with having an 'external vs internal' split for object-like-things. It seems to me that both variants will want roughly the same feature set in the long run (locked vs unlocked, meta functions, etc.) so my natural inclination is to keep them unified. I can certainly see the need for improving the current situation though. I'm busy today but hoping to give this topic some proper attention tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
There is some prior art in the lua implementation; they have userdata and lightuserdata. |
Beta Was this translation helpful? Give feedback.
-
|
@llogiq I hope you don't mind but I figured the topic was worth moving over to a discussion while we continue to discuss the design of a solution. I'm curious to hear about the project that you're integrating Koto into? Is there anything you can share about it? |
Beta Was this translation helpful? Give feedback.
-
|
Sure! We are building a configuration DSL for synth which at some point would also include expressions and functions, so I looked at a few lang impls and liked koto best so far. |
Beta Was this translation helpful? Give feedback.
-
|
Nice, looks interesting, and great name 😄! Let me know if you run into any problems. You're welcome to start discussions here asking general questions about the language, and you can also contact me by email if you prefer. |
Beta Was this translation helpful? Give feedback.
-
|
I think I'm getting towards a design that I'm happy with:
The main advantage of this approach is that external values would then also be able to define meta behaviour like overloaded operators. To extend the idea:
@llogiq How does this sound to you? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, so basically I need to amend my PR to change the ValueMap vtable to a MetaMap (once that has arbitrary string keys), and then it's at least the third part. I think this plan makes a lot of sense, and hope I can help to bring it to fruition. |
Beta Was this translation helpful? Give feedback.
-
|
Great, I think it makes sense for me to start a branch in the next days that implements the MetaMap changes (I think there'll need to be some hoop-jumping to access the entries efficiently with |
Beta Was this translation helpful? Give feedback.
-
|
Perfect! Just give me a ping when I can rebase my PR on top of your work. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@llogiq I've just merged #69 which includes named meta entries and should work as a foundation for the
Re-reading this reminded me that I left a |
Beta Was this translation helpful? Give feedback.
-
Done in #70. |
Beta Was this translation helpful? Give feedback.
-
|
@llogiq I finally managed to get to implementing a new |
Beta Was this translation helpful? Give feedback.
-
Hi there. I'm experimenting with embedding koto in another crate, and I feel the protocol around ExternalVaues (as showcased in the example; to my knowledge there are no other docs) is quite cumbersome.
I have built a procedural macro that can insert Rust functions into a given prelude, however, I'd like to also extend it to derive support for my own types (perhaps in conjunction with the proc macro also setting up a kind of vtable). What do you think about simplifying this interface to an
ExternalValue+ aBox<dyn fn(KeyValue) -> ExternalFunction>that will do the vtable dispatch? This might both be faster and easier to code against.Beta Was this translation helpful? Give feedback.
All reactions