World: r4wp
[#Red] Red language group
older newer | first last |
Arnold 6-May-2013 [7528x3] | No rejected items yet, looking good! Point 5 and 17 both have a wish for a BREAK. |
What do we need GOTO for in Red? GOTO END-PROGRAM ;) | |
Array type +1 | |
DocKimbel 7-May-2013 [7531] | Arnold: I haven't processed the list yet. |
Pekr 7-May-2013 [7532] | Array type + 2, no matter if you processed it :-) |
DocKimbel 7-May-2013 [7533] | Having an array type is probably not as useful as you might think. The only real advantage I see is the ability to add optional bound-checking, which should protect from a whole class of errors. |
PeterWood 7-May-2013 [7534] | Array syntax is a little more "average" programmer friendly than allocating memory and user pointers though :-) |
Arnold 7-May-2013 [7535] | But only just a little! :D @Doc I guessed that! It looks other way for outsider(s) (undecided) |
DocKimbel 7-May-2013 [7536x3] | Peter, it is possible to add literal array notation support without adding an array type. |
Also, even if you can statically allocate memory, you still need dynamic allocations too. | |
Peter, what kind of "array syntax" do you have in mind? | |
Arnold 7-May-2013 [7539] | For other purposes arrays are not a replacement for pointers. But for the majority of small uses of arrays they take away the need for the administration overhead. It is handy and easy. |
Gregg 7-May-2013 [7540] | Is there a Red/System page that states its goals? e.g., Is Red/System meant to be bare bones, or do you see adding some higher level elements, like D. I ask because D has various array types, and didn't know if you planned to implment a few core elements at the lowest level, so they can be used in Red/System, and then just exposed to Red. |
DocKimbel 7-May-2013 [7541x3] | Goals are stated since the beginning here: http://static.red-lang.org/red-system-specs.html#section-1 |
Red/System is supposed to remain small in order to be usable as a Red dialect for low-level programming. I don't have any plans to add higher-level features, because they will overlap or collide with Red's own features. | |
So, it's fine to add Red/System features as long as it helps Red language construction or extends the low-level accessing abilitites. | |
Gregg 7-May-2013 [7544] | Thanks Doc. |
PeterWood 7-May-2013 [7545x2] | I''ll add an idealistic array wish page to the Github Wiki. |
It's here https://github.com/dockimbel/Red/wiki/Ideal-array-capabilities Comments appreciated. | |
Gregg 7-May-2013 [7547] | Re #7, while I understand the reasoning behind the op names, I prefer remove/append/take/insert. I'm OK with other terms, though REBOL's choices are nice. I used to write OO stuff with ops named based on the data structure, e.g. push/pop for stacks, but Bertrand Meyer's argument for Linnaean naming conventions swayed me a long time ago. |
Arnold 8-May-2013 [7548] | @arrayproposal: I really like the index to run from 1 to 10 and not from 0 to 9. I suspect this is because I happen to be a human-being not a computer. Maybe I could live with this different in Red (1 - 10) and Red/System (0 - 9), because Red is higher level and Red/System being low level, but that might be confusing too. |
GrahamC 8-May-2013 [7549] | where does I/O appear in the list of priorities and timetable? |
MaxV 8-May-2013 [7550] | +1 Arnold |
PeterWood 8-May-2013 [7551x8] | For Red or Red/System Graham? |
I/O for Red/System is likely to be a library rather than in the language itself. If I remember correctly Kaj's C lib provides I/O support. | |
I/O support for Red is very high on the Red todo list - basic I/O support is essential for Nenad for Nenad to write Red/System V2 (which itself is essential for "production ready" Red. | |
I believe that object! datatype and an improved 'LOAD function are pre-cursors to I/O in Red and the reason that i/O isn't top of the priority list. (Of ocurse, I may be wrong) | |
Gregg I will note your suggestion in the wiki. | |
(Though I suspect that my initial wish is very much a "wish to far"). | |
Arnold, MaxV - The array wish includes the ability for the programmer to choose between zero-based and one-based indeces as it allows the user to specific the array range. | |
This really is a mega-wish list. It is very possible that adds far too much bulk to Red/System to be added in the language. At least the list could be the basis for the spec for a Red/System lib to provide much of the functionality. | |
GrahamC 8-May-2013 [7559] | @PeterWood - Red thanks |
DocKimbel 8-May-2013 [7560x2] | My first impressions on your proposition: 1) arr[i] is a useless syntactic addition as we already have indexed accesses: arr/i 2) #7 and #8 are going way too far from the Red/System application domain, it's basically a series abstraction. Red internal API already provides series (the internal API is not yet completed nor formalized though), so this is both unneeded and overlapping with Red standard library. What you might not realize is that you already have array-like capabilities with Red/System pointers (including structs and c-strings). If you want automatic memory management in Red/System, you won't have it, low-level programming requires a manual management of memory for accuracy and avoiding unnecessary burdens. The only array-like part that Red/System is really missing right now is the literal array-like declarations, which can be achieved without a new formal array! type. As I said earlier, adding a array! type would only add bound-checking abilities (which is a nice feature to have) and provide you with #5 as a side-effect (not very useful anyway, as array would be fixed-size). |
One of Red/System DSL goals is to be as close as possible to the hardware, not as far as possible. This implies that no arbitrary abstraction layers will be ever added to Red/System that can't be more or less directly mapped onto some hardware features. Exceptions exist when some targets do not provide a basic feature that others are providing. For example, ARMv5 family do not have integer division, nor modulo support, so I had to implement it manually in the ARM emitter in assembler: https://github.com/dockimbel/Red/blob/master/red-system/targets/ARM.r#L372 Another one is the runtime exception system recently added (THROW) to Red/System, which also required a specific assembler routine: https://github.com/dockimbel/Red/blob/master/red-system/targets/ARM.r#L2008 | |
PeterWood 8-May-2013 [7562] | Thanks for the clarificaiton, it's helpful. I keep thinking of Red/System as a standalone langauge (because I like it so much). |
DocKimbel 8-May-2013 [7563x2] | I like it too and I think we can improve it significantly in 2.0. |
Being able to do whatever C does without its outdated syntax and bloated toolchains is a dream coming true. ;-) | |
Kaj 8-May-2013 [7565x5] | Graham, if I/O is stopping you, you can have it right now in my extended Red binaries |
With the new shared library code, I have been able to compile a shared library on Linux for the first time | |
I can compile a Red/System extension with the R3 bridge and load it into R3. However, only two of the COMMAND examples work: | |
http://red.esperconsultancy.nl/Red-REBOL-3/dir?ci=tip&name=examples | |
HELLO and INCREMENT work, the others segfault | |
DocKimbel 8-May-2013 [7570] | Andreas: thanks a lot for this new contribution! Now that shared lib generation support is unlocked for Linux, we'll be able to finally start working on the Android full support (amongs other new targets). |
Pekr 8-May-2013 [7571] | According to Git it seems that global variables and on-load/on-unload are not yet supported. How limiting is that? |
Kaj 8-May-2013 [7572] | Not very, at the moment |
DocKimbel 8-May-2013 [7573] | The main effect is that Red/System init code is not run when the shared lib is loaded, this affects floating point exceptions flags and runtime error catching routines. Not a problem for now. |
Arnold 8-May-2013 [7574] | @Peter I took the liberty of commenting the document here https://github.com/dockimbel/Red/wiki/Ideal-array-capabilities We could add Nenad's comment on it too. It is a giant wishlist indeed :) @Nenad, "Being able to do whatever C does without its outdated syntax and bloated toolchains is a dream coming true. ;-)" it is :) |
DocKimbel 8-May-2013 [7575x2] | Peter, you should add an "Author:" field in the wiki page header, so that it's not being misinterpreted as being a Red official page. |
Oh forgot it, I can edit it directly. | |
Arnold 8-May-2013 [7577] | DId you by accident wipe the page Nenad? |
older newer | first last |