-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convenient syntax for shuffling (incl. removal) of values on the stack #1
Comments
The "yet another idea" would then look like the following.
with convenient shuffling:
Btw. if lambdas allowed explicit arguments like Another question (admittedly only partially related and significantly less important than shuffling) is how default argument values could be supported without introducing the ferocious |
Interesting idea. For sure I'll think about it to make stack shuffling easier. It already should be easy as variables can be captured not only at the beginning of the function but anywhere in the code. You can:
but this will overwrite variables x a b c if they were defined before in the foo function. With lambdas, this will not happen.
I don't have yet any plans for handling empty/missing values. BTW: thanks for the info about Quark. |
I'm thinking about adding specialized stack shuffling syntax similar to Quark.
It will support only one letter aliases BUT I think that the syntax is:
|
That's great news, thanks!
Hm, could this be lifted? Maybe This is to use already existing names as in my opinion that'll be almost a necessity considering Morty's coolest feature are "argument names as variables". My assumption is argument names will be ubiquitous as that's more or less the easiest way how to nicely structure programs written in Morty (and besides everybody loves names 😉). What do you think? |
Hmm, I'll think about it. Efficient stack machine code should avoid shuffling BUT since it makes programs more readable I want to provide some shuffling mechanisms. Mechanism a) can be used when values are already captured into named variables. Your example with mechanism b) would look like When I was designing local variables I was thinking about allowing just function parametrs to be named.
|
True. I forgot about this. Looks actually good to me though I'm afraid if this won't be optimized away by the compiler, it might be slower than Regarding "both - named params and local variables" functionality I'm a bit confused what the difference between a named param and a local variable is in this context. Could you clarify? Intuitively I'd say named params are local variables but their naming is enforced at the call site somehow (this is being usually used for default values of arguments). But I'm unsure you meant exactly this. |
Yes, local variables are not as easy to optimize. Named params on the other hand are easy to optimize (all named params can be captured in a single vm instruction) but still, shuffling expressions are the easiest to optimize.
Named parameters can be captured only at the beginning of the function. The capture can be optimized (all params in one vm instruction) and more natural ordering can be used: function with the signature With named params stack reshuffling with lambda functions will look more natural:
BTW: the "dot notation" is just an example - most likely the notation will be different. |
Ah, now I see. Thanks for explanation! In that case I'd prefer to support both named params as well as local variablles. But because named params can be "efficient enough" or even identically efficient, I'd abandon special syntax for shuffling. |
@antirez I just read your readme in https://github.com/antirez/aocla and thought you might be interested in knowing there was definitely some prior art to the "local variables" 😉. I am pretty sure many people came up with such ideas but not many tried to implement it and thus we might have not heard about their thoughts. |
I like how Morty approaches the "implicit" stack content (with comments in parens). There is one more thing which is verbose in stack languages and at the same time potentially inefficient. Namely shuffling of values on the stack if they're not in the order one needs them.
I was looking for a way how to solve it and found Quark with its stack manipulation syntax.
I think it's worth thinking about making such shuffling easier for the user (actually the fact, that all "functions" in Morty depend on the order of arguments becomes the main driver behind this need).
Another idea would be to not introduce generic stack manipulation syntax, but rather a built-in function with variable number of arguments which would do the shuffling.
Yet another idea would be to simply allow special shuffling syntax only at the place when calling a function. Basically saying "if the function is called without explicit arguments, it behaves like standard combinator, but if it's called with at least one explicit argument it's regarded as these were first popped from the stack and then passed explicitly as arguments (this latter case would allow for compile-time check whether the number of arguments is correct which could improve general app safety).
Btw. there are some other more or less crazy ideas in henrystanley/Quark#2 . Feel free to take a look 😉.
The text was updated successfully, but these errors were encountered: