World: r3wp

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"

OK, so if I understand it correctly, Red/System loads the library 
at an executable load time, whereas load/library does so dynamically 
in the app run-time. Stil - I wonder, if we could get a handle to 
such a library? I mean, syntactically #import is just like preprocessor 
construct - you can't assign it to any variable. Not sure it would 
be usefull, to be able to retrieve a handle to such wrapped library 
plus handles (entry points) to wrapped function calls?

Evgeniy: (short answer)


1) IIRC, there's no recompilation of included files in Red/System, 
the only overhead is parsing the preprocessor directives and reducing 
them. I agree that the whole compilation process would be significantly 
faster without a preprocessor, but that's another topic.


2) Preprocessor is a handy addition for compiled languages, that's 
why it was introduced in Red/System, not because it was a planned 
feature, but just because we _needed_ it for going further. The distinctive 
# prefix is used to make it clear both for users and the compiler 
that these parts are reduced at "compile-time" instead of "run-time" 
and avoid confusing both users and the compiler. For example, from 
your examples, the compiler has no way to distinguish a "compile-time" 
IF from a "run-time" IF, unless you make it a lot slower by doing 
static analysis and complex inference (the cost would be huge compared 
to the preprocessor). Also, this might also introduce a lot of new 
restrictions in the language semantics, which is not desirable.


3) IMPORT is better than INCLUDE: you might have missed it, but we 
can't yet generate libraries, so importing Red/System code now is 
not an option.

Pekr: you've mixed up completly "load-time" and "run-time" library 
loading. You don't need a library handle at "load-time" (unless you 
want to hack something in the OS). Also, you don't need any of your 
code above, just the #import declaration with the right function 
names (finding the right names seems to be the most complex part 
in the case of the library with the weird API you're using)

Pekr: the "make" vs "declare/alias" topic has been discussed lengthly 
in the ML, please read the posts there.

Also, the plan for me since the beginning was to use Red to help 
construct dynamically Red/System programs without requiring any preprocessor. 
As Red is not ready yet, I'm glad we have the preprocessor now in 
Red/System, to make our life easier.

I was not using preprocessor in my Rebol/Flash dialect and I must 
say, I find the Red/System way useful. It may be true, that additional 
pass may slow the compilation a little bit, but it also provide additional 
features. Also I don't expect that it will be used in some huge projects 
with MB of sources so if it's a few ms slower is not a problem. And 
as Red/System is open, everybody can provide own version:)

Doc - we have got the right function names, that is not the problem. 
The problem is the crash, and we were trying to identify, if Red/System 
library wrapping system still needs some improvements for some cases, 
or simply the DLL is doing something internally, that some functions 
work, and some crash. Here's example:


fpGetBright= (LSN_GETBRIGHT)GetProcAddress(g_hLedCtrlInst, "LSN_GetBright");
wrapped as:
led-get-brightness: "LSN_GetBright" [return: [integer!]]


Btw - how do I wrap properly function, which does not return any 
result? I tried just without the return clause, but it is not possible. 
Is e.g. return: [] (empty block allowed?)

As for compilation time. I don't know guys, but Red/System compiles 
REALLY fast. I do remember my dos times, where compiling took 30 
secs. Where's the problem? It's not imo about the compilation speed, 
at least for me - it is about the process of building app vs dynamic 
prototyping using interpreter. I don't like much the compile/build/run 
process, but I expect something like R2 console for prototyping appear 
in distant future for Red ....

Pekr: I will test your lib later today and see what's wrong. As I 
read that it crashes with also R2 and World, it seems obvious that 
something is wrong (a) in the lib or (b) you're not passing the right 
arguments or (c) you're not calling the right functions in the right 
order.

Compilation time: absolute speed is not the issue currently, we're 
talking about relative speed of the preprocessing compared to whole 
compilation time.

 it is about the process of building app vs dynamic prototyping using 
 interpreter


Well, I don't know how you build apps, I have never built one from 
the console, but only from a code editor. Console is nice for testing 
some small snippets when unsure, but coding is usually done in a 
decent code editor, where you usually launch your script using a 
shortcut. From that POV, there will be no differences with Red for 
the users. And to avoid further misunderstanding, Red will have a 
console, like R2 does, with similar features and possibilities.

Btw - how do I wrap properly function, which does not return any 
result? I tried just without the return clause, but it is not possible. 
Is e.g. return: [] (empty block allowed?)


