(Our assembly language target doesn't support branch-to-address, and there is no heap, so the possibilities are quite limited.)
Conversation
oh. Yeahhh uhh solving upwards funargs with no dynamic memory allocation sounds hard.
I would probably not say those are closures.
2
1
Yep, I've called them "lambda functions" and explicitly said they aren't closures. Does that sound fine?
2
tbh I don't remember, if I ever knew, what features the formalism that name got borrowed from requires for functions
1
1
To your mind, does a "lambda function" intuitively require the possibility of closure?
1
None of the languages I use day to day use that term, so I would mentally translate it into something more familiar like "closure" or "block" and then be a little startled when I couldn't capture anything.
Swift calls these "thin closures", but I think that's one we made up.
2
2
unfortunately, the language I'm implementing calls functions "procedures", so things get hairy fast
1
1
(the original language does not allow return values, but I added it on top)
1
1
Tbh if the functions are side-effecty, I'm completely on board with the 'procedure' naming!
I tried to get rid of all greek-letter-named stuff in Pikelet and just call things 'functions' and 'pairs' etc.
If I had it my way (tuples and non-primitive return types) there'd be no need for side effects, but alas...
1
1
(I don't have anywhere near enough time to implement these 🤣)
1
Show replies