World: r3wp

More like this for my needs:

dlt-type?: func [w] [found? any [attempt [to-datatype w] false]]

drop the [word!] requirement from the argument and report true or 
false.

But that doesn't fill a rule block to be passed to parse which is 
my original intention but is still very useful.

I'd still not bother with it :-) how many datatypes will you support?

Sorry, try  [#[datatype! datatype!]  that should restrict the match 
to only datatype values.

Or not.  :)

Or yes, if the source is reduced.

parse reduce ["age" integer!] [string!  set type #[datatype! datatype!] 
(print ['got type 'type? type? type])]

well, he doesn't like the serialization syntax and he won't reduce 
which is a security problem (always wise though)

reduce/only is safe for that no?

evaluating words can still be unsafe

Gee, I guess to be secure you need   reduce/only exclude query system/words 
[integer! string! ...]

or just act on words in your dialect :-)

Yeah, but ...  :)

I know it's already been beaten to death, but I guess you don't want 
to support all of rebols datatypes, so what is wrong with listing 
them explicitly?

>> types: ['string! | 'integer! ]                         
== ['string! | 'integer!]
>> data: ["age" integer! "name" string!]                        
== ["age" integer! "name" string!]
>> data2: ["age" integer! "name" string! "gobbledygook" object!]
== ["age" integer! "name" string! "gobbledygook" object!]
>> parse data [some [string! types]]                            
== true
>> parse data2 [some [string! types]]                           
== false

I'm with Ingo on this. And as far as "being simple", this isn't really. 
:-) When I've needed to parse for datatypes, I either reduce/compose 
or set up rules for the types.

Henrik, pretty much all of them.

Hi Ingo, I'm planning on supporting most of the REBOL datatypes which 
is very long when you consider that REBOL has 54 of them.

So setting types to all of those is not very efficient.  At this 
point using parse to do this is as Gregg said not "simple..

So my next question is if we were to wish for something to be added 
to REBOL to make this task easier and submit it to RAMBO what would 
be the best way to describe what is desired?

We have already put together a set of requests to enhance PARSE. 
This problem could be solved by at least 3 of them.

You should probably exclude function types from your acceptable types 
to store in your database, as well as library! and a few others.

Right now, the only thing that is protecting REBOL from serialized 
functions and objects is the fact that their bindings are not deserialized 
properly. Small blessings, I guess. In the meantime, screen your 
data.

Right now I have a solution in place for the database and have decided 
to continue to allow the types to be inputted.  The pro outweight 
the cons in my opinion with my application.

So setting types to all of those is not very efficient.

 -- Do you mean in the parsing, or in the time it takes to set up 
 the rule(s)?

You could write a script to generate the rules. It could be faster 
than writing them directly.

I'm not worried about the coding, I'm concerned about the performance. 
 If I have to parse a million records or something then anything 
that cuts down on the amount of evaluation is necessary.

I'm a little curious as to why you need to have the datatype of a 
field referenced in the record at all, if you are just using the 
REBOL data model. Wouldn't the data itself have a type? It seems 
to me that specified datatypes of fields would only need to be specified 
once per table.

This assumes that you aren't taking advantage of REBOL's type system 
to do SQLite-style manifest typing.

If you are doing type specifications to validate records, the fastest 
way to do it is to generate static validation rules based on the 
specification, then just apply the generated per row. Static validation 
rules would be faster than dynamic.

generated per row -> generated rule per row

Brian, in my TRETBASE for example when a new table is created then 
one must set the fields and their datatypes such as:

["fname" string! "lname" string! "age" integer!]


but it will always be a format of [string! datatype! string datatype!....]

That is the table spec, right? Not the row data?

I have already got a solution for TRETBASE.

is it possible to write a parse rule that accepts something like 
[ "test" | 123 ] ?

damnit, found out already.. | was apparently a word! :D

["test" '| 1 1 123]

I think my parse rules use lots of temporary variables.. How do you 
prefer to hide these?

1: Hide them from whom, and why?

In general, if you want to hide something about your parse rules, 
you need to hide the parse rules altogether. That is not to say that 
it is a good idea; I've found that in most cases that someone wants 
to hide some code or variables in REBOL, they really want to do something 
else and the something else depends on the circumstances. What do 
you hope to accomplish?

2: You have to be careful with temporary variables.

REBOL parse rules are often recursive, and the temporary variables 
used with them are not. You have to be extra careful to not recurse 
to another trip through the same parse rule before you are done with 
the temporary variables in the first round, or put off setting the 
temps until just before they are used. It's not as hard as it sounds.

1. Hide them from myself :) I don't mind having lots of global variables 
in a small script, but I really don't like it in larger programs. 
To keep things well organized I prefer if variables aren't valid 
in a larger context than necessary, to avoid overwriting, accidental 
use etc. Does context [ ... ] add alot of overhead btw? Maybe I should 
try to use that more often

2. I don't use alot of recursion so far. some [...] usually works 
equally well in my applications. But it's definitely a valid point, 
and I'll try to keep it in mind

The only execution overhead of context is when it is built - nothing 
extra at runtime. The memory overhead is minimal. Every word is defined 
in a context, even the global ones. Overall, using an object to wrap 
the temporary variables that your rules use is not a bad idea. As 
long as you are doing this to better manage your program and reduce 
the scope of errors, it is great.

context [ ]  is just a shortcut for  make object! [ ]   and it's 
great.  The more we hide in objects the easier it will be share, 
or at the least, easier to use code from a variety of developer sources. 
 Programming in the Many is important  in our context as there are 
relativily few of us in the "many" - so far.  So when even our small 
stuff is shareable we all  win.

I often use contexts with parsers, to contain the rules.

what about 'use

tmp: 1 use [tmp][ parse "test" [copy tmp to end (probe tmp) ]] probe 
tmp

Does a bind/copy on its code block every time it is used.

That kind of overhead is usually only worth it when you can't get 
rid of concurrent use any other way.

Wait, USE may not copy in R2 - that could be even worse.

I should probably not to use the code evaluation so much directly 
in the parse rule block and rather call a function if I need a lot 
of temp variables to process the action.

>> parse [>] [>]
== false
>> parse [>] ['>]
** Syntax Error: Invalid word -- '>

How do you parse that block?