r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Topaz] The Topaz Language

PeterWood
25-Jun-2011
[1]
A new group for discussing the Topaz language.
Endo
26-Jun-2011
[2]
Good! Thanks!
onetom
26-Jun-2011
[3]
awesome! :)
GrahamC
26-Jun-2011
[4]
What's topaz?
Gabriele
26-Jun-2011
[5]
Graham, you'll probably have to wait for a good answer to that question. 
:)
GrahamC
26-Jun-2011
[6]
I guess it'll be a year or more ... before the answer arrives
TomBon
26-Jun-2011
[7x2]
graham, topaz is a silicate based gemstone, with the correct impurities 
it could morphe to topaz_red.

as you can see here: http://en.wikipedia.org/wiki/File:Topaz_red.jpg 
  :-)))
this was a truly accelerated year...
GrahamC
26-Jun-2011
[9x2]
So, the topaz lines the cloud of the missing R3 author?
Or, all that sparkles is not ruby?
TomBon
26-Jun-2011
[11x2]
LOL, yes, but only if mutation appears also within a accelerate year.
we could use dnanexus for this as posted from doc.
Kaj
26-Jun-2011
[13]
Silence is topaz
Dockimbel
26-Jun-2011
[14x2]
:-)
I am pretty sure that we will find some ways to combine Topaz and 
Red at some point, once both get more mature.
nve
26-Jun-2011
[16x2]
@Gabriele Do you have a home page or is it Github project hosting 
as a home page ?
Thx
@TomBon Great ! I like this picture !
Gabriele
27-Jun-2011
[18]
nve: i don't have a home page yet, except for the try-topaz.html 
thing. so github is the place for now.
nve
29-Jun-2011
[19]
Do you have a timeline for your project ? A goal to reach ?

People are asking lots of questions about Topaz (because it is related 
to Javascript ;)).
Thanks for your lightening.
Gabriele
30-Jun-2011
[20x2]
I don't have a timeline because I can't work on it 100% of the time.


I have many goals. One is to make creating web applications easy. 
I'll repost a message I posted earlier on a different group:
But what about concentrate all the effort on one product ?


We all have different goals. My main goal is to be able to try out 
experiments (like, what would it be like to add feature X to the 
language?); there's no way I can do this with R3. Also, I don't want 
to program in C (so, again, R3 and Boron are out).


My secondary goal is to simplify creation of web and mobile applications. 
R3, RED and Boron do not run inside the browser; RED may be able 
to target mobile platforms eventually, so we may be able to collaborate 
here.
Endo
1-Jul-2011
[22]
even you don't work on it 100% time, it would be nice to know what 
is next, you can write what is in your mind for next step, like a 
to-do list, without given exact dates.
nve
1-Jul-2011
[23]
Your right Endo...!
Gabriele
2-Jul-2011
[24]
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.
Gabriele
19-Jul-2011
[25]
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
Pekr
19-Jul-2011
[26]
That would be quite a change for a reboller, in how we perceive rebol 
code, no?
Maxim
19-Jul-2011
[27]
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...
Geomol
19-Jul-2011
[28]
x -> string!

hmm
Maxim
19-Jul-2011
[29]
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).
Endo
19-Jul-2011
[30x2]
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"
Maxim
19-Jul-2011
[32]
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"
Gregg
19-Jul-2011
[33]
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!]
Geomol
19-Jul-2011
[34]
Having the ability to create operators would be a good first step 
to deside, which operators makes sense, and who don't.
Kaj
19-Jul-2011
[35x2]
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
Mchean
19-Jul-2011
[37]
very nice!
BrianH
19-Jul-2011
[38x2]
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.
Kaj
19-Jul-2011
[40]
I thought we have something of a convention to use AS for possibly-non-copying 
conversions?
BrianH
19-Jul-2011
[41]
That would be nice, but this is also a Topaz group, and that's a 
REBOL convention :)
Kaj
19-Jul-2011
[42]
Topaz is not the Anti-REBOL, is it?
BrianH
19-Jul-2011
[43x4]
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.
Kaj
19-Jul-2011
[47x2]
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
BrianH
19-Jul-2011
[49x2]
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.