World: r3wp

#import [
	LIBC-file cdecl [
		quit-return: "exit" [  ; Exit program, returning status code.
			status		[integer!]
		]
	]
]

yes.. just found it in C lib as well... goot to know I can use the 
quit without it - I was missing the return code

btw... is there any reason that print does not add the LF automatically?

Yes, it is hard to come up with good names for "print-with-LF" and 
"print-without-LF" functions. ;-)

if you need an LF, you can just write: print [value lf]

What about prin and print? Or print and printn ?

It's not perfect, but at least, that way, we only need a single PRINT 
function (no need to remember other names like PRINTF, PRINTLN, PRIN, 
...).

PRINT/LF ?

PRIN and PRINT: that was my first choice, but users were pushing 
hard for not having PRIN.

PRINT/LF: no refinements support in Red/System, that will come in 
Red only.

I think it is better to have print with LF by default.. but ok... 
I must repeat myself that red/system is just a low level:)

I think that it would be possible to have the following:
	
	print value   				 ;; automatic line feed
	print [value value lf]			;; no autmatic line feed

Problem is it would confuse newcomers no end.

btw... if I do print float, I get result like: 100.00000000000000 
. I guess you know this issue.

By default, PRINT for floats maps to `printf ["%.14f" f]`, I guess 
the formatting string passed to PRINTF could be improved.

Since Red is related to REBOL, prin and print seem natural choices.

LF by default: sure, but the issue is coming up with a good name 
for PRINT without LF then. We already had a debate here about that 
a few months ago, and having just PRINT ended up being the less problematic 
solution (but it's not perfect I know).

I suppose "%14f" would avoid the extra zeros? (haven't checked the 
PRINTF docs).

What is wrong with PRIN? It's not more confusing than LF

I wonder if Carl's choice for PRIN was planned or added later when 
the need for a PRINT-WITHOUT-LF arised...

And I think in 99% you want the LF :) At least I forget to add it 
all the time.

Anyway.. not important now.

The only issue with PRIN is that it looks odd to all newcomers, not 
knowing about REBOL. I guess also we all found that odd in REBOL 
while learning it. I am used to it now, but it could be seen as "weird" 
choice by people first looking at Red/System.

Also PRIN is breaking the naming conventions used in REBOL, like 
having full words.

Since Red is related to REBOL, prin and print seem natural choices.
 - I agree.

like having full words
 - do words like REFORM not also violate that rule?

reform
 is a valid english word, no?

;-)

but in REBOL, it is a short for REDUCE-FORM.

Yeah, I know. We will use the same words in Red for maintaining compatibility 
with REBOL. I wish we had stricter rules for naming, but I guess 
that it won't hold in practice.

I think I would just be annoyed that Red tries to "fix" the wording 
of a REBOL function, as it means that you need some kind of alias 
table or must fix scripts or remember two sets of functions in your 
head.

I guess it's too soon for int64, isn't it?

Agreed, and I plan to keep Red as compatible as possible with REBOL 
wrt the syntax, but Red/System, as a dialect, can be a bit different.

int64: too soon yes, adding support for it would break all the current 
integer math code in backends, so not a trivial task. I have not 
planned to support it in this first Red/System version but add it 
only in the v2 (the rewrite in Red). OTOH, if we hit some wall in 
supporting an important feature or binding, I might reconsider that.

It should be possible though, to support it for bindings, but without 
any math operations.

it is used in iMagick. It would be fine without math.

I think it can be simulated with struct but I don§t know how difficult 
it is to implement it just without math.

It would take 2-3 days probably.

But I don't want to delay the work on Red compiler anymore, I should 
have started around new year, and I'm still on Red/System...

I must invest which routines are affected, but I think it's not a 
big priority like the float.

What about enums? What is the best way how to work with them in Red/System?

No plan for enums for now. You can use defines instead.

that would be quite a lot defines: https://gist.github.com/1683212

What about adding #enum into the loader?

I would like enumeration constants to be first class. Possibly integrated 
with a symbol type

no refinements support in Red/System, that will come in Red only.

 - just curious - isn't such a feature still a valid entry for future 
 Red/System enhancements? It is still in 19.7. section - should be 
 updated in doc as a dismissed feature then ...

Regarding PRINT, I would suggest simply defining a PRINT-LINE as 
an alternative to PRINT [LF}. There already is one in the C library 
binding, but it just prints a simple string

I don't agree... it's loger than print [lf] and as I said.. at least 
im my case 99% I need print with LF

Yes, [lf] is really not that long, so it's hard to find a good shorter 
alternative. In many cases you'll need a block anyway, so it's just 
" lf"

How about ?? as an alias for print-line, if it really must be ultra 
short for debugging?

Pekr: the section name in the documenation is "Possible Evolutions", 
not "Planned Evolutions", so features listed there might or might 
not make it in Red/System.

??
 sounds like a good addition.