World: r3wp
[Red] Red language group
older newer | first last |
Kaj 4-Sep-2011 [3121x3] | If you could do |
center: constant 1 | |
and have constants be real types that you can check for, you'd be able to stretch simple dialects a lot further | |
Dockimbel 4-Sep-2011 [3124x2] | Supporting first class constants would require to duplicate all existing types... I was thinking recently about adding a PROTECT keyword that would allow to mark any variable as immutable, so they would act as constants. But I guess that such option wouldn't help much for dialects, unless I would also add a PROTECTED? keyword to detect them. |
Also, some kind of namespace support should also help implement more cleanly Red/System-level dialects. I might need that too for Red's runtime as it will grow much bigger than initially planned, due to Red compiling to Red/System. | |
Gregg 4-Sep-2011 [3126] | Very nice Kaj! |
Henrik 4-Sep-2011 [3127] | cool, Kaj |
Kaj 4-Sep-2011 [3128x6] | Thanks |
Doc, for dialects I only need constant integers. The immutability doesn't matter much, so it's more like the symbol! you suggested, but with control over the internal value | |
Namespaces would be good, too | |
Enumerations would also help; they're sort of a namespace type for constants | |
Note that to make the dialects more powerful, I'm making use of GTK's object system, that allows you to check types. So I can distinguish between different Red structs | |
If you would want to support that in Red/System itself, you'd need some sort of user defined type | |
Dockimbel 4-Sep-2011 [3134] | I think that extending the RTTI system to distinguish different type of structs (or at least aliased structs) should be doable without that. Aliases are already a form of user-defined type. |
Andreas 4-Sep-2011 [3135] | Very nice Kaj, congrats! |
GrahamC 5-Sep-2011 [3136x2] | Looks like we'll all have to install Syllable! |
How's the Red timetable going? | |
PeterWood 5-Sep-2011 [3138x4] | Tick-tock. |
Yes, very nice Kaj. | |
Nenad keeps the status updated on the RoadMap http://www.red-lang.org/p/roadmap.html Since taking the decision for Red to compile to Red/System code, Nenad has been spending additional time extending Red/System to be able to do so. It will probably result in less work being needed on the first Red static compiler. | |
Having more people testing red/system would probably help speed things up a little. | |
Dockimbel 5-Sep-2011 [3142] | Agreed with Peter, as Red/System becomes more important now, it needs to be strengthen a bit more. I will publish an updated roadmap duing the SFD event in two weeks. |
Kaj 5-Sep-2011 [3143] | Detecting aliases would be very nice. It would replace GTK's RTTI, which is complex and buggy, and obviously wouldn't work cross-toolkit |
Dockimbel 6-Sep-2011 [3144x4] | Kaj: I have added in the last commit a new virtual path for querying aliases unique ID value: system/alias/<name> The system/alias/... paths are replaced during compilation with a unique ID that should match the one passed for "typed" functions. So now you basically have RTTI on aliases too. |
As it might be a bit verbose in some cases, macros would be welcome to shorten them. In such case, the convention of a "type-" prefix on the alias name would be a good one to follow (will document that in the spec later today). | |
I also plan to add a SWITCH function soon, maybe before the SFD. It should be able to resolve alias names without the system/alias/ path prefix. | |
Let me know what you think about this solution. | |
Kaj 6-Sep-2011 [3148x3] | Great, I'll try it |
What I'm a bit worried about, though, is binary compatibility. How are the values of type IDs determined? | |
I suppose they shift when the program uses different aliases. That's no problem for monolithic programs, but it would be when you try to define an interface to a library or other subsystem | |
Dockimbel 6-Sep-2011 [3151] | They are source-specific, they represent the order of each alias definition encountered by the compiler. |
Kaj 6-Sep-2011 [3152] | Yes, so they're not suitable for standard interfaces |
Dockimbel 6-Sep-2011 [3153x2] | Anyway, whatever value is attributed it should be transparent to users. |
As long you as you use system/alias/ path accessors. | |
Kaj 6-Sep-2011 [3155] | That's source compatibility, not binary compatibility |
Dockimbel 6-Sep-2011 [3156x2] | The value are calculated at compilation-time. |
values | |
Kaj 6-Sep-2011 [3158] | If I ask GTK to determine an object's type, it takes care that it works across versions of the GTK library. You can't use these aliases to build such a library |
Dockimbel 6-Sep-2011 [3159] | You can't build libraries yet in Red/System anyway. |
Kaj 6-Sep-2011 [3160] | Sure, but we will in the future. In other words, we need some sort of ReBin standard |
Dockimbel 6-Sep-2011 [3161] | We'll deal with that when library generation will be possible. Until that, the current solution should be enough. |
Kaj 6-Sep-2011 [3162] | OK |
SFarber 6-Sep-2011 [3163] | If Carl should decide not to continue developing rebol is there anyone else who could take it over? |
Henrik 6-Sep-2011 [3164] | Sure, but I doubt that would happen, since Carl is not likely to hand his baby over to someone else. |
SFarber 6-Sep-2011 [3165] | SO why the mysterious behavior? |
Henrik 6-Sep-2011 [3166x2] | Carl is very busy with another project. |
(let's move to REBOL3 group) | |
SFarber 6-Sep-2011 [3168x2] | I'm trying to make a decision about which language to learn for my own use. |
OK see you on REBOL3 | |
Kaj 6-Sep-2011 [3170] | Help! The current Red is incapable of compiling anything: |
older newer | first last |