World: r4wp
[#Red] Red language group
older newer | first last |
sqlab 5-Jan-2013 [5149] | there are still § & ~ unpopulated and without a special meaning .) |
Andreas 5-Jan-2013 [5150] | Note that § is not immediately available on US keyboards |
Maxim 5-Jan-2013 [5151] | and & is a word character |
Arnold 5-Jan-2013 [5152x3] | An altenative for preprocessor command could be .if (It starts in column 1 doesn't it?) On the other hand isn;t it possible to get the meaning from the context? #if #define etc could be preversed preprocessor words? (or I am on a complete other level again this time) |
preversed=preserved | |
(The sz sign i a bad choice as is the ¤ or the & ^ * @ and Euro sign together with all backets and braces.) | |
Oldes 5-Jan-2013 [5155x3] | #if# ? |
#1 2# if one needs it as a string, I consider current Rebol behaviour as confusing: >> probe to-string probe to-issue "1 2" #1 1 2 | |
in my case I used issues only as preprocesor commands and for storing color values in my dialect (which I could replace with the hexadecimal number which is in Red already) | |
Gregg 5-Jan-2013 [5158x3] | Carl's post was interesting because (and I think this is true for Carl in general) he sees himself as a regular REBOL user, so when he decides on a design point, he extrapolates that to general use. Fortunately, his choices are generally very good. :-) In this case, he was the one who set the precedent of using issues as keywords, which I think came from familiar syntax for them in other languages. |
My question then, as now, is what are the benefits, what do we give up for those, and what are the alternatives? I do think the # sigil is U.S. centric, so it works for me. It may not make sense in other parts of the world. | |
I like things that are different to look different. But we don't have many goods chars left as leading or bracketing sigils, and I don't know if Doc has anything planned for those (e.g. [! @ & ~ | _]). The doubling of a sigil, to me, seems more like something we want to use as a convention, not a datatype. But the real question is what value each datatype adds. I've asked Carl a few times about a marker! type, for use in tagging locations in documents. Good chars for those are not easy to type († ‡ §), but could have mappings from (+ ++ $ $$). And now hashtags are a widely used meme. What lets us add meaning and clarity to the things we write, beyond just code. I still think REBOL's great success in expression comes from the fact that it was designed for data exchange. | |
DocKimbel 6-Jan-2013 [5161x3] | Note that most respondents to Carl's old blog liked to keep issue! as is I just see people expressing irrational fears... I was pointing on this article to refer to Carl's statements about issue! which I completely share: It was a good attempt, but rarely, if ever, has it been used. Normally, we use strings for those types of values. Instead, the issue datatype has gained usage as a meta keyword. Also, I fully agree with him that having issue-as-word is more helpful than having issue-as-string. |
I agree with Andreas, the change to issue-as-word (== keyword) has been motivated mainly but preproc directives, so, we certainly don't want to change their syntax, there is no problem there to fix. My question was about adding or not an issue-as-string datatype and what literal form would it then have. | |
Actually re-reading Gregg post above about # sigil been US-centric and the popularity of hashtags, it seems to me even more interesting to rename issue! datatype to keyword!. | |
Pekr 6-Jan-2013 [5164] | hmm, from compatiblity to Rebol point of view, is the rename needed? |
DocKimbel 6-Jan-2013 [5165x2] | Which Rebol are you referring to? R2 or R3? |
You should be aware that you will never have a 100% script compatibility between R2/R3, R2/Red and R3/Red. This means that migration tools would be required anyway for R2 scripts. Adding some rules to change issue! to keyword!, issue? to keyword? and to-issue to to-keyword is really not the biggest show-stopper. | |
Kaj 6-Jan-2013 [5167x4] | As for me, don't bother adding another issue-as-string. I won't use a syntax that's not compatible with natural language. I'll have to do string processing and convert the original issue! syntax to string! |
string parsing | |
quit: :halt q: :quit | |
How come this works in console? Is it because they don't take arguments? | |
DocKimbel 6-Jan-2013 [5171x3] | No, it works because it is interpreted, which is an execution model very different from static compilation. In the interpreter, there is no need to make internal tables for functions or variables, they are simply resolved at runtime. |
That is why the interpreter will be useful to fill the gaps that are too complex or too expensive for the static compiler to cover. | |
The JIT-compiler will also be used to fill those gaps when it is more effective than the interpreter (mainly code with loops). | |
Kaj 6-Jan-2013 [5174] | OK, I wondered because this code is compiled, before the interpreter is started |
DocKimbel 6-Jan-2013 [5175x2] | Ah, if it is compiled, let me see... |
Ok, same answer. :-) | |
Kaj 6-Jan-2013 [5177] | :-) |
DocKimbel 6-Jan-2013 [5178x3] | The compiler generates code to pass the function! value from :halt to quit:, then the interpreter evaluation `quit` by analyzing its value, detecting a function!, then processing it. |
evaluation = evaluates | |
The compiler needs to do that at compile-time, so it needs to recognize what is a function! call and what is not. | |
Bo 6-Jan-2013 [5181] | Doc, in your opinion, is Red/System mature enough to write graphical apps in Linux on the Arm processor? |
DocKimbel 6-Jan-2013 [5182] | Red/System is in beta stage. Whether or not it is a good choice for a GUI app is matter of personal taste. I personally gave up building GUI apps in a C-level language a long time ago. However, if you want to give it a try, I recommend you Kaj's GTK+ binding, which now works fine on Linux ARM, as shown here: http://static.red-lang.org/rpi-gtk-widgets.png You can see the source code for this GTK+ demo here: http://red.esperconsultancy.nl/Red-GTK/artifact/3453dd410a1c64ca8f842f75c7431b6f7fc3c4b3 As you can see, Red/System has some limited dialecting capabilities that Kaj leveraged to build a very nice GUI dialect (which is quite an achievement for a low-level language). |
Gerard 6-Jan-2013 [5183x2] | Thanks Doc for sharing this information and Kaj for doing this GUI binding, paving the way for newcomers and sharing the source for deep study. When I will be going back to my former status (more free time) I plan to deeply study Red/System in parallel with the C language just to be able to write some small doc (or book) to help newcomers to start with Red/System after coming from the C environment. In fact it's a long time I planned to do it for myself first but never found the time to do so when I worked as a teacher in the past. Now I hope I will better drive my diary to cope with this new planniing !!! |
Doc or Kaj, do you think it would be usable on my Android tablet - since it uses Linux on Arm as basis ? Already I can use the R3 port from Cyphre and the console is working fine. The single problem I see for now is that the Red/System app is still not working on my tablet ... but I suppose some time in a near future this will be a thing of the past. Bue Doc I don't tell you this so you feel yourself as if you would put more time on this issue. This is not even disturbing me for the moment sinc in any case I don't have much time left for now - so even if it already worked I couldn't use it anyway. It's damage I don't know more by myself about all these new computers and environments but I have to think I'm not alone in this case ... Regards | |
Gregg 6-Jan-2013 [5185x3] | Keyword! sounds much more like it means a reserved word in the language to me. issue! keyword! label! marker! cue! |
Still, I'm sure I could get used to keyword! as it could be interpreted clearly in the different contexts where issue! is used today. | |
If used as keywords/hashtags in messages (blocks), would they be better as word! or string! values? Limits versus speed I suppose. | |
DocKimbel 7-Jan-2013 [5188] | Gregg: (I'm not sure if I understand your question correctly) If you use an issue! as a keyword/hashtag, it will be better for issue! to be a sub-type of word! rather than string!. |
Kaj 7-Jan-2013 [5189x3] | Gerard, Red currently works better on generic Linux for ARM than Android. All support for Linux is available on ARM, but Android is quite different |
It's possible there's currently a problem with Red/System on Android. Can anyone confirm this? | |
Other than that, many of the libraries that I bind are not or not easily available on Android, so functionality is currently more limited | |
DocKimbel 7-Jan-2013 [5192] | A possible cause of the hello app not working on Android anymore is a mismatch between the output encoding of Red and the expected one from the Java wrapper. I will check that when I'll start working fully on the Android port. |
Kaj 7-Jan-2013 [5193x3] | I can't push to GitHub because it requires a Git version newer than the one available in my Ubuntu of only a year and a half old |
At least, that's what it seems to mean when it says error 403 | |
Got it working through SSH instead of HTTPS. I spent a whole day setting up GitHub to be able to fork and push Red contributions | |
Gregg 7-Jan-2013 [5196] | Doc, what I meant was, if you use blocks as a message structure, you include issue! values as hashtags, you gain speed and storage efficiency. But you may also hit limits. Suppose you have a blog/chat/tweet system, how many unique issues can you have without blowing a symbol table if they are words? Not saying they shouldn't be words, to be clear, just making sure I know how to use them correctly. :-) |
DocKimbel 7-Jan-2013 [5197x2] | Limit for symbol table is available memory, but it would be a bad idea to make the symbol table grow too big with current implementation, it would slow down a lot addition of new words. This could be addressed by using a more sophisticated internal data structure in the future. |
Actually, the worst case is if you have massive number of issue! values and doing transformations of them (insert / remove operations). In such case, you should use string! and convert to issue! once transformations are done. | |
older newer | first last |