World: r3wp

Gabriele, thanks for the info about the rewrite rules. That's an 
interesting way to lay them out - a little more traditional that 
I've come to expect from REBOL, but that #==> is unlikely to be found 
in REBOL code so its use to delimit the parse rules should work nicely. 
I look forward to trying it out!

but then I want tasking maybe and mixing it with timers here :-) 
well, just watching Carl's speach - did he mention plug-ins (language 
plugins)? And IIRC Reichart mentioned modularity ... hmm, hmm, looking 
at RebCode, watching the devcon videos, I think good times are ahead 
:-)

Actually, when I think about it, the flexible function call syntax 
of REBOL would be a bit of a slowdown to implement directly in rebcode. 
All of the operations now are fixed in arity and known ahead of time. 
One way to get that same predictable behavior in rebcode is to put 
the call in a block and assign the result - coincidentally this is 
the syntax of the do opcode.


Another way to do this would be to add something like an APPLY opcode 
with three parameters: A result param (word!), a function param (word! 
| path!) and an arguments param (word! | block!). This opcode would 
pass the arguments to the function (perhaps with refinements) and 
assign the result to the word provided. This would allow the higher 
order programming that would otherwise be awkward - the do opcode 
could be used for traditional function calls. If necessary, the operation 
could be split into two opcodes: APPLY for function values assigned 
to a word, and APPLYP for a path literal or value assigned to a word 
- whether to do this would depend on which was faster.


Another awkward thing to do in rebcode is getting and setting values 
through indirection, like the get and set natives do. Those seem 
like a really basic operations that should have opcodes assigned 
to them rather than having to resort to do blocks. I'm just thinking 
of the basic get/set word assigned to word scenario, not the more 
advanced object/block stuff.

Gabriele, you might want to change the compose/deep call in the rewrite 
rules generated by rebcode-define to compose. The current version 
might trip up makers of rewrite rules, like it does in your first 
example rule above in the (either paren? ...) clause. Let any further 
composition be up to the rule makers, just in case they actually 
need to use parens themselves.

Brian - you may add your 'apply request to RT QA group :-)

Well, I would hope that the RT people implementing rebcode might 
check the rebcode group every once in a while, but sure. I'll have 
to rephrase since it's out of context though.

BUG (possibly): The SETI and SETD opcodes don't work unless the variable 
has already been set to a value of the appropriate data type.

Maybe optimisation?

BUG: The decimal math opcodes can take an integer value in the second 
argument, but if that value is specified literally the syntax checker 
rejects it. The integer! datatype needs to be added as an alternate 
to the second argument.

Volker, that's why I said possibly. If so it should be documented.

REQUEST: I would like the LOG-2 opcode to be added to the existing 
LOG-10 and LOG-E. Log-2 is the only one of those I actually use regularly 
:)

APPLY is just what is in the works :) and... some kind of GET and 
SET for indirection is being discussed too.

How about LOG-2 :)

about the compose/deep, i think that's what most people will want. 
note that my either paren? has nothing to do with it (it is to handle 
parens in the expressions, not to workaround compose/deep)

SETI and SETD: that's intended. they only work on initialized variables... 
but they are faster than normal SET (SET has to copy 16 bytes, SETI 
only 32 bits for example)

log-2: going to ask Carl.

I meant the other, literal paren in your code that you clearly needed 
to be composed at rewrite time rather than at rule adding time like 
it is now.

(either paren? val [compose [rv: (to block! val)]] [ ])

how would compose without /deep help there?

Compose would just compose the parens directly in the production; 
compose/deep composes all of the inner parens inside the code as 
well.

it does not compose parens inside parens

it only composes parens inside blocks.

>> compose/deep [([something (something)])]
== [something (something)]

that's why i need an extra compose there.

if you have either or if or while or something like that in your 
production, you'll need /deep, and you'll be screaming if you don't 
have it ;)

OK then, I thought /deep meant /deep, my mistake :)

I thought you needed the extra compose since it was to be applied 
later, at rewrite time.

That makes compose/deep more useful than I thought.

:-)

I've been thinking about temporary variables generated by rewrite 
rules. I have a way to generate extremely unlikely variable names, 
but no way to bind them in the rebcode function after they've been 
added. Any ideas?

the rewriting process preserves binding.

so, you can also use extremely likely names, but just have them bound 
to your own context.

I mean adding new bindings, say for intermediate values of complex 
expressions that need to be changed to sequences of simple expressions 
using temporary variables that don't exist in the original code.

use [x val] [rebcode-define ['my-op set val integer! #==> set x (val) 
?? x .]]

you can consider X a temporary variable here.

Expressions like (x * (y + z)) + (w * y)

To use only one temporary variable may require a topological sort 
of the expression, if it is at all possible. I want to be able to 
generate anonymous temporaries if necessary.

(there's an infinite loop in my compiler using your example, i'll 
need to debug it later - too sleepy now ;)

but, it works removing one paren.

>> f: rebcode [] [res: x * (y + z) + (w * y)]
>> print mold second :f

[set res x set rv y addd rv z muld res rv set rv w muld rv y addd 
res rv]

only RV is used as a temp var... and it's always the same rv.

if you can find an example where this would not work... please let 
me know; i guess you will, since this compiler is just a quick test, 
and i didn't expect it to work this well ;)

Well finding an example is simple: Just convert to stack code and 
figure out when the stack would be used more than one deep between 
ops. That means more than one temp var. What we get for going to 
a register machine in a stack language :)


This would all be solved by a built-in USE directive with literal 
blocks that acts like USE in REBOL except only binding at rebcode 
creation time. It could be implemented as a built-in rewrite rule, 
changing the temporary variables to local variables, renaming if 
necessary. This rewrite would be done after the user-defined rewrites 
were done, but before the binding to the opcodes.


Let me think about how this could be implemented - I am late for 
a class.

rebcode 10 was released .....

Pekr, yes, rebcode docs will be forthcoming.

thanks ... the docs will be pretty comples - soooo many opcodes in-there 
:-) I just wonder, if Gabriele does only some wrappers or even C 
internal coding? :-) And if he is so good at it and RT is working 
on a low-level stuff for a while - there were few wishes to improve 
library interface and callback support. Imo it is still in versio 
like Jeff did it initially and some update which would make wrapping 
easier would be handy :-)

I have a dialect to simplify routine! writing, but I don't know if 
there is anything else planned for the library interfaces right now.

imo callback  support is weak, dunno if other languages have such 
a limit as 16 possible callbacks ... well, there is many indications 
in dll.so group. It surely will not be a priority for RT right now, 
as it simply works as a solution, but I just thought that those two 
things (dll C interface and VM assembler) could be related somehow 
...

besides that, yesterday I played part of Carl's speech, and in QA 
part I noticed something like a mention of interfacing via plug-ins, 
but I could easily misunderstood because of my "ability" to distinguish 
natively spoken English :-))

from Carl:

log2:
   log n
   div n 0.6931471805599453

Do you still want it as an opcode?

note, that rebcode10.zip has APPLY. see notes.txt.