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

World: r3wp

[Red] Red language group

Maxim
13-Feb-2012
[4964]
note that currently, what you see isn't RED... its RED/System.
Evgeniy Philippov
13-Feb-2012
[4965x18]
Of course
This preprocessor is a BIG step BACK for a REBOL-like language and 
is completely counterproductive, and I can prove and explain why. 
I have a lot of insights into this issue.
Regardless of whether it's RED or R/S, it's highly counterproductive.
I find a code with preprocessing TERRIFIC, AWFUL, and TERRIFYING. 
It slows down compilation to orders of magnitude.
#include must be replaced by IMPORT or DEPENDENCIES
Since compilation of included file is done everytime, and for IMPORT/DEPENDENCIES 
it is done once, and then a compiled version of a dependency is used 
everytime, which is infinite orders of magnitude faster.
#define may be replaced by MACRO keyword (more specific) or by DEFINE 
keyword (if you want to use a broad term). # is redundant and ***misleading*** 
since it makes one think it's C #define.
why not use the simple
define macroname: macrovalue
syntax
?
#if and #either are easily replaceable by "if" and "either" with 
an optimising compiler
and are completely redundant
#switch is the same as #if/#either.
So, all preprocessor directives can easily be removed from a language 
of Red/System, and replaced by normal keywords.
They give no pros, and give only slowdown of a translator and also 
much greater complexity of a code (try to analyse it metaprogrammatically 
and you will understand what I tell about!) and they also give a 
redundant extra layer of complexity.
I propose to start a RED v2
Red/System v2. Without a preprocessor directives at all.
GrahamC
13-Feb-2012
[4983]
Not if it delays RED
Evgeniy Philippov
13-Feb-2012
[4984x6]
Haha. So you advicate a sShort time progress with Eternal
oops
Sorry. So you advocate a short time progress with Eternal regress 
and pain of recompiling included files and unavailability of metaprogramming 
possibility? No-preprocessor languages can easily be analysed metaprogrammatically 
and transformed, and preprocessor languages cannot (almost).
That's very childish, then. Uninformed decision.
Okay my intent is derive ROD from REBOL... Not sure I will reach 
a result.
err from RED
Steeve
13-Feb-2012
[4990x2]
I don't know what you mean by "I want to be able to analyse metaprogrammatically". 
But if you want "cleaned" sources, you just have to run the pre-processor 
on the "biased" sources.
Though, I don't know if it's possible right now to just run the pre-processor. 
But feel free to ask.
Evgeniy Philippov
13-Feb-2012
[4992x4]
http://en.wikipedia.org/w/index.php?title=Metaprogramming&oldid=472528422
I hate preprocessors installed right in the language. That's a sin 
of mixing layers into one layer.
Steeve, such cleaning removes important information from a code. 
That's reduction. And removing the preprocessor removes this reduction.
That's reduction of meaning of a program. Reduction of its semantics.
Steeve
13-Feb-2012
[4996]
Okkkkkk, I know what the word means in its regular sense. I just 
feel you should make clear yourself with the context and provide 
some use cases.
Evgeniy Philippov
13-Feb-2012
[4997x2]
for example how to analyse this:
#either macroname cond [ a if macroname ] [ b if macroname ] either 
macroname
Steeve
13-Feb-2012
[4999]
And we should switch the discussion into another thread
Evgeniy Philippov
13-Feb-2012
[5000x4]
either macroname [ c ] [ d ]
that's not analysable. Into which thread?
This is related to RED only. I can discuss privately with Dockimbel, 
but why should I go private?
Maxim, from a R/S spec: "Red/System ... will be embedded in Red scripts"

Maxim
13-Feb-2012
[5004]
AFAICT, Red/system is used more like a high-level VM (compilable 
source rather than interpreted opcodes) which can be natively compiled. 
  RED won't have RED/System semantics.
Pekr
13-Feb-2012
[5005]
Max, I share some sentiments with Evgeniy. I too don't understand 
some design decisions - my first take is, that Red/System should 
be as much compatible to Red, as possible. Hence I will never agree 
to decision for 'print differing from its Red counterpart. I don't 
give a <censored> to C users, as imo noone will use Red/system, unless 
that person also plans to use Red itself.


My take is, that compatibility between Red and Red/System is much 
more important, that compatibility between the Red/System and C.


Ditto the strange aproach to use kind of preprocessor for importing 
the libraries, whereas R2 and World are OK with just make routine!

Ditto for strange declaration stuff:

declare struct!
alias struct!
#import for a library

Intead of:

make struct!
make lit-struct!
make routine!


If Red/System is going to be inlined in Red, the aproach to costructors 
should be as much the same as possible. This is a dialecting - the 
same words have different meaning in different context usage. I don't 
give a <censored> about protecting a possible C user's knowledge 
...
Kaj
13-Feb-2012
[5006]
The print names have nothing at all to do with C
Pekr
13-Feb-2012
[5007]
It does :-) It does not print newline by default, although it will 
be 90% time of requested feature. Just because the compatibility 
to C, Doc introduced print-line, which will be equivalent to ??. 
So 90% of your time your code is going to be ridden with print-line 
or ??, becaue we don't like 'prin ...
Kaj
13-Feb-2012
[5008]
What does that have to do with C?
Pekr
13-Feb-2012
[5009x2]
That is what I call a protecting C nonsense. We are REBOL, not C, 
period. I am so mad about it, that if there would not be option to 
use print along with block, I would stop using Red/System ...
The decision was based clearly upon the fear, that Red/System is 
going to be used mainly by C ppl, and that in C print doeas not add 
new line by default ... that is imo a wrong design decision ...
Kaj
13-Feb-2012
[5011x2]
Please point to the "protected" C equivalents
That is total nonsense
Pekr
13-Feb-2012
[5013]
Explain ... that is how I remember the decision point ...