![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
might want a syntax for 'apply this code transformation with the scope of this entire function'. Eg might want to say: ^ref a to declare that the variable 'a' will be addressed by reference, eg:
a = 3 y = f(a)
should be transformed to:
(and of course the language is handling memory management and initialization here)
---
i guess one principal of Oot syntax is that we eschew keywords and use punctuation instead for core language language-y things (but not just for primitive operations, like Hoon does). This has a few benefits:
---
when i explain my idea that local mutations are okay, but what you don't want is aliasing between variables across different functions, i use the demonstration that:
a = 3 a = f(3) y = g(a)
can be transformed into
a_1 = 3 a_2 = f(a_1) y = g(a_2)
that is, go thru the fn one line at a time, and upon each assignment to a, increment a counter i and then do a search-and-replace over the rest of the fn below that line, replacing a with a_i
note that this is a local (function-local) transformation.
i notice that my proposal for reference variables is also such a transformation. And that i proposed a syntax like ^ref for that transformation.
this suggests that we should let the user define other transformations and apply them eg ^users-custom-transform-name to the function scope.
---
consideration of the 'function scope' brings into focus the point that in Haskell and Lisp, there is no 'function scope', there are just expressions, some of which produce first-class functions which are bound to identifiers.
so i guess part of the (syntactic) idea of these languages is that there is no such thing syntactically as a 'block' of statements, there are only expression trees. But both of them actually provide block-like constructs, do notation in haskell and progn in lisp.
so this is an argument for us providing blocks.
the opposite conception might be eg javascript, where variable declaration 'hoisting' use function scopes.
functions of course are 'above' blocks in a sense, in that you might have a sub-block within a function, syntactically, eg if you have blocks delimiting then/else in an if/then/else, or delimiting a while loop, etc. Most likely ppl would like transformations such as mutable variables and by-reference variables to be function-level, not just block-level.
so perhaps we should provide function scoping for this.
---
F# has an interesting, straightforward syntax for declaring properties:
public class PiggyBank?{ public PiggyBank?(int coins){ Coins = coins; }
public int Coins { get; set; }}(from https://msdn.microsoft.com/en-us/magazine/ee336127.aspx )
now, i think everything should be properties in Oot, but the F# syntax is still neat/worth noting.
---
mb no need to waste uppercase on labels, labels are rare, so mb we can use uppercase just to distinguish keywords from annotations?
---
if we have annotations, maybe eg "^ref a" can mean that ^ref is an annotation. Or maybe "^ref(a)" is better to make it clear that 'a' is not in the base part of the AST (it's part of the annotation).
And mb just use uppercase for annotations:
REF(a)
(leaving capitalization for keywords: f(Keyword-a))
nah, let's have upper for keywds and caps for annotations:
Ref(a)
f(KEYWORD-A)
---
y'know, could distinguish multiple grouping constructs from one symbol by repeating the opening two or more times in a row, since there's never a reason to do that 'for real'. Eg [[image: ?]] could be different from { }. And (( )) vs ( ).
to make that easier to remember, the multiple repeats could only be used for 'big' versions of the single ones.
eg maybe use (( )) for 'parens until explicit close' (as opposed to ordinary parens, ( ), which are implicitly closed at the end of a paragraph). And maybe use [[image: ?]] for 'big block', which functions like a 'function scope' in that many metaprogramming constructs are implicitly scoped to the enclosing big block.
---
colon for namespace prefixing? or just period?
---
should a trailing period, eg 'y.fieldname.' mean anything?
some ideas:
---
so far i like the assertion the best
---
mb y..fieldname is the syntax for referring to the edge connecting 'y' and 'fieldname' and how, then, to refer to the ports of this edge? mb: e = y..fieldname; psrc = ..e; pdst = e.. yeah i like that. any use for y.fieldname. now? is a port really just a second order edge? what about roles for hyperedges? my guess is: yes; hyperedges need more syntax, this is just convenient syntax for the typical case of ordinary edges (mb the syntax for hyperedges is y.(role).edgenamee; no wait arent roles just like fields in the reified edge anyways?
---
" let squareOfEvens = numbers
| > Seq.filter IsEven? |
| > Seq.map Square |
The only confusing part about this code may be the
| > operator. This operator is used to make code more readable by allowing you to reorder the arguments to a function so that the last argument is the first thing that you read. Its definition is very simple: |
let (
| >) x f = f x |
Without the
| > operator, the squareOfEvens code would look like this: |
let squareOfEvens2 = Seq.map Square (Seq.filter IsEven? numbers)
" -- https://msdn.microsoft.com/en-us/magazine/ee336127.aspx
---
actually i guess mb we dont need hypergraphs -- the 'roles' in hyperedges make them just like nodes-as-dicts anyways, no need to have two kinds of entity instead of 1
so we still need a way to select an edge, at least, the trailing edge. So maybe y.edgename. after all (y.edgename selects the destination node, y.edgename. selects the edge itsel)
could use a..b..c to select a path (what about a..b.c..d? a disjoint selection?)
still need a syntax to construct immutable value graphs with cycles (eg without directly using the & ptrs syntax because these are values, not references). Maybe just use && though!
---
