World: r3wp

Typeset! is a new datatype in R3. Function argument type specs are 
converted to typesets at function creation time.

and how would the typeset be specified after the /search refinement?

There is no order in a typeset!, it's a set.

ok, got it - so the order is lost and can't be enforced

if that's the way it is, then I guess we have to live with it

I'll ok the ticket as you have it then - sounds good in other respects

It's the way it is in R2 as well. The order has never mattered. HELP/search 
of a typeset! is covered in the comment - I'm not rewriting it :)

so specifying help/search integer! string! would create a typeset! 
of those datatypes, no? I'm just thick and what I was asking above 
is how do you specify a typeset! - in your comment you only show 
help/search integer! (though you mention that the last value could 
be a datatype or typeset)

HELP/search (to-typeset [integer! string]) so far. HELP/search [integer! 
string!] sounds like a good equivalent - I'll add it to the comment.

REBOL doesn't have variable length args without putting them in blocks, 
remember.

heh, yeah

This should be easy to add to R2-Forward as well.

I'm happy with what's there so I ok'd it

Cool :) To answer your question: Not this week, but it's on my list.

I suspect there is a misunderstanding here. It seems to me Adrian 
wants to search for functions that take two arguments, one integer! 
and the other string!. It seems to me Brian proposes a /search refinement 
that searchs for functions that have one of the arguments accepting 
integer! or string!. These are two very different things.

Gabriele: Brian explained to me that the order of the arguments in 
the spec is not preserved when a word is defined since the spec args 
are kept in a typeset! which doesn't preserve the order. In the last 
part of the comment to the ticket, he describes how you would specify 
a typeset! in the /search refinement (help/search [integer! string!]). 
This would let you search for definitions where at least two of the 
arguments are integer! and string! - in any order. It's not exactly 
what I was asking for, but it's all that can be done with the metadata 
that is retained from the definition.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.

Adrian, the order of arguments are preserved in the spec, but the 
order of types in the typespec for a particular argument are not. 
That is what I meant. Do you also want to search for functions that 
take multiple arguments, by the types of each of those arguments 
(their names don't matter), in the order specified? If so, why?

I'm having a lot of trouble coming up with a use case for that behavior 
in REBOL.

Or a way to specify it that is simple enough for a function that 
is, by its very nature, primarily used by people who don't know what 
they're doing, if only for a moment. I use HELP often, but only when 
I need help.

as a new user to REBOL, you tend to browse around to discover new 
functionality - least I do. The example I gave before was to answer 
questions like "what can I do with two strings?" or "or "what can 
I do with a block and an integer?". Typically, you tend to have a 
bit of a clue as to the datatypes you're working with, but you often 
can't recall the function names

I mean you typically have a clue to the datatypes for particular 
kinds of operations

from experience in other languages

It's funny, I've found that experience in other languages tends to 
make REBOL more difficult to understand, with some notable exceptions: 
Lisp-family languages, assembler, and Icon :)

I suppose, though, that if the type information is often (most of 
the time?) not there this type of lookup won't get you too much

Any experience in a language with C-like syntax trips you up, for 
instance :)

With the possible exception of Nemerle.

yeah, I found that I had to make a significant mental shift to grasp 
REBOL - all of a sudden though, it became clear - almost an epiphany 
- I think btiffin had a good list of the various stages of understanding

I wonder if this non-REBOL experience will hinder wide scale adoption

The worst problems come from comparing REBOL to any compiled functional 
language not in the Lisp family, like Haskel.

REBOL's not going for large-scale adoption. With software-as-a-service 
and the huge programmer population, even a niche language can have 
huge impact and lots of developers. We don't want the mass market 
- that road leads to Java or VB.

well, if you can believe it, I've been "following" REBOL since it's 
beginnings, but never really pursued a deeper understanding of it 
due to various reasons (lack of adoption, closed nature of the language, 
lack of time on my part, etc). I have always, though, felt a very 
strong attraction to it because of all the possibilities hinted at 
- the lightweight nature, the clarity of expression, the built-in 
GUI, dialecting, and so on.

with R3, I'm trying to take the time to really learn it - I'm also 
learning patience at the same time

it's been baking for quite a while - but I can smell the goodness!

I learned a lot about R3 by writing R2-Forward. Perhaps you can learn 
something by reading it.

I will use it as an example for sure - I was wondering though - the 
documentation on the diffs are pretty important - it creates essentially 
a hybrid REBOL and without detailed docs explaining the diffs, it 
might make it harder to know what's what - you did mention the release 
notes in the code, but that's not so accessible for quick reference

It's not meant to be a quick reference - it's meant to be read thoroughly. 
The code is written for clarity where possible, but also optimized. 
There's about 8K of comments too.

The R3 docs will explain the differences, where necessarr, eventually. 
For now, consider that a function is defined in R2-Forward to be 
evidence that it has changed.

Every function that is different from its R3 version has notes that 
explain how it is different. The only lacking docs are Unicode-related.

so, the approach that should be used with R2-forward is - program 
as if you were using R3 and when seeing a difference try see if it's 
due to an R2-forward limitation or a bug, no?

That's what I do with it at work.

It also helps because the R3 docs are better organized than the R2 
docs, so it's easier to just use the R3 docs, thougn they need work.

There are some gotchas - I didn't redefine any R2 natives in the 
main module. That is on my todo list for a suplementary module.

I was thinking about where/how REBOL might hitch a ride on Java's 
success and popularity - being in the server-side Java space for 
quite a while now, some of the trends are pretty obvious to me - 
and some of this touches on some of the unfinished business in REBOL, 
namely modularity - are you familiar at all with OSGi Brian?

Not with the term. Cleaning up R3's modularity is the next thing 
on the todo list, and I will backport it to R2-Forward as much as 
possible. Most of the hard work of the backport has been done already 
by Gabriele in his %module.r. By the way, if you don't use R2-Forward 
as a module, a lot more code doesn't work. The new words are just 
exported from it when loaded as a module - they redefine the global 
words when you just DO it. Those changes to global words can break 
other parts of R2 in unknown ways. If you just import the module, 
only the words in your script are redefined, so only your script 
has to be made compatible.

I'll keep that in mind

This is how I use R2-Forward safely at Qtask without changing the 
rest of the codebase, for instance.

here's an outline of what OSGi is from the horse's mouth, if you 
care to look - http://www.osgi.org/About/WhatIsOSGiand some of the 
benefits - http://www.osgi.org/About/WhyOSGi. I'll try to explain 
where I see REBOL taking advantage of this.

essentially, OSGi is all about modularity and dynamic services

by specifying very clearly the dependencies among modules, different 
versions of the same code can run in the same runtime