WEP 3: Add turing completenss to RIDE by introducing loops with FOLD macros


#1

The idea is to introduce macros for RIDE, namely, FOLD macros:
so that this:

let result = FOLD<5>(arr, acc0, function)

will be unwrapped to

let restult = {
   let size = arr.size()
   if(size == 0) then acc0 else {
      let acc1 = function(acc0, arr[0])
      if(size == 1) then acc1 else {
         let acc2 = function(acc1, arr[1])
         if(size == 2) then acc2 else {
            let acc3 = function(acc2, arr[2])
            if(size == 3) then acc3 else {
               let acc4 = function(acc3, arr[3])
               if(size == 4) then acc4 else {
                  let acc5 = function(acc4, arr[4])
                  if(size == 5) 
                     then acc5 
                     else 
                       throw("Too big array, max 5 elements")
}}}}}}

Being a compile-time operation, this requires no changes to node code, therefore no hardfor-feature-voting. It also preserves primitives structure at VM level, therefore the implementation doesn’t complicate formal verification.

Pros:

  • sum , mult ,filter , contains , exists , average — anything that can be expressed with fold
  • No need to change Estimator or Evaluator — everything happens in pre-compile time
  • For that reason, no hardforks are needed to get the new functionality.

Cons:

  • You have to know the max size of your collection.
  • If you get more elements than expected, you get Exception
  • Computation cost will be linear to that max value
  • Script size will be linear to that max value

More here: https://medium.com/@ilya.smagin/solution-for-loops-for-foreach-in-ride-7b5f41dc76dd

Please share your thoughts.


#2

Are you kidding talking about turing completeness? Your proposal is not introducing any sort of recently absent computation abilities to RIDE, it’s just a “syntax sugar” to reduce coder’s routine work.


#3

i understand you concern and the reasoning, but what reasonal computational capabilities are still missing? I mean, I’m really looking forwar to introducing somethin like “reasonably turing complete” or “turing complete enough” here.


#4

Try to implement stock (sorted list with dynamic data) for example


#5

Deals with stock should be processed strictly from top to depth. Currently we have no capability to maintain blockchain-proved stock structure in RIDE.


#6

If I understand correctly, it basically boils down to sorting(do you agree?). That’s doable(do you agree?), we might miss a few functions in Lists API in ride though.