World: r3wp

What is next is completing Topaz. The current version exists only 
so that I don't have to write any JS code in order to write the "real" 
Topaz. If you look inside next/ on the repository, i need to add 
all the datatypes and the natives, then write a translator that turns 
all that into something the current compiler can digest.

I was thinking about this:


In Topaz, you can make an op! out of any two-arguments function! 
(or native!). So, would it make sense to define IN as an op! rather 
than a function? Ie:

   'word in context

rather than

    in context 'word


The problem with it is that, contrary to +, * etc., there is no visual 
clue that IN is an op! rather than a function. However, the same 
can be said for AND, OR etc. in REBOL.


Which lead me to think: maybe the fact that the name is not a verb, 
but a preposition? In that case, should TO also be an op!?

    x to string!

rather than

    to string! x

That would be quite a change for a reboller, in how we perceive rebol 
code, no?

I prefer this syntax by far, but are you using the same operator 
precedence rules than REBOL?   ... it might complicate other areas 
of expression handling...

x -> string!

hmm

I find this better:

x  =>  string!



->    looks more like a "move to here" (which is why they used it 
for C pointer struct dereferencing IMHO)

=>   having an = symbol, looks more like a "make into"  (for which 
"to" is a synonym).

Making IN and TO as OP! looks ok.
=> looks better than -> but it a bit similar >= and <=

I'm not sure if it reduces readability. Especially if we put string! 
value in a word (I'm not sure either if anyone uses this)

;rebol
>> to t 5
== "5"

;topaz
t: string!
x => t

Oops, small typo, it should be:
>> t: string!
== string!
>> to t 5
== "5"

the Other alternative I see is using   <-  , as in:

>>  x <- string!    

but with endo's comment, its very misleading to read.
>>  x  <-  t

it looks like an assignment.  (put value of t within x)


so maybe standardizing on a first character which means, this operator 
is an in-place modifier, might be a good idea...  it might also allow 
a new class of series operators.
-----------------------------
with:
:=   to
:<   append
------------------------------
label: "prefix-" :< "text" :< "-suffix" 
x: 1
y: 3
x  :=  string!
x  :< "test"
x:  label :< 1  :<  y: "2"  :<  (y  := string! )
-----------------------------
x == "prefix-text-suffix123"
y == "23"

To op or not to op
 ...is suddenly very confusing.


For general use I would keep them as regular funcs, but perhaps add 
special sigilized op! versions. I like the regularity of funcs when 
generating code. I use the op approach in my dialected CAST func. 
e.g.

  cast [a to tag! b to block!]

Having the ability to create operators would be a good first step 
to deside, which operators makes sense, and who don't.

I like the experiment. I was always a bit thrown off by the order 
of IN

An experiment with TO wouldn't even harm REBOL compatibility much, 
because there are still the TO-* functions

very nice!

AS might be a better name for the operator instead of TO. IN as an 
operator with that argument order makes sense.

In REBOL I often avoid using operators when they would require parens 
to manage precedence, because parens have overhead there. This wouldn't 
be the case in a compiled language like Topaz.

I thought we have something of a convention to use AS for possibly-non-copying 
conversions?

That would be nice, but this is also a Topaz group, and that's a 
REBOL convention :)

Topaz is not the Anti-REBOL, is it?

Well, a lot of the language patterns used in REBOL come from its 
interpreted implementation. We don't use ops much in complex code 
because of paren overhead, but we use ops in simple code in R2 because 
the lookup is more efficient because it's special-cased. Compiled 
languages may end up being shaped differently, especially for optimized 
code. Still, AS for possibly-non-copying conversions is still more 
of a proposal in REBOL rather than an actual. AS as an operator version 
of TO would work there too. You could even do it directly in R3 if 
it weren't for the reversed arguments.

For IN though, it makes much more sense to have it be an op, with 
that word order. Too bad we can't do that in REBOL as well.

As for Topaz, it's the experimental one. Red is supposed to be more 
REBOL-like, to facilitate easier conversion of REBOL code, but Red 
is Gabriele's experiment with language design. He's already proposing 
to do things differently - i.e. function optional arguments - so 
it will likely end up quite different :)

Red is Gabriele's experiment -> Topaz is Gabriele's experiment
Bad typing day.

I agree about the differences, but I don't see how they're relevant 
to AS. To copy or not to copy is still very relevant in compiled 
languages

