Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
As usual, I understand only like 20% of it, but I find it interesting 😄
How is a vector based tuple supposed to work?
AFAIK vectors have components or elements of the same type, like arrays. But tuples can have different types for the individual elements.
Do you want to use type erasure? -
@lorentz Since tuples can be thought of as anonymous structs without methods (just data), why not implement them as such?
-
@Lensflare I don't have structs yet but they'll probably be implemented as named tuples. Unless I give in to the temptation of simplicity and just use a dictionary of interned strings like JS.
-
@lorentz I see many issues with the simple approach. For example, in dictionaries the order doesn’t matter but in tuples, it does.
And structs should be value types. Tuples and dictionaries should be value types as well, but they are not in JS. -
@Lensflare I meant that structs might be implemented as dictionaries or tuples. Tuples are definitely vectors.
Orchid is completely immutable, the distinction between value and reference types doesn't exist. -
@lorentz
> I meant that structs might be implemented as dictionaries or tuples.
Yes.
> Tuples are definitely vectors.
Why? I have troubles to understand that because of different types vs. same types.
> Orchid is completely immutable, the distinction between value and reference types doesn't exist.
That’s interesting. So it’s purely functional?
Related Rants
Orchid lesson #many:
Church tuples exist only to demonstrate how general substitution is. Just like Church numerals, they aren't meant to be used for real computation and cause a lot of problems. Few type systems and fewer optimizers can deal with them, they're a pain to pass through FFI boundaries, and they're much slower in an interpreted context than a native smart array. And in a lazy language the tuple is almost always lighter than the code that generates it, so you want to generate the tuple eagerly and thunk the actual elements, if thunk you must.
I'll go write a vector based tuple and end this madness tomorrow. New version soon, probably.
With dynamic dispatch.
rant
orchid
langdev