questions - pannous/warp GitHub Wiki

❓ open questions?

todo

merge todo with questions?

matching by type name

does matching by type name lead to undesired behavior? Ambiguity is ok unless it is detected early and resolvable.

representations

a{x:1} == a:{x:1} solved: last one is key ++ a{x}{y} == a({x} {y}) vs a(x y)

consider

# question
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 it or value

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

repeated symbol execution

In which situations does a symbol get executed multiple times? Answered by charged (P71): square:=x*x is a getter, run at every use. The lines are alternatives, not one program:

square x:=x*x # only once: x is argument
square x=x*x  # only once: x is argument
square:=x*x   # at every use: a getter (P71)
square=x*x    # only once: x is context variable, or twice?

Related :

tainted io arguments

Todo Pure functions can/cannot? be tainted by io arguments

# question
square x:=x*x # pure
square random # pure: random is only invoked once as argument
square random() # same
vs
square [&](/pannous/warp/wiki/&)random # square the FUNCTION random, not it's return value
square &random == random()*random()

gap filling

gap filling is probably a bad idea What is the point of providing arguments, when unbound external symbols are resolved anyways?

# not yet: parameters fed from same-named locals (card gap-feeding)
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 :=

binding of 'in' operator

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

early operator notation or late expression evalutation

a{x:1} != a {x:1} but {x:1} becomes child of a
a{x:1} == a:{x:1} ?

fundamental data type

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 peter the 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:

  1. for index i of xs
  2. for property x in xs ==
  3. for x of xs

The seemingly harmless variants

  1. for key, value in xs
  2. 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 with for index i,v of xs in which case even the index of wife is returned as a number (3)

suffix function operator precedence

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) ?