World: r3wp

Hey Gregg,  Thanks for the code.  I tried it out and while there 
is a few hicups, I am planning on using that code when I create an 
Excel CSV version in addition to the Tab delimited version.   Thank 
you!

Let me know what the hiccups are, if you can, so we can get a solid 
version out there for people to use. Thanks.

can you tell me why to-file does not care if a word holding the value 
of a file name is presented as

to-file :filename

or  to-file filename

source to-file is very simple  to-file: func [value] [ to file! :value 
]  ; which seems to apply : to a get-word! in the first case

Put another way, what is the rule for when a word must explicitly 
bear the sigil prefix of  :  ? I.e., when is a get-word! required 
and when does any word suffice?  ::word is an error but   to file! 
:myString  in a func is no different from  to file! myString   and 
how do you pur carriage-returns into this message-post box!  ;-)

ed: func [/file filename [string! file!] " afile name" /local fn 
] 
	[either file 
		[either exists? fn: to file! :filename
			[editor fn]
			[fn: ask "file name:  " editor to file! :fn] ]
		[editor {}]
	]

comment { this works the same

ed: func [/file filename [string! file!] " afile name" /local fn 
] 
	[either file 
		[either exists? fn: to file! filename
			[editor fn]
			[fn: ask "file name:  " editor to file! fn] ]
		[editor {}]
	]}

Robert.  get-words are "unevaluated", so no code will execute getting 
to the value.  Most datatypes will return the same value for get 
as for evaluate.  But getting functions will return the function, 
not the result of evaluating the function.  Umm, that's probably 
not a Ladislav level answer, but it's how I think about it.

I'm not completely clued in, but I think get-words can be faster 
as well, as the lexical scanner can skip the evaluation,  In your 
case; evaluating a filename, returns a filename, (and I only assume) 
is an extra (nearly empty?)step than just getting the filename.

For instance.  a: now  gives you a date time field that won't change 
whenever you reference a or get a and it's type is date!   a: :now 
gives you an a that will be the current time whenever it is evaluated., 
but if you get-word a with :a or get 'a you get back the native, 
not the datetime, so a's type reports as native!  It's funky and 
fun.

Carriage returns - click the pencil icon to change to ctrl+s as the 
send key.

>> logname: does [rejoin [now/date ".log"]]
>> to-file logname
== %1-Aug-2007.log
>> to-file :logname
== %?function?

Brian's explanation is good; it's something to play around with in 
the console, to get a feel for things.

what seems a little spooky is the way the behavior Gregg illustrates 
disappears when I define to-file as
to-file: func [value] [to file! value] ; cool - or spooky

REBOL is both and more.  :)   But in that last example, although 
you may have passed the "unevaluated" logname, the function by using 
 the  value  reference, evaluates it.  :)

Try func [:val]  and func ['val]  for even more fun

wilco ;-)

The lexical scanner will pass the "uneval" value in the first case 
and the literal value in the second.  It is tricky, but it slowly 
starts to make sense.

But I recommend practise, and let yourself be confused.  :)

It's a weird time in Altme as well.  The gurus that are usually around 
to give very detailed and exact wording to these issues are all busy 
with R3, so show up here on a less regular basis.  You may have to 
filter through some tier B rebol explanations for the next few days. 
 :)

Now having said that...Gregg, Geomol, many many others dish out good 
help...but watch for Gabriele, Ladislav and some others as they seem 
to have a gift for explaining things so a computer would understand 
without ambiguity.

I'm in a catch-22 now...Gregg and John are gurus, they speak human 
and computer...Gabriele and Ladislav are gurus, they speak computer 
and human...Gregg and John are gurus, they speak computer and human...Gabriele 
and Ladislav are gurus, they speak human and computer...  Just like 
REBOL, I know what I want to say but it's deeper than I can express. 
 :)

Thanks - I don't discourage easily...  The Rebol for Dummies is not 
too very helpful on some points - I now like the 'Official Guide' 
a lot for the path it takes, but some of the typos/misprints must 
have irked Carl ;-)

:)  I've never actually read the books...everything I know is from 
the Core manual, experiments and the guys here.

Robert and all;  I just bumped into this one again...so I thought 
I'd mention it.