It's in the spec document and same as the routine! interface in R2, 
just do not put a RETURN: definition if the function does not return 
anything:

http://static.red-lang.org/red-system-specs.html#section-14.1

Doc - I use text editor too, for some complex stuff.Yet for trial 
and error I use console. Several users expressed in the past, that 
one of the nice values of R2 is its console, for the quick prototyping 
around.

As for the return value - I was switching between R2, Red, World, 
so not sure, but ommiting return clause raised an error. Not sure 
it was Red or other environment. Will try that ...

LedCtrl.dll (from ledset-source package): 

1) How is it supposed to react if a board is not connected?


2) The DLL is a C++ program with static functions (acting as wrappers 
I guess). Have these static functions been compiled with an "extern 
C" directive? If not, there's no chance it can work with anything 
other than a compatible C++ compiler.


I think that the crash has nothing to do with Red/System, the "unknown" 
error might be caused by the DLL functions corrupting the data segment 
of the Red/System binary where the runtime error data is located. 
I will try to track it anyway, just to be sure, it's not a missing 
code in the Red/System runtime error processing routine.

I think too, it is not a Red/System. I used the generated exe also 
on a LED screen PC. I can turn screen on/off, led-is-power? works 
correctly, ditto for led-is-locked?, but led-get-brightness fails 
... so if some functions work, it means that DLL has properly exported 
values? All use the same declaration ...

It is a pity that my first attempt has some such problems. Just don't 
loose the time with it, if you have more important stuff to do. Kaj 
tried to do his best here, ditto Andreas.

Btw - if some func retunrs void, how should my return value look?

Also - what is a difference in passing a "void" to func, and passing 
it no value? Aren't following definitions just the same?

typedef void (WINAPI *LSN_BRIGHTDLG)(void);
typedef int	 (WINAPI *LSN_GETBRIGHT)();

Btw - if some func retunrs void, how should my return value look?

 Void is the C way to indicate "no return value". In Red/System, you 
 just don't add a RETURN: clause in such case.

OK, thank, that just clears the situation for me a bit ....

Steeve: The Red/system's compiler is not that far advanced. It can't 
perform dead code analysis. it's why it will get stuck with macros.


Evgeniy: dead code analysis for boolean constants is fairly simple 
and straigtforward

I could even help write


the only thing necessary is a boolean flag for a value that it is 
a CompileTimeConstant


if we have "IF(value)" and value is FALSE, we just remove the false 
code branch

from memory. And do not output code for it.

This renders #if useless...


Steeve: Yeah it seems pretty straightforward, feel free to ask in 
#Red :-)))))


Evgeniy: In Oberon, you can write VAR Procedure1: PROCEDURE1; BEGIN 
IF (ARCH1) Procedure1:=Arch1Module.Procedure1 ELSE Procedure1:=ArchOther.Procedure1 
END END


that's not so simple: there can be absent libraries and headers and 
files in dependent files on different archs. This must be taken into 
account and makes an implementation slightly complex.


Steeve, I've already asked that by previous discussion. I thought 
that this technique is obvious.

Oldes: And as Red/System is open, everybody can provide own version:)


Evgeniy: It seems to be necessary. I won't be attached to a language 
with a preprocessor. That's UNDERTHOUGHT OUT language.

:-) We are just starting ... but you could help Carl to improve R3 
semantics :-)

I'm really looking for to see your version Evgeniy. It's always good 
to see different approaches for same tasks.

Adding dead code elimination in Red/System at this point of the project 
serves no purpose. Please re-read all the presentations slides, roadmap, 
discussions on the ML or here...

Evgeniy: it seems you've missed my post at 10:40:23 earlier today.

After using `??` a few hours, I realized that it was a mistake to 
use it as a shortcut for `print-line`. It is readable when used on 
a word, but with a block, it looks too esoteric and hurt the feelings 
of old rebolers that see it as a syntax error. So, I want to get 
rid of `??` but can't find anything to replace it that would be both 
short and consistent with `print`and `print-line`. I think that I'll 
just deprecate `??` but won't remove it for now as some of you are 
heavily using it.

It does mean "print word value" in REBOL

Doc - I did not like ?? eiher, looked weird. Nor did I liked print-line, 
so I adopted "print [something lf]" block aproach, which looks ok 
to me ...