Talk:Smartboxes

I'm probably going to write a Hoon implementation at some point. Though in that case I'll borrow the local convention of %literals (besides numbers, I suppose I could just reuse the canonic literal parser), and probably let it hook all the native methods since the FFI is so straightforward. --198.188.4.4 19:05, 9 April 2014 (EDT)

What is Hoon? --Ørjan (talk) 10:30, 11 April 2014 (EDT)

A language these guys are using to implement a replacement for the unix stack, currently sitting atop it. Hoon itself compiles to Nock, a turing tarpit that is made into slightly less of one by pattern-matching which replaces inner loops(such as math) with native code. Somehow. All I know is it runs as promised --Zerk (talk) 15:01, 11 April 2014 (EDT)

Implicit evaluation

Namely, I propose we get rid of it. Well, not exactly: variables are already scoped to their bindings at compile time, symbols could similarly be looked up outwards by name until they hit non-nil, the outermost map being the parser. But maps themselves should evaluate to literals, and only subject to unification.

Paren syntax sugar would also be useful

 square(add(1 3)) => {[let _ _] _:-[let _1 add._];->square._1}.[1 3] => 16

Using which, less messy version of the genetic algorithm:

{env->{[let _A _A]}
 popsize->50
 targetfitness->55
 [done _pop]:- lessthan(targetfitness _pop.map(fitness).fold1(max));
 start :- [let _pop dotimes(popsize newcritter)] 
          [let _run {_A:-[done _A];-> success 
                     _A-> _run(step._A)}];
           ->_run._pop
 newcritter -> {->dotimes(30 {->random.3})}                                     //a critter is a vector of length 30 with values ranging from 0 to 2 
 step -> { _pop -> dotimes(popsize makechild(selectparent._pop selectparent._pop))} //returns the population of children
 fitness -> { _A -> fold1(+ _A)}
 makechild -> { [_A _B] -> {->_A.zip(_B).map.{_C->_C.(random.2)}} }             //creates a new vector randomly choosing between elements from _A and _B
 selectparent -> { _pop -> dotimes(7                                                             //from a vector of 7
                                   {_->_pop(random.popsize)}).fold1(                             //randomly selected members of the population
                               {[_A _B]:- greater(fitness._A fitness._B); -> _A, [_A _B] -> _B}) //choose the individual with the best fitness
 }
 dotimes-> {
   [_length _body] :- [let _self {[_length _vect]-> _vect                                   //until _vect is the desired length
                                  [_A _vect]-> _self(++._A insert(_A _body.nil _vect));     //add the results of evaluating _body
                       -> _self(0 []) 
   insert->{[_key _val _orig]-> {_pos->_val _->_orig._}}
   _->env._
 }
 _->env._
}.start

--Zerk (talk) 03:42, 12 April 2014 (EDT)

I agree { ... } and [ ... ] should evaluate to boxes while symbols should be looked up.

"look up thing in environment (bind)" and "look up thing in other thing" (call) are resisting integration.

bind and the pattern match variables are also unintegrated. Bind looks up the value associated with a key in its home box and then up the chain of containing boxes (environments) until it fails.

A variable looks up the value in its current clause and then all containing clauses until it fails. They are almost the same thing.

evaluation proceeds by finding what the first thing is bound to and then if there are any . s it looks up the thing after the dot in the thing before.

parenthesis would evaluate their insides and then look it up in the thing to their left Doesthiswork (talk) 18:26, 12 April 2014 (EDT)

My concern with "looks up the value associated with a key in its home box" dynamically instead of statically is that it forces all infinite maps to take vectors. {_->sqrt._} can never resolve what sqrt is supposed to be.--Zerk (talk) 18:34, 12 April 2014 (EDT)

It was meant to be the same as lexical scope. A thing's home box is the one in which it is typed in. So sqrt in {_->sqrt._} resolves to the inbuilt definition of sqrt while {clauses, key->{_->sqrt._, otherClauses}} would check to see if sqrt was defined in otherClauses or clauses and if not, it uses the inbuilt definition of sqrt. A things home box doesn't change no matter how many times its passed around into and out of other things. --Doesthiswork (talk) 01:38, 13 April 2014 (EDT)

Er {_:-lt.[_ 0];->sqrt.(neg._), _->sqrt._}. Not just defined in otherClauses, explicitly defined in otherClauses; and if not in clauses, and if not use the inbuilt definition, which can conceptually be a final outer box. I suppose you could just elect to ignore all wildcard clauses, but that's the only way you'd have implicit dynamic bindings anyway, so might as well precompile the references.--Zerk (talk) 12:29, 13 April 2014 (EDT)