Over the weekend, I realised, extremely belatedly, that the expression language I designed for my free-software project
spigot has a grammar bug. Specifically, it's a context-dependency analogous to the C typedef bug: the same expression can parse differently depending on whether a given identifier is currently defined to be a function or a
(
Read more... )
And you manage to make it look like coincidence that you say this just below deborah_c's comment about Fortran! :-)
Or, programmers could suck it up and figure out a way to use different sorts of bracket for "invoke function" from "collect expressions together" :)
Oddly, I did have the weird thought some time last year that - at least for functions in the true mathematical sense, i.e. no side effects and always the same output for the same input - square brackets might be quite appropriate in a computing context.
Because, mathematically speaking, a function is a static collection of (input,output) pairs, i.e. it's basically the same as an array or dict/map/hash - better yet, an immutable one. So it should have the same syntax as an array lookup!
The fact that in programming the thing we call 'function' computes each result on demand whereas 'map' stores them all in advance is a mere implementation distinction, not affecting the semantics of the operation, so it's OK to relegate it to not being flagged up by a mandatory syntactic distinction. (Indeed, the difference between the two kinds of thing is already blurred in languages like Python, where on the one hand you can subclass dict to make it automatically fill in values for missing keys on the first access attempt, and on the other hand, decorate functions to make them automatically memoised.)
Of course, the other meaning of 'function' in programming - the mechanistic one of 'save all my current state, go off and run arbitrary other code, come back with or without a return value, who knows what happened in between' - doesn't give rise to the same argument...
Reply
Leave a comment