3 ms·
I find the differing syntax between function and variable storage to be interesting. Is there any particular reason these aren't unified? Assuming anything in b
by jdmichal 11y ago
I find the differing syntax between function and variable storage to be interesting. Is there any particular reason these aren't unified? Assuming anything in brackets is a first-class "function" object, something like this should be possible:
2 /two define
{ two add } /addTwo define
- protomyth 11y agoThat looks quite a bit like Postscript.
- Drahflow 11y agoThe storage is exactly the same, the difference is only in what will happen if the name is encountered somewhere. { 2 } /putTwoOnStack deff { 2 } /putClosureOnStack defv putTwoOnStack dump # 2 putClosureOnStack dump # <function 0006002514AE5> putClosureOnStack * dump # 2
- couchand 11y agoI'm not convinced the distinction is valuable. Since you already have * and {} you don't really need two distinct variable types.
- Drahflow 11y agoI think it's a good thing (tm) that { x sin } could be valid code with x pushing the value of x whereas sin is executing the value of sin. Theoretically speaking, I need at least the deff and defq distinction, otherwise { } could not be invoked during "parse" time. The defv case could in principle be removed, but as * needs to execute (otherwise nothing ever will), execution would need to be the default or I would need to decide based on dynamic type. The first option would mean a lot of superfluous {} (or | actually) around normal data variables, the second one would destroy the nice similarities between arrays, strings and functions with integer domains.