-
-
Notifications
You must be signed in to change notification settings - Fork 4
questions
merge todo with questions?
does matching by type name lead to undesired behavior? Ambiguity is ok unless it is detected early and resolvable.
a{x:1} == a:{x:1} solved: last one is key ++ a{x}{y} == a({x} {y}) vs a(x y)
consider
get first character in string
get first 'a' in string
both have different signatures and semantics the first returns a character the second returns a position of a character
is this conceptually fixable?
property age with implicit getter (value) and setter:
age:set{value=it} OR
age:set{it=value} ?
The preferred style is a free declaration:
To set the age of a person: value be it OR
To set the age of a person: it be value OR
To set the age of a person: its value be value ?
the keyword value represents the internal value of the property
the keyword it represents the argument to the setter of the property
arbitrary keys in pairs
hash={peter:123} # symbolic peter
hash[peter]=123 # reference peter
In which situations does a symbol get executed multiple times?
square x:=x*x # only once: x is argument
square x=x*x # only once: x is argument
square:=x*x # twice (or never if kept symbolically)
square=x*x # only once: x is context variable, or twice?
Related :
Todo Pure functions can/cannot? be tainted by io arguments
square x:=x*x # pure
square random # pure: random is only invoked once as argument
square random() # same
vs
square [[&]]random # square the FUNCTION random, not it's return value
square &random == random()*random()
gap filling is probably a bad idea What is the point of providing arguments, when unbound external symbols are resolved anyways?
f y:= y*y+v
f(y=2,v=3) # 7
y=2,v=3;f() # 7
be vs is assignment
square = x*x # error: unknown symbol x OR treat as :=
indexing operators '#' 'in' and 'of'` bind tightly, so
1 + 1 in {1:2} == 1 + {1:2}['1'] == 1+2
TODO: REALLY ?
1 + 1 in {1:3} == (1+1) in {1:3} == false
Solution: compiler error: mixing evalutations needs grouping
a{x:1} != a {x:1} but {x:1} becomes child of a
a{x:1} == a:{x:1} ?
we found that lisp lacked the builtin map primitive, all map implementations feel like second class citizens. we found that triple stores rarely lacks support for n-tuples like "yesterday the green cat jumped over the black fence". Even mixing attributes and properties begs the question: How to coherently combine these concepts, especially when iterating. let's say we have Peter={ funny, smart, wife=Jule} when we iterate over peter, how to make sure that the value of wife is not overlooked? should we support error prone js iteration? The attributes funny, smart can act both as keys and values:
- Peter[0] == funny
- Peter[funny]=true
the first variant seems not natural and thus should receive a special syntax.
for each index in peterthe other one should be default:
for each property in peter
for each key in peter
for each value in peter sic!!
for each attribute in peter
for each field in peter
for each property of peter
for each key of peter
for each value of peter sic!!
for each attribute of peter
for each field of peter
or, consistent with java script: just
for x of peter
That sounds like a solution to the mixed iteration problem: Using js for i in xs yields a compiler warning or error: "iteration over index needs special qualifier, did you mean:
- for index i of xs
- for property x in xs ==
- for x of xs
The seemingly harmless variants
- for key, value in xs
- for key k in xs
still beg the question if the key of attributes is its index or itself:
- Peter[funny]=true
- Peter[0] == funny
solution: the last case only arises withfor index i,v of xsin which case even the index of wife is returned as a number (3)
Todo : do functions and their corresponding suffix operators have the same precedence? I.e. does
square 1+2 == 1+2 squared
square 1+2 == 1 + (2 squared) ?