Merge branch 'main' of github.com:refaktor/rye into contextplay

evaldo/evaldo.go

@@ -292,10 +292,28 @@ func EvalExpressionConcrete(ps *env.ProgramState) *env.ProgramState {
 	//trace2("Before entering expression")
 	if object != nil {
 		switch object.Type() {
-		case env.IntegerType, env.DecimalType, env.StringType, env.BlockType, env.VoidType, env.UriType, env.EmailType: // env.TagwordType, JM 20230126
+		case env.IntegerType, env.DecimalType, env.StringType, env.VoidType, env.UriType, env.EmailType: // env.TagwordType, JM 20230126
 			if !ps.SkipFlag {
 				ps.Res = object
 			}
+		case env.BlockType:
+			if !ps.SkipFlag {
+				block := object.(env.Block)
+				// block mode 1 is for eval blocks
+				if block.Mode == 1 {
+					ser := ps.Ser
+					ps.Ser = block.Series
+					res := make([]env.Object, 0)
+					for ps.Ser.Pos() < ps.Ser.Len() {
+						EvalExpression2(ps, false)
+						res = append(res, ps.Res)
+					}
+					ps.Ser = ser
+					ps.Res = *env.NewBlock(*env.NewTSeries(res))
+				} else {
+					ps.Res = object
+				}
+			}
 		case env.TagwordType:
 			ps.Res = *env.NewWord(object.(env.Tagword).Index)
 			return ps

evaldo/evaldo_test.go

@@ -3,6 +3,7 @@ package evaldo
 
 import (
 	"fmt"
+	"strconv"
 
 	"github.com/refaktor/rye/env"
 	"github.com/refaktor/rye/loader"
@@ -408,3 +409,45 @@ func TestEvaldo_load_lsetword4(t *testing.T) {
 		t.Error("Expected result value 80")
 	}
 }
+
+func TestEvaldo_load_block(t *testing.T) {
+	input := "a: 1 { a 2 }"
+	block, genv := loader.LoadString(input, false)
+	es := env.NewProgramState(block.(env.Block).Series, genv)
+	RegisterBuiltins(es)
+
+	EvalBlock(es)
+
+	nonEvaluatedBlock := es.Res
+	if nonEvaluatedBlock.Type() != env.BlockType {
+		t.Error("Expected result type block")
+	}
+
+	if nonEvaluatedBlock.(env.Block).Series.Get(0).Type() != env.WordType {
+		t.Error("Expected first item to be evaluated to type integer but got type " + strconv.Itoa(int(nonEvaluatedBlock.(env.Block).Series.Get(0).Type())))
+	}
+	if nonEvaluatedBlock.(env.Block).Series.Get(1).Type() != env.IntegerType {
+		t.Error("Expected second item to be type integer")
+	}
+}
+
+func TestEvaldo_load_eval_block(t *testing.T) {
+	input := "a: 1 [ a 2 ]"
+	block, genv := loader.LoadString(input, false)
+	es := env.NewProgramState(block.(env.Block).Series, genv)
+	RegisterBuiltins(es)
+
+	EvalBlock(es)
+
+	evaluatedBlock := es.Res
+	if evaluatedBlock.Type() != env.BlockType {
+		t.Error("Expected result type block")
+	}
+
+	if evaluatedBlock.(env.Block).Series.Get(0).Type() != env.IntegerType {
+		t.Error("Expected first item to be evaluated to type integer but got type " + strconv.Itoa(int(evaluatedBlock.(env.Block).Series.Get(0).Type())))
+	}
+	if evaluatedBlock.(env.Block).Series.Get(1).Type() != env.IntegerType {
+		t.Error("Expected second item to be type integer")
+	}
+}

loader/loader_test.go

@@ -2,6 +2,7 @@ package loader
 
 import (
 	"fmt"
+	"strconv"
 
 	"github.com/refaktor/rye/env"
 
@@ -253,6 +254,26 @@ func TestLoader_multiple_newlines2(t *testing.T) {
 	}
 }
 
+func TestLoader_bblock(t *testing.T) {
+	input := "a: 1 [ a 2 ]"
+	block, _ := LoadString(input, false)
+	// expect setword, integer, block
+	if block.(env.Block).Series.Len() != 3 {
+		t.Error("Expected 3 items")
+	}
+	innerBlock := block.(env.Block).Series.Get(2)
+	if innerBlock.Type() != env.BlockType {
+		t.Error("Expected type block")
+	}
+	// block is not evaluated yet, only loaded
+	if innerBlock.(env.Block).Series.Get(0).Type() != env.WordType {
+		t.Error("Expected first item to be evaluated to type integer but got type " + strconv.Itoa(int(innerBlock.(env.Block).Series.Get(0).Type())))
+	}
+	if innerBlock.(env.Block).Series.Get(1).Type() != env.IntegerType {
+		t.Error("Expected second item to be type integer")
+	}
+}
+
 func TestLoader_multiple_blocks(t *testing.T) {
 	input := "\n\t123	{ { 22 } aa } \nword2\tsetword2:\n\t234"
 	block, _ := LoadString(input, false)

planing.md

@@ -10,7 +10,7 @@ Positive now is that with `ls` you can quickly see all builtins you have, negati
 We will make subc waythe default one, so `ls` will only show your context which will be way clearer. We will add function `lsp - list parent` which will show in this case the builtin. Benefit is also that
 you then can't change or owerwrite parent functions (but you can owershadow them - which is better than first - think of some warning about this).
 
-### Evaluated blocks
+### Evaluated blocks [++] @Rok
 
 I left the difference between { } and [ ] open for years. Currently both work the same, but we use { } . One benefit of mixing would be that if you alternate them it's easier to see the matching parenthesis sometimes. But it's 
 a dubious one - as it would also confuse new viewers of code and colors can do the same. I was making Fyne integration. There is a constructor for container and it accepts any number of widgets. The best way to do 
@@ -19,14 +19,16 @@ this in Rye was to put them into a block, but blocks aren't evaluated by default
 If [ ] evaluate by default we reduce the need for vals function (which I couldn't find a good name yet btw. Rebol's reduce is taken, eval would be the most correct but would strongly conotate javascript's eval which does a different (bad) thing). 
 So some code becomes cleaner and runtime handles these cases in one step instead of two, which is not unimportant as it can be used a lot.
 
-### Builtins inside context's
+### Builtins inside context's [++]
 
 At integrating Fyne also it was decided that builtins should have and option to be loaded in their own context. Once a native is created we use generic methods for namespacing, but to construct them words need to be namespaced. So we have either 
 fyne-window, fyne-button, fyne-entry, ... of we put all those in it's own fyne context and we can have fyne/window, fyne/button, fyne/entry of just execute code inside that context and have only window, button, entry ... This is the best way for 
 multiple reasons so builtins must support loading in their context. If you would want at build time determine what builtins should load in their own context and what directly, or if it should be decided by the builtin maker is still an open question.
 
 Too much variability can then complicate reuse ... this would need to be determined by flags and build flags are already a per-project parameter.
 
+For now it's statically determined at development of builtins. We will explore more dynamic options later.
+
 ### Rye shell / console naming [+-]
 
 I need to decide what Rye REPL will be called. REPL is not user friendly word. I used shell, but it can get confusing with Bash, Zsh, maybe one time Ryesh :P. I use console here and there so it's not unified. Google gemini suggests Rye console