Also, Topaz' main current purpose is to compile to a (semi-)interpreted 
language, so you may still want to take interpreter patterns into 
account

Nope, not as long as parens don't have overhead in JS. JS, Lua, Python, 
Ruby, they're all compiled, even if the compilation result runs on 
a VM.

But the copying thing is a good reason to have AS be different than 
TO.

The big problem isn't an interpreter or copying thing, it's a syntax 
thing. If Topaz keeps the same evaluation precedence as REBOL, operators 
are going to continue to be awkward. The reasons behind the REBOL 
precedence rules are sound, and derived from the interpretation method, 
but if they are emulated in Topaz we'll still have asymmetry between 
the left hand side and the right hand side of an operator, requiring 
parens to resolve. Even if they don't have runtime overhead, we still 
have to type them. Not necessarily a problem, unless Gabriele thinks 
so :)

honestly, I'd prefer if operators did have precedence, but this might 
be awkward if you can define your own!

you'd need to instruct the compiler what precedence your op has! 
 but how?

I'm very pleased with not having to remember precedence rules in 
REBOL, so I think of it as a brain optimisation instead of an interpreter 
optimisation

even when  = has higher precedence than executing a function?   come 
on, a little bit of precedence would make a lot of REBOL code simpler 
to write.

a: "eek"
b: "wtf"

if append a  "ouch" =  append b "ouch"  [ a ]  ; ERROR appends boolean 
to a string, so is always "truthy"
== "eekfalse"


this kind of thing makes me go mad !  (there are sooo many other 
examples  ;-)

but it would also make it pretty slow, so I have to live with it. 
  :-/

It's an inconvenience, but remember a whole stack of rules, which 
never succeeds, is a big inconvenience

I don't find C's precedences to be that far off the mark of the most-commonly 
usefull pattern.  I don't have to write parens nearly as much in 
C than I have to in REBOL, its like a 10 to 1 ratio.  Do I feel like 
precedence is actually helping me.


its also a problem to me that rebol's clean syntax gets bloated by 
all those (relatively) useless parens.  


Add the fact that Compose will often bite you in the arse because 
of these (I do a lot of run-time code building and compiling in many 
of my apps) and its just gets really complex for nothing.

My C book falls open at page 53, as all of them do. It's just to 
hard to remember, lots of programs have superfluous parens "to be 
sure", and it's accepted that some of C's precedence should have 
been designed differently

hehehe... don't get me wrong, I'm not saying its perfect.

When in doubt in C, you need the book. When in doubt in REBOL, you 
only have to think logically

there is also an issue in that there are sooo many ops in C.  This 
is one thing that makes REBOL simpler.

I see it more like... when in doubt... just add parens (in both languages). 
  ;-)

Ah, but we were discussing implementing more operators - in fact, 
making their number unlimited

yep.  its another battle of consistency (objective) vs practicality(subjective). 
 this is probably the biggest challenge in any design decision IMHO.

See, all this is the reason, I think, why Carl never allowed creating 
new operators. :) (Aside from what looks like an optimization in 
R2, I think R3 works like Topaz in this regard and could easily allow 
custom ones.)

Brian: a clarification, Topaz is both an interpreter and a compiler, 
and although you can compile whenever you need speed (so in principle 
there won't be much need to manually optimize functions for the interpreter), 
in most cases you're running in an interpreter very like REBOL.

The issue of parens: i think that no matter what the precedence rules 
are, you'll find cases where you need parens.


Now, one of the things I want to try doing in Topaz is TCO, so maybe 
parens will have less overhead in the future than in REBOL, but it's 
hard to predict whether this is possible at all in the interpreter. 
They will probably not have significant overhead if you compile.


I vote we worry about readability first though, there's always going 
to be alternatives when performance is required. (Eg. the fact that 
something is available as an op! does not mean that it is not also 
available as a regular function; like in REBOL you have both AND 
and AND~. In fact, Topaz requires that you pass a function! or native! 
to make op! - so such function version has to exists anyway.)

Max: if append a  "ouch" =  append b "ouch"

I wonder how would you ever find that readable.

(TCO = taill call optimization)

*tail

Note, it would be possible to use any unicode character for the IN 
etc. ops to make them stand out visually... but then they would not 
be easy to type.

My C book is open at page 53 too most of the time. Operator precedence 
is crap!

That might be a drastic announcement. Letting = have higher precedence 
than the rest could be a good idea, but might be hard to implement 
and/or have performance hit.