none is a weird value, in that it usually looks like none, but a 
lot of time is  'none  the word!, not the value none of type none!

My suggestion...when starting out, get used to typing  #[none]


a: [none none]   type? first a  is word!  and none? will test false.

a: [#[none] #[none]]  nice and safe...  type? first a  is none!  
and none? will test true.

Umm, get used to typing [#none] if you are putting none into a block 
that is.  a: none  does what you'd expect.

The online Core guide is still the best overall language reference 
IMO.

Core manual rather; agreeing with Brian.

Sometimes MOLD can be very helpful, along with TYPE?, to see if things 
are what you think they are. NONE, datatypes, etc. can be tricky 
at times, to know if they are a word or the value.

Is there a list anywhere of what values are actually their expected 
values, and what values are seen as words, when inside a block? As 
in:


blk: [none 1 1.2 integer! [email-:-somewhere-:-net] #an-issue 127.0.0.1]
etc. etc.

If not, someone should make one such list!

All words are seen as words, unless reduced.


>> blk: [none true :word word: 'word integer! 1 1.0 1.0.0 $1 1x1 
"string" <tag> [name-:-host] #i
ssue]

== [none true :word word: 'word integer! 1 1.0 1.0.0 $1.00 1x1 "string" 
<tag> [name-:-host] #issue]
>> head forall blk [change blk type? first blk]

== [word! word! get-word! set-word! lit-word! word! integer! decimal! 
tuple! money! pair! string! tag! email! issue!]


>> blk: reduce [none true 'word integer! 1 1.0 1.0.0 $1 1x1 "string" 
<tag> [name-:-host] #issue]

== [none true word integer! 1 1.0 1.0.0 $1.00 1x1 "string" <tag> 
[name-:-host] #issue]
>> head forall blk [change blk type? first blk]

== [none! logic! word! datatype! integer! decimal! tuple! money! 
pair! string! tag! email! issue!]

Geomol, such a list cannot be made, if I understand you correctly.

Ok, why not? I was thinking about something like Gregg just did, 
but with all the datatypes. Putting the different datatypes in a 
block with a simple assignment and then check, how they're seen by 
REBOL.

Carl wants such a list for   form, mold, to string!,  format (but 
that's R3), add the serial form, score some points and help the beginners 
in one grand pdf-maker datatype file.  Not much to ask, is it John? 
 :)

I would be cool, if we could kick some of the new ones to make such 
a list. It would be a good learning experience.

I think it'll be a very useful and worthy entry for DocBase, but 
it would also be nice to use Gabriele's PDF-MAKER or other page layout 
for a nice reference sheet printout.

*It would be cool*

hmm... that's a good idea. :-)

So...get RT to open DocBase and I'll start right now, oh yeah and 
R3 beta for access to format  :)  Kidding... I was going to be playing 
with PDF-MAKER today, to see if I can add print functionality to 
the Desktop Librarian...maybe I'll use this as a good way learn the 
dialect.  So unless someone else steps up...I'll take a kick at it, 
for R2 datatypes anyway.

hmm, not sure i understand here. what do you want to add to docbase?

I was just kidding...I'm about half way through using your pdf-maker 
(v2) to document the R2 datatypes regarding  to string! form mold. 
 Blog http://www.rebol.net/r3blogs/0092.htmlbut like I everything 
I do now-a-days, it comes pre-expired  :)

To all...by the way, check out Gabriele's pdf-maker.r in rebol.org 
(the docs have a pointer to the new in-progress work for pdfm2). 
 Maybe we'll get printing from REBOL sooner than later.  :)

ah, a table with all datatypes and how they convert to string? that 
didn't seem to be what John was talking about :) anyway... we have 
something like that ;)

True.  John is (I think) talking about a little more, the unevaluated, 
evaluated, versus serialized issue.

Like when is false false, versus (non-obviously) 'false and true.

Yeah, it started with you Brian pointing out, that none is not always 
none. I then extrapolated on that idea to include all datatypes, 
not just none!.

none is always a word. of course, if you reduce the word, you get 
the value. like print is always a word, but if you get it you get 
the function :-) so there is no mistery, words are just words.

the issue is another - that some values do not have a mold representation.

they should all have a mold/all representation though (well, of course 
there are exceptions, like native! and so on.)