World: r3wp
[Red] Red language group
older newer | first last |
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? |
Dockimbel 26-Jan-2012 [4511] | Everyone will use Red, some library developers or system programmers will also use Red/System. |
Pekr 26-Jan-2012 [4512] | If not, the mindset is closer than you might think. If someone is going to use only Red/System, which you claim being closer to C than Red, than such person can just use - a C :-) |
Oldes 26-Jan-2012 [4513] | I will not use print-line for sure:) |
older newer | first last |