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

World: r3wp

[Topaz] The Topaz Language

BrianH
19-Jul-2011
[51]
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 :)
Maxim
19-Jul-2011
[52]
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?
Kaj
19-Jul-2011
[53]
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
Maxim
19-Jul-2011
[54x2]
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. 
  :-/
Kaj
19-Jul-2011
[56]
It's an inconvenience, but remember a whole stack of rules, which 
never succeeds, is a big inconvenience
Maxim
19-Jul-2011
[57]
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.
Kaj
19-Jul-2011
[58]
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
Maxim
19-Jul-2011
[59]
hehehe... don't get me wrong, I'm not saying its perfect.
Kaj
19-Jul-2011
[60]
When in doubt in C, you need the book. When in doubt in REBOL, you 
only have to think logically
Maxim
19-Jul-2011
[61x2]
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). 
  ;-)
Kaj
19-Jul-2011
[63]
Ah, but we were discussing implementing more operators - in fact, 
making their number unlimited
Maxim
19-Jul-2011
[64]
yep.  its another battle of consistency (objective) vs practicality(subjective). 
 this is probably the biggest challenge in any design decision IMHO.
Gabriele
20-Jul-2011
[65x7]
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.
Geomol
20-Jul-2011
[72x2]
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.
Kaj
20-Jul-2011
[74]
I think Max wants it to have lower precedence :-)
Geomol
20-Jul-2011
[75]
Ah, sure. :)
Kaj
20-Jul-2011
[76x2]
Having no precedence is the most brilliant way to solve all precedence 
disputes :-)
The thing that mesmerised me most in the Dragon Book was the implementation 
of expression evaluation with precedence rules. I think since then, 
everyone was hypnotised to think that it needs to be implemented 
in every language. Maybe Carl never read the book :-)
Geomol
20-Jul-2011
[78x2]
I wonder, who first introduced operator precedence in math?
http://mathforum.org/library/drmath/view/52582.html


Mathematicians needed to write ax^2 + bx + c as easily as possible.
Kaj
20-Jul-2011
[80]
Nice find
Gabriele
21-Jul-2011
[81x2]
operator precedence makes sense... but it is not worth the trouble.
I guess the common use:

   if 'word in context [...]

makes sense, while the common use:

   var: (...) to string!


is a bit unpleasant. OTOH, maybe this'd give a reason to the various 
to-* functions, so you'd use

    var: to-string ...

still, "to-string" is not a verb... so, i'm not convinced yet. :/
Endo
21-Jul-2011
[83]
But if TO is an OP then var: (...) to string! looks ok. Just like
var: 3 + 5

does not lead var is 3. variable assigment has lower precedence than 
any other.
Gabriele
22-Jul-2011
[84]
Endo: think about the fact that the (...) is usually a long expression, 
but more importantly, there is no clue that TO is an op rather than 
a function, other than it not being a verb (which is not obvious).


The IN case is much easier to read, and IN is used in a similar way 
in other languages. TO might confuse both rebolers and non-rebolers... 
:)


I still like the idea of them being ops, i'm just worried about it 
being too unreadable and forcing parens most of the time. would anyone 
prefer using some kind of symbol? eg. similar to the <- suggested 
above.
Endo
22-Jul-2011
[85]
Normally all op!s are somehow related with math, as we can consider 
equality tests (=, !=, > etc) and logical operations (xor, and etc.) 
as math operations.

TO and IN are different by this way, they are not related any math 
operation, they don't test, they don't calculate anything.

And one of them should have a precedence the other, or we should 
use parens, or can we say always left-to-right:

>> o: context [a: "3"]
>> 'a in o to integer!
Kaj
22-Jul-2011
[86]
I like TO better than a symbol, which would also be non-standard, 
but maybe we can have both
Bas
12-Aug-2011
[87]
Gabriele will give a presentation about Topaz during Software Freedom 
Day 2011, wednesday 14th september, at the Centrum Wiskunde & Informatica 
(CWI), Science Park Amsterdam: http://www.softwarefreedomday.eu/
Dockimbel
12-Aug-2011
[88]
That is a very good news!
shadwolf
12-Aug-2011
[89x7]
I like this idea print  "hello " .  myvar . " !" or print "hello 
" + myvar + " !"  over the print rejoin ["hello " myvar " !" ] ... 
In web area a rebol inspired language using more "advanced" less 
pompous string concatenating method will be noticed I think...
I like the perl way to deal with bash expression on linux ...
myvar=`ls  /home/myname/mydir`  foreach file myvar [ print "file 
name: " + file ]
arriving to do something like that in a rebol inspired script language 
would be terrific ... I know I'm just giving some thought and no 
code ... well ... I have not your talent for those thing :)
oh last remark ... I noticed most of the time scripting language 
tends to be differenciated by their affectation symbol  example lua 
use var ::= 1 rebol var: 1 perl var= 1, PL/SQL var:=1;  etc ... I 
like the rebol way of affectation and since that one of the sign 
of a rebol script I think it's important to keep in in spin off languages 
...
ok one last remark with red, borron, and red isn't that too much 
spin off language to handle for this community ? I understand there 
is a lot to research on this very interesting field ... but don't 
you fear that those project  will in a short term stop growing cause 
complexity level reach and there is noone to keep them on the progressing 
curve. Can eventually  those project be merged into one single project 
keeping the other two less advanced  as research ground and the BIG 
thing being granted with the best ideas proven in the "research" 
project ?
I fear that being 3 totally seperated projects on their own they 
won't liveon ... and somehow collide  ... Ok I'm not clear on this 
...
Gabriele
13-Aug-2011
[96x2]
Shadwolf, something like "bla" . "bla" . "bla" cannot be optimized 
in an interpreter like Topaz, moreover, why the hell should i have 
to write . a hundred times and have an error when i forget it? So, 
no, you won't get this in Topaz.
Re: SFD: I hope to have something to demo as well, but i can't guarantee 
that as Topaz still has a long way to go before 1.0. Worst case, 
i'll just talk about it in general and accept questions.
shadwolf
16-Aug-2011
[98x2]
gabriele I think the perl/php  apraoch print "myvqr bla blah myothervar" 
is not in your plans neither ... Well I gived you just a list of 
the kind of things I think rebol could do better no offense ...
take them as overall general comments and particular taste of someone 
used to program in around 20 languages ...
Gabriele
21-Aug-2011
[100]
I've significantly reorganized the Topaz source code. A bit more 
manageable this way.