World: r3wp

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.

Gabriele - who does low-level coding - you or Carl? :-) It already 
seems to me, that rebcode is more powerfull than initially planned, 
that is really nice :-)

Carl.

i only wrote the new assembler (print mold rebcode*)

btw, about log2, you could write:

use [w] [
	rebcode-define [
		'log2 set w word! #==>
			log (w)
			div (w) 0.6931471805599453
			.
	]
]

Gabriele - some time ago you also did interesting script - parse-rules 
or anything like that? Or was it script to make own datatypes? You 
now seem to be an expert in that regard, providing us the assembler 
part. Maybe stuff I mentioned could be added to rebol in some extent? 
Would it be worth it? :-)

compile-rules: it's a compiler for parse rules, that allows extending 
the parse dialect. i think, that some of the extensions available 
using compile-rules should eventually get into the parse dialect. 
but, parse is not high on the pri list right now, so don't hold your 
breath.