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
The 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 # putClosureOnStack * dump # 2
Show HN: Self-hosted stack-based programming language
21–24 of 24 posts
Re: Show HN: Self-hosted stack-based programming language
#22Earlier quoted context omitted.
The 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 # putClosureOnStack * dump # 2
I'm not convinced the distinction is valuable. Since you already have * and {} you don't really need two distinct variable types.
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.
Re: Show HN: Self-hosted stack-based programming language
#23"tsch" ==pa
pa dump
# "tsch"
Re: Show HN: Self-hosted stack-based programming language
#24Can I do this with strings as well? "tsch" ==pa pa dump # "tsch"
|dump =*clap
[ "pa" |dump /tsch 0.0 ] ==slow slow clap
# [
# "pa"
#
# "tsch"
#
# +0.0e0
# ]