World: r4wp
[#Red] Red language group
older newer | first last |
DocKimbel 4-Jan-2013 [5099] | Do you have to process lots of literal issue! values? |
PeterWood 4-Jan-2013 [5100x2] | Yes. The data is stored in REBOL blocks. The "key" for each block is an issue value typically of the form #999999999 (though the length may vary). |
Gregg knows the details much better than I. | |
Jerry 4-Jan-2013 [5102] | It's interesting that we have all the symbols in unicode but still are lack of symbols because of we use only ASCII characters. |
PeterWood 4-Jan-2013 [5103] | :-) |
DocKimbel 4-Jan-2013 [5104x3] | Jerry: keyboards are only able to handle a tiny subset of Unicode. |
The limitation comes from the input devices. | |
Peter: you might want to optimize such structure to use integers instead of very costly issues-as-strings. | |
Kaj 4-Jan-2013 [5107x2] | ##1 looks at least as bad as #if especially because #1 is (American) English, while #if is just one of the many ad hoc inventions in C |
How about @ for a keyword prefix? It has some precedent in TeX and such, I think | |
Jerry 4-Jan-2013 [5109] | I knew that, Doc. |
Kaj 4-Jan-2013 [5110] | ##1 looks at least as bad as ##if |
DocKimbel 4-Jan-2013 [5111x2] | @ will clash with email! syntax. |
Agreed, but we use much more often #if than ##1. | |
Kaj 4-Jan-2013 [5113x2] | I don't think so. mail! always needs to have a name before the @ |
I wouldn't program a system where users would have to enter ##1 for a bug number or such | |
DocKimbel 4-Jan-2013 [5115x2] | nr<space>@red-lang.org would then be loaded silently without any error reported. |
We can still use #1 as we always do. My proposition was just trying to cover some rare cases where we want to process issues as strings. But I see it brings a lot of confusion, so I will probably leave it as-is for now. | |
Kaj 4-Jan-2013 [5117] | I think the split is fundamentally over that I don't see REBOL as just a language for pogrammers, but as an engine for user dialects |
PeterWood 4-Jan-2013 [5118x2] | The system that I'm referring to has been collecting data for 10 years or so. There are hundreds of REBOL scripts that would need to be changed. More importantly , the users have got used to using the issue format when entering data. It would be a massive emotional change and quite a large programming change to move from using issue-as-string. |
I believe that Gregg has many other systems that depend on issue-as-string | |
Bo 4-Jan-2013 [5120] | I prefer # to be used for issue-as-string and and ## (or something else) for issue-as-word. |
Kaj 4-Jan-2013 [5121x3] | empty?: function [ series [string!] return: [logic!] ][ tail? series ] |
-= Red Compiler =- Feature not yet implemented! | |
What's not implemented here? The problem seems to be in the series string! argument | |
Bo 4-Jan-2013 [5124x2] | Do we post Red/System questions here as well? Kaj, is your example for Red or Red/System? I think you're talking about Red. If it's Red/System, 'tail? is not the way you check to see if you're at the end of a c-string. |
But I know you know that. I just wanted to see if I am getting a handle on Red/System... ;-) | |
Kaj 4-Jan-2013 [5126x2] | It's about Red, as can be seen in the compiler output header |
This place is definitely also for Red/System questions. It's only since shortly that Red is here to ask about :-) | |
Ladislav 4-Jan-2013 [5128] | It would make it easier to port existing REBOL systems that make extensive use of issue! - this does not look smart at all, there were discussions about this when R3 design was discussed. There was no significant mention of such systems when the decision was made. |
Maxim 4-Jan-2013 [5129] | I never thought the change to issue-as-word was any improvement. I still wonder what is fundamentaly better about it. IMHO issues are meant to be datas. they used to be promoted like serial numbers or tag labels. AFAICT only pre-processing tools use them as keywords... because they stand out. but in such cases, the actual amount of issues is so low, that any memory saving it would be for them to be words, is virtually insignificant. |
PeterWood 4-Jan-2013 [5130x5] | Kaj, this works for me: Red[] empty?: func [s [string!] return: [logic!]][tail? s] if not empty? "string" [print "full"] |
using the latest commit under OS X | |
... and even when I change s to series | |
Did you mean to use function [] instead of func[] ? | |
One reason it would be bad to adopt a different literal form for the issue! datatype from REBOL (whether any-word! or any-string!) is that it would make it more difficult to exchange data between REBOL and Red. | |
DocKimbel 5-Jan-2013 [5135x3] | Peter: I agree partially with your last argument: it wouldn't change anything about data exchanging with REBOL (as the literal #... form exists in both languages), but it would make some code testing for issue! (vs keyword!) incompatible between them. The point in making issue! work as a word is fast comparison wherever it been used as a keyword or an ID (usually used for lookups). It is not a trivial performance difference, it is between one and two orders of magnitude faster with words than with strings. |
Re-read Carl's blog about it: http://www.rebol.net/r3blogs/0108.html | |
Kaj: about EMPTY?, no problem here, your code compiles and run fine. | |
Kaj 5-Jan-2013 [5138x5] | The problem is gone with the latest update from Git |
Peter, no, I did not mean to use FUNC. I like to standardise on the full, comfortable form. In a compiler, the overhead is no problem | |
Is | |
empty?: :tail? | |
not supposed to be supported yet? | |
DocKimbel 5-Jan-2013 [5143x2] | No, it needs specific support for functions. EMPTY? definition needs to be caught by the compiler to populate its internal functions table. |
Function support will be completed once objects will be added. | |
Kaj 5-Jan-2013 [5145x3] | OK |
Note that most respondents to Carl's old blog liked to keep issue! as is | |
From there, how about \ as a prefix for keywords? | |
Andreas 5-Jan-2013 [5148] | As preproc directives such as #if should stand out, it will be hard to find anything better than #. |
older newer | first last |