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

World: r3wp

[Red] Red language group

Dockimbel
26-Jan-2012
[4461]
;-)
Henrik
26-Jan-2012
[4462]
but in REBOL, it is a short for REDUCE-FORM.
Dockimbel
26-Jan-2012
[4463]
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.
Henrik
26-Jan-2012
[4464]
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.
Oldes
26-Jan-2012
[4465]
I guess it's too soon for int64, isn't it?
Dockimbel
26-Jan-2012
[4466x3]
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.
Oldes
26-Jan-2012
[4469x2]
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.
Dockimbel
26-Jan-2012
[4471x2]
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...
Oldes
26-Jan-2012
[4473x2]
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?
Dockimbel
26-Jan-2012
[4475]
No plan for enums for now. You can use defines instead.
Oldes
26-Jan-2012
[4476x2]
that would be quite a lot defines: https://gist.github.com/1683212
What about adding #enum into the loader?
Kaj
26-Jan-2012
[4478]
I would like enumeration constants to be first class. Possibly integrated 
with a symbol type
Pekr
26-Jan-2012
[4479]
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 ...
Kaj
26-Jan-2012
[4480]
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
Oldes
26-Jan-2012
[4481]
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
Kaj
26-Jan-2012
[4482x2]
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?
Dockimbel
26-Jan-2012
[4484x2]
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.
Kaj
26-Jan-2012
[4486]
Regarding integer64!, wouldn't it currently be possible to fake it 
with float! to pass them around to bindings?
Dockimbel
26-Jan-2012
[4487]
I think it should work.
Endo
26-Jan-2012
[4488]
+1 for "??"
Dockimbel
26-Jan-2012
[4489x2]
I guess someone can contribute that to github, no need for me to 
write it? ;-)
FEAT: added `print-line` function to runtime, with `??` as alias. 
Works like `print`, but adds a line-feed character at end.
 

https://github.com/dockimbel/Red/commit/82099d117e790859606697c33f90c35ef87cf5b6
Pekr
26-Jan-2012
[4491x3]
Just imo, but:


1) hmm, I am with oldes - if there is 99% case, where you want your 
"print" to print including the newline, it follows REBOL rule = most 
used case goes first

2) There is nothing wrong with following REBOL compatibility, especially 
if we claim, Red is inspired by REBOL. So 'prin and 'print worked, 
new user would learn their stuff

3) If Red itself will have some REBOL compatibility, I would expect 
both 'prin and 'print there. Now imagine, how messy the translation 
is going to be: print -> print-line, prin -> print ...
it's not a big deal for me, so regard it being just my opinion ...
As Doc is a guru here, the final decision is of course upon to him 
:-)
Kaj
26-Jan-2012
[4494x2]
There are going to be quite a few differences between Red and REBOL, 
anyway. It's a fundamentally different language. You can't expect 
to run REBOL programs unchanged, except in incidental cases
I used to be of the opinion that REBOL clones should be compatible, 
but Red is not a clone, REBOL itself is incompatible between R2 and 
R3, and REBOL in general is fading into irrelevance
Dockimbel
26-Jan-2012
[4496]
Pekr: you should really make the distinction between Red and Red/System, 
they don't have the same goals. People currently coming to Red/System 
are usually C coders, not REBOL-only coders. Things like "PRIN" might 
give a negative feeling on the language design, and it would be a 
pity, because PRIN is not my idea/choice, but Carl's one. At Red 
level (when it will be available), we'll have a wider compatibility 
with REBOL, so to ease the transition for rebolers, PRIN will be 
there (but maybe just as an alias).
Pekr
26-Jan-2012
[4497]
Well, that does not mean, that what worked for REBOL is not worth 
to consider for new language, which is syntactically similar to REBOL?
Dockimbel
26-Jan-2012
[4498x2]
BTW, I don't like much the "guru" word, I prefer "leader" or "lead 
developer".
Just a question: did you have the feeling that PRIN was somehow a 
weird choice when first learning about it?
Kaj
26-Jan-2012
[4500]
I still have that feeling every time I see it
Pekr
26-Jan-2012
[4501x2]
I don't remember anymore. Not liking the word much, as well as another 
funct, func, etc.
I am just sure, if there is going to be so much of a distinction 
between the Red/System and Red itself. I think I am well aware of 
the difference. But - why would anyone use Red/System, without wanting 
 to use Red, which will have some compatibility level?
Dockimbel
26-Jan-2012
[4503x2]
To a lesser extent, I had also a weird feeling with FUNC word, but 
it vanished rapidly, I'm very used to it since years now.
The distinction between Red and Red/System is almost as big as between 
REBOL and C.
Henrik
26-Jan-2012
[4505]
I accepted PRIN the first time I saw it, just going "oh" and memorized 
it for what it did. I don't agree that Red being a fundamentally 
different language means that you must rename trivial functions. 
That just means there are more differences to learn.
Pekr
26-Jan-2012
[4506]
that's it - you just get used to it. Now imagine your source code 
- if Oldes is right, then 99% of time you are going to see print-line, 
instead of print, in your source code. Well, it depends how often 
do you actually print :-)
Kaj
26-Jan-2012
[4507]
It's a more common way of abbreviating than leaving off one letter. 
Still, I changed all my FUNCs to FUNCTIONs in Red/System
Dockimbel
26-Jan-2012
[4508]
Red/System is aiming at being a dialect living inside Red, for system 
and bare-metal programming.
Oldes
26-Jan-2012
[4509]
I accepted PRIN as well... and as I said, it's usage is really rare. 
I would prefere PRINT to do line break.
Pekr
26-Jan-2012
[4510]
Doc - yes, but as I said - will there be many users, using just Red/System, 
not using Red, and vice versa?