AltME groups: search

Again, I'm saying what is wrong with having the lit-word? function 
return true for a lit-word value?

Obviously the interpreter can see that it is a lit-word value even 
BEFORE it calls it a word! value.

Trace shows that it does see it as a lit-word

Trace shows that the interpreter - not the lit-word? function - sees 
a lit-word before it gets evaluated

See if I asked someone to tell me what type this is:

'test


They would most likely respond a lit-word.  So shouldn't the lit-word? 
function say the same?  I say it should.

Rebol, the interpreter, sees a lit-word!.  Trace shows this.  It 
*then* evaluates it to a word!, *then* passes it to lit-word?, and 
lit-word? never sees the original lit-word!

I would ask if it's a line of code or data

Trace doesn't show that it evaluates it to a word.  I don't know 
where you get that.

>> Gettype: func [A][print type? A  return A]
>> lit-word? Gettype 'Test                   
word
== false

Well that is my Izkata, how do we know that - are we just assuming 
that?  I mean we know that it can handle the data as a lit-word while 
it is in an unevaluated block.

Surely we can return true with a modification to lit-word? function 
to do the same for lit-word? 'test

Izkata, let my pose a hypothetical question to you.  If lit-word? 
could return TRUE to this statement:

lit-word? 'test

Would you desire that ability?

No, as I would then never know if something's datatype was a word! 
or a lit-word!

sure you would.  a word that doesn't have the tick in front of it 
woudl be a word!

But it's better to submit it as a wish into CureCore and see what 
Carl means

Oldes I was going to personally take it to Carl via RebDev but I 
won't if the community doesn't desire it to report true in such a 
case.

Paul, how would you check that?  String manipulation?  Because trying 
to get the first character of a word! or a lit-word! errors

Izkata, how does REBOL know that this is a string?:

this

Without a context, it doesn't:
>> X: to-word {"this"}
== "this"
>> ? X
X is a word of value: "this"

Izkata, I'm sure that REBOL is written in C language and in C we 
use a char type for this.  So it is possible to detect the ' character.

