• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

DocKimbel
4-Jan-2013
[5095]
I haven't found any good prefix to replace # for issue-as-string!, 
so ## is the only option I see so far.
PeterWood
4-Jan-2013
[5096]
I'd prefer the other way around too. It would make it easier to port 
existing REBOL systems that make extensive use of issue! to Red.
DocKimbel
4-Jan-2013
[5097]
REBOL systems that make extensive use of issue! 
 What systems do you have in mind?
PeterWood
4-Jan-2013
[5098]
The ones that I work one with Gregg.
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.