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

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.

5 Likes

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.

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.

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

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

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.

I this sense, with limitations i agree with idea, but i believe need some refinement on methodological implement