r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

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: