World: r3wp

Red/System v2. Without a preprocessor directives at all.

Not if it delays RED

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

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.

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.

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.

for example how to analyse this:

#either macroname cond [ a if macroname ] [ b if macroname ] either 
macroname

And we should switch the discussion into another thread

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"

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.

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 
...

The print names have nothing at all to do with C

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 ...

What does that have to do with C?

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 ...

Please point to the "protected" C equivalents

That is total nonsense

Explain ... that is how I remember the decision point ...

Then you remember wrong. It's easy to reread above here

Pekr,  Red and Red/System don't have the same semantics so I see 
no reason why they have to be compatible in any way except lexically.

I feel that there is a lot of merit in Evgeniy's approach, not least 
the possibility of a one-pass compiler. 


I think it is worth remembering that the current version of Red/System 
is a "bootstrap" version with which to build Red. Once Red is built, 
Red/System will be re-written in Red.


It is most likely that there will be many imporvements to Red/System 
, some may involve syntax changes. 


I feel we should all expect to have to re-visit existing Red/System 
code when the "real" Red/System is released.

My approach would also decrease a number of layers by one. This greatly 
reduces the complexity and greatly improves compilation speed.

I.e. after each #define and after it the #include, we would need 
to recompile the included file. That's enourmous lossage of time 
and resources.

Whilst I cannot speak for Nenad, I'm sure he will recognise these 
advantages. He may of course have other strategies up his sleeve 
to achieve speedy compilation.


Whether he would choose to improve the bootstrap version of Red/System 
at the expense of delaying work on Red is the big question.

Ok

But I am sure that NO strategy justifies #include and NO strategy 
is speedier than IMPORT of a compiled library.

Back from my trip to Paris, took me 3 days to come back home (Montenegro) 
due to huge snow. All roads closed, no train/bus/plane, state of 
emergency declared since saturday. I will answer the questions brought 
by Pekr and Evgeniy here later today, when I'll finish reading all 
the posts and emails I got since a week.

:-) yeah, we generated quite a lot of a stir here. At least you know, 
that Red is a lively project :-)

It all started by me trying to wrap some specific case. That's probably 
the most importat - Red allowing to wrap more outer world. As for 
syntax and other sugar, that's a secondary ... for now :-)

Welcome back Doc!

Pekr: (short answer) Red/System (and Red) generate executable binaries 
while R2/R3, while World and all other interpreted languages just 
run code in an interpreter or VM. This is a big difference, because 
Red can use the OS to load libraries at "load-time" instead of having 
to write code to do it (as all others interpreted languages require). 
This is also faster than loading manually. Red/System doesn't have 
yet a x-platform extension for adding "run-time" library loading 
support, just because we don't need it at all for now, but it can 
be added easily, by wrapping libFFI for example, or implementing 
it purely in Red/System.

The only added benefit of  manual loading at runtime is being able 
to upgrade the library without having to recompile the main program.

or extending an app by loading "plugins" at runtime.

But all the OS and third-party libraries we're currently using in 
Red/System have stable API, not the need for runtime loading has 
not appeared yet.

We tried to manual load library and get the proc address to be able 
to wrap a function, which crashes Red (as well as REBOL, World). 
It might be, that the library is not properly constructed for such 
a case. But Kaj mentioned something like parameter being a function! 
type, which is not supported, nor do we know, if it is planned, or 
if it even help our case ....

here's what he meant: "get-proc-address should really be defined 
as return: [function!] but that's not currently supported"