>> val: first ['a]
== 'a
>> lit-word? val
== false
>> lit-word? :val
== true
>> lit-word? first ['a]
== true


It's not the assignment or LIT-WORD? that is converting the lit-word! 
to a word!, it is DO. This is a good thing.

It is not *in any way* a bug, it is intended behavior.

If you want DO to just get a value and not treat active values as 
values, use a get-word expression. This is evaluation model stuff. 
You need to be able to distinguish between the data that your code 
is working on, from the data that your code *is*, itself.

The difference is between your data:
>> ['a]
== ['a]
and the data of the DO function:
>> 'a
== a


Just because your code is data, doesn't mean your code is *your* 
data. It is actually DO's data, and DO interprets its data as what 
we think of as the REBOL syntax. I didn't see you complain that the 
set-word! in your code was treated as an assignment, or that the 
word! print is treated as a function call. The treatment of lit-word! 
values *in code* is no different from those.

Brian, just for you information.  Remember that in REBOL 'test is 
not a lit-word.

Paul .. Would you expect the argument to this function to be a lit-word 
or a word?

myfunc 'a

>> myfunc: func [word-or-lit-word] [print type? word-or-lit-word]

>> myfunc 'a

word

I suspect it would be a major change to Rebol for functions to receive 
unevaluated values which is what I believe you want.

I believe it would require much more than writing a native lit-word? 
function.

Paul, in REBOL 'test is a lit-word!. The problem is that you are 
getting datatypes and evaluation rules mixed up. When you are evaluating 
your own data, you can treat lit-words any way you like. When DO 
is evaluating *its* data (what you would call normal REBOL code), 
it treats lit-words as active values. Active values are normally 
evaluated when DO encounters them - the only exception is when they 
are just retrieved from some word they are assigned to, either using 
GET, or DO's shortcut for GET: get-words. All of DO's active values 
work this way.


And there is a good reason DO treats lit-words as active values: 
If there were no active lit-words, DO wouldn't be able to refer to 
word values without breaking words as variables, and normal REBOL 
code would cease to function.


When I say that it is not a bug that lit-words are active values, 
I am understating things. What is really the case is that lit-words 
being active values is the *entire reason for their existence* - 
if they weren't active values, there would be no point to them at 
all. Oh, and REBOL code wouldn't be able to work with its current 
syntax.

Brian, my point is that 'test is NOT a lit word  as you can see here:

lit-word? 'test
==false

By the time LIT-WORD? sees the value, DO has already converted it 
to a word!, the way it is supposed to. LIT-WORD? works fine.

LIT-WORD? is just a type test.

Brian, I don't care about what lit-word is actually doing.  I'm not 
trying to understand what it does.  I already get that part.  I'm 
saying it should be modified to identify 'test as a lit-word.

and 'test is a lit-word

You aren't passing 'test as an argument to LIT-WORD? whenn you do 
this:
lit-word? 'test
==false

What you are doing is *evaluating* 'test and then passing *that* 
value to LIT-WORD?. There's a difference.

Trace it Brian.  The interpreter sees it as a lit-word.  It doesn't 
evaluate it to word!

Functions don't evaluate their arguments, the evaluator does. Your 
change to LIT-WORD? would break it. When you DO a lit-word! it returns 
the associated word! value. That is what lit-words mean in DO code: 
Literal words.

Rebol from the command line, as well as a running script IS a 'do 
session, that's what we're trying to get at.  'do is what's converting 
the lit-word! into a word! before it reaches the function

When, you've typed something at the console:

	>> 'test	

, and you press Enter, it is as if this is happening in a script:

	do ['test]


The result is equivalent - a lit-word reduces to a word, which is 
returned.

yes, and
>> lit-word? 'a
can be written as
>> do lit-word? do 'a
or 
>> (lit-word? ('a))

>> a: func [b [lit-word!]][return b]
>> a 'test
** Script Error: a expected b argument of type: lit-word
** Near: a 'test

See to me the question comes down to the fact that I wanted a function 
that tells me what the argument was passed to it as not what the 
function recognizes it as.

So then I have to determine what is a lit-word?  It is merely a word 
that is has the tick symbol at the beginning or is it a word that 
in affect is of the same characteristic as a word with a tick symbol. 
 I chose the latter since it is more in form with REBOL.

Almost does.  I fixed it up a bit for you to give you more of a match 
to my function here:


 a: func [val][if any [word? val lit-word? val][return true] false]

However, you used lit-word? which was what I was avoiding.

>> a first reduce [to-word "test"]
== true
>> as-lit-word? reduce [to-word "test"]
== false

>> a first reduce [to-word "test"]                               
    
== true
>> as-lit-word? first reduce [to-word "test"]
== true
>> a reduce [to-word "test"]      
== false
>> as-lit-word? reduce [to-word "test"]
== false

actually it would be correct in both cases as it would still be a 
block.

Here you go:

>> c: make set-word! 'd
== d:
>> c
== d:
>> a c
== false
>> as-lit-word? c
== true

Paul, I have a hard time following the discussion. Can you show what 
you are right about?

Here is what BrianH said:


You aren't passing 'test as an argument to LIT-WORD? whenn you do 
this:
lit-word? 'test
==false

What you are doing is *evaluating* 'test and then passing *that* 
value to LIT-WORD?. There's a difference.

Brian is saying that 'test would get evaluated to a word and *THAT* 
value is then in turn passed to lit-word? function.  But that isn't 
the case.  Because if it was indeed a word! at that point then there 
is no way my function could detect it as a lit-word!

as-lit-word?: make function! [  

    "Returns logic on whether the val argument is as a lit-word! type"
    val
    ][
    not error? try [= :val make lit-word! :val]
]

A gave the link because the one on my computer actually has the == 
symbol  instead.

>> a: 'test
== test
>> :a == make lit-word! :a
== false
>> :a = make lit-word! :a
== true

Doc, the problem is that Paul never actually passes a lit-word to 
the function, so he can't test for strict-equal?. It just happens 
to work the way he wants for lit-words.

Paul, your LIT-WORD? function returns true if passed a word! value, 
which breaks it.

>> a: 'test
== test
>> type? a
== word!
>> type? :a
== word!
>> a: to lit-word! 'test
== 'test
>> type? a              
== word!
>> type? :a             
== lit-word!

As I see it, 'test gets evaluated to a word.

Doc, I'm testing to see if a word behaves like a lit-word.

BrianH, it doesn't break.  My function is not a replacement for lit-word? 
function.

Doc, the reason in the example above that mine returned true was 
because it matched the error.  But that is what I want because it 
still indicates that the word behaved in a manner of a lit-word.

That is why the function is called as-lit-word.  I changed it yesterday 
to get rid of this idea that it is matching a lit-word.

Since were talking about R3, do you really need a true? function?

It was Carl's function, and he *needs* it for his code, so TRUE? 
will definitely be a mezzanine, not a library function.

Because 0 being false only makes sense for languages without a boolean 
type (logic! in REBOL).

So essentially true? only reports false when it meets a an actual 
false.

Henrik: "BrianH, what exactly does the :value do in function header? 
What is passed?"


What is passed in R3 is the argument, completely unevaluated. So 
you can write this:
    set quote a get/any quote b
instead of this:
    a: :b

It's a departure from C way.  If you want the C way then use make 
logic!

BrianH, perhaps it's time for a little cookbook recipe on MAKE. :-)

I've backported most of R3 to R2 (it bears repeating, because it 
was a hell of a task). 67 functions so far.

So does this mean a 2.7.7?

Since it is all mezzanines then I don't think it should be anything 
more than offered as a mezzanine library.

I think as a minimum for a new version in REBOL - it should contain 
new natives.  Maybe Carl can make some of them natives.

Paul has deciphered the plan. I think it should stay a separate script. 
It breaks tons of R2 code. I expect that we won't be doing a 2.7.7 
soon, and when we do it will just be compatible bug fixes. The future 
compatibility stuff will be in the R2-Future collection.

I disagree with that plan, unless there will be a method to include 
all changes with a single line of code. There are also many additions 
in VID.

Brian, I suggest not waiting for Carl and just offer a library of 
 all the mezzanines that can be incorporated by just 'DOing the script 
to import them.

There are a few functions that were originally written by Carl - 
7 of the 67 are slight tweaks to functions Carl wrote, the rest mine.

Some changes will break VID, so there is probably more reason to 
create a VID extension kit.

Yes, and then release it. Don't wait for a new R2 release.

I have some plans for such a kit, but it depends on if I will get 
time to do it and if it collides with R3 GUI development. It involves 
removing some parts of the current VID, like the WindowsXP style 
buttons and making SET-FACE and GET-FACE uniform for all styles. 
Also adding some new styles and the new resize scheme would go under 
that. It would make VID way less painful to use.

FYI: R2-Forward is currently usable from a DO call, prebol (the SDK 
preprocessot) or Gabriele's R2 module system.

It's about half done and I have a bunch of code files for this. I 
was going to use it for a large VID project, but it has been dropped, 
cutting away 6 months of work for me (phew!).

Carl is not a lawyer, but he knows that you can't encap LGPL2 or 
GPL2 code. MIT is less restrictive than BSD, so it's Ok.

a: [ "23" "Feb" "2008"]

b: copy a

(a== [ "23" "-Feb" "2008"])  a IS MODIFIED, why?

each string in the block is also a series. for your problem to be 
solved, you must use copy/deep.

ah, it does that for a different reason than you might think. b/2 
references the second string itself, not the index in the block where 
the second string is.

you may want to do something like:

insert at a 2 '-


If you don't want to destroy 'a, copy it first, but in this case 
/deep is not necessary, as you wouldn't be affecting the strings 
in the block, only their positions.

anyone know how I can talk to a UNC path on the network

files: recursive-Read %//bens2000as/c$/myTestDir

You can always take a windows path, or UNC path and convert it

to-rebol-file \\bens2000as\c$\myTestdir

This function will return a number that corresponds to the maximum 
summands that can result in the sum of the number without repeating. 
 For example:

1 + 2 + 3 = 6


therefore it would have a value of 3 since their is 3 numbers added 
together.

1 + 2 + 3 + 4 = 10

just be mindfull about the unc paths... any local root dir which 
has the same name as a machine will take precedence...  I have been 
bitten by this on linux. 


I really wish rebol left the double \\ as double // on the root or 
if it had a real machine name separator.  which translated to whatever 
local path it equates to (UNC most probably).

Cheyenne is listening on port 8002 and gives a 404 if a browser is 
used.

>> help system/error/script/call-fail

SYSTEM/ERROR/SCRIPT/CALL-FAIL is a block of value: ["External process 
failed:" :arg1]

kib2: "Does that mean that we can use unicode encoding with the help 
of r2-forward ?"

No, I only can only spoof datatypes that don't exist in R2, and R2 
has a string! type. The code should be equivalent if the characters 
in the string are limited to the first 256 codepoints of Unicode 
(aka Latin-1), though only the first 128 codepoints (aka ASCII) can 
be converted from binary! to string and have the binary data be the 
same as minimized UTF-8.

There are ASCII? and LATIN1? functions that test, char!, string!, 
binary! and integer! in exactly the same way as the R3 natives, and 
a UTF? function that tests the BOM. When ENCODE and DECODE are written 
in R3, I'll backport them too if I can, though they probably won't 
generate string! values.

It is probably better to load R2-Forward as a module (compatible 
with Gabriele's %module.r) - then it will just export, not set global 
words. Scripts written with R2-Forward are more likely to be compatible 
with R3 than they are with R2, so assume some porting will be necessary 
for existing R2 code. It makes a good porting tool though, since 
very little will need to be done to your app to make it R3-compatible 
if it runs with R2-Forward.

What is the etiquette for using metadata in a REBOL header?  Here's 
some scenarios:

A) From Viewtop:

	REBOL [
		type: 'index
	]

	title "My RebPage"


This is clearly ok, and a good way for an application to determine 
the disposition of data - in this case a Dialect.

B) I use this for QM modules:

	REBOL [
		type: 'module
		exports: [do-something]
	]

	var: 1
	do-something: func [val][val * var]


This adds a little more, as the 'exports block is more than just 
an 'id, it's contents are bound to the application.  Moreover, 'exports 
is not in the standard header.


C) A hypothetical dialect definition with some 'do code (I'll use 
VID to demonstrate):

	REBOL [
		title: "My Application Window"
		type: 'vid
		locals: [mybtn myarea]
		on-close: [save-all quit]
		options: [resize min-size (config/min)]
	]

	h1 "My Small App"
	myarea: area "Some Text"
	mybtn: btn "Submit" [save-all]



Now obviously all these cases can be fleshed out with R2, but is 
this abuse of the header?  There's still no security issue 'loading 
the file, indeed it takes a special handler to actually execute the 
code.  But again, is this taking the header where it shouldn't go? 
 What of R3?

Anyone else manipulate headers for more than a trivial degree of 
metadata?

its also (I find) a clean way of presenting end-user options to a 
script which shouldn't really be edited by the user.