AltME groups: search

REBOL is not about being as terse as possible. That's for Perl and 
Rebmu. I don't agree with all the designer's choices, but I can at 
least understand most of them. We all have things we don't like, 
and those things are different for each of us.

I feel like it's almost possible to teach people non-idiomatic Rebol 
and have it make sense from the get-go, where you can really focus 
on the code.  There are ways to keep from triggering "WTF" responses, 
like putting in parentheses when they're not strictly necessary. 
 And it seems so close that it's a shame the last little bit isn't 
done.

The catch is that "the last little bit" is not little at all. It's 
fundamental. I know you know that, but if we change REBOL to work 
like C and PHP people expect, that's what it will be.

experienced programmers have learnt to accept idioms like the requirement 
of parens on function calls.


they have to understand a different set of idioms.  "unlearning" 
that some of what they perceive as "fundamental" in programming is 
hard.


new programmers will have it the other way round if they learn REBOL 
first... why do we needs comas, and parens everywhere.... seems like 
waste.

Depending on how you are presented with something, the "unlearning" 
can be either a joy or a suffering.  Put a kid on a bicycle with 
no training wheels and they fall and get hurt and they might not 
appreciate bicycles very much.  Give them some training wheels and 
let them get comfortable and be happy the day it comes off.

yes, but its still a bicycle. start them of on a tricycle and none 
of what they learned there it is usefull.  on a tricycle, if you 
lean you fall. on a bike, if you don't lean you fall.

Since I was unable to get an answer to my question:


I want to ask you a question related to your refinement-arguments 

initialization" (actually, it is not initialization, but "unused 
refinement arguments", like the /local arguments are usually preferences 
(see the wording of my answers at http://stackoverflow.com/questions/3168226/how-value-function-really-works
)"


from RebolTutorial messing the thing up with a purported incompatibility 
between FUNCT and FUNC, I guess, that this is the place where the 
question would be at least understood. So, is there anybody actually 
preferring the "unused refinement arguments" to be unset, than to 
be set to #[none] at every function call?

that is for 'FUNC.  


not shure what the difference is with FUNCT, but I'd prefer them 
to be none there too, though I'm not currently "schooled" as to the 
intricacies of 'FUNCT and what effects any change would have.

though I (and many others) often use none, to indicate the use of 
a default or fallback value.

Well, anyway, because of this, RebolTutorial completely ignoring 
any explanation makes a bad publicity to Rebol stating that "FUNCT 
and FUNC are incompatible", which is just nonsense.

ok, but that is a fringe case which probably got put there specifically 
to allow that specific pattern so that some command-line functions 
can be simplied... 
its not the intended use of Rebol.


argument passing by reference is rarely used (a few mezzanines and 
highly specialized situations)

Agreed. And things like the R3 behavior for a missing arg when using 
a lit-word! param versus a word! param would be good to note in the 
FUNC docs.

I think Ladislav dislikes lit-word params anyway, as they are a pain 
when generating code, but they make for good examples and thought 
experiments.

they are mainly used for command-lines and code analysis funcs (?? 
for example)

Lad, can you explain simply, what is the difference between func 
and funct which RebolTutorial claims?

yeah, he doesn't seem to grasp that there is just one function! type 
 ;-)

and there is that nice little line in funct :   collect-words/deep/set/ignore

which pretty much explains it all  :-)

And, in my opinion, this actually *is* a gotcha for beginners

/local x  sets the value of x to none in the F above.
if F was defined like so instead (R2)

>> f: make function! [/local x [any-type!]][[x:] value? 'x]


then you can call it with with unspecified /local arguments and it 
will yield #[false]

>> f/local
== false

A little note about FUNCT vs. FUNCTOR: The word "functor" has a specific 
meaning in computer science, and that meaning is *not* what FUNCT 
does. There is no standard CS term for what FUNCT does, nor is there 
a standard English term. Any word we use would therefore have to 
be made up. FUNCT is not a bad made-up word: it's short, which is 
good for a function that will be used often in user code, and it 
starts with the same letters as FUNC and FUNCTION without being either 
one of those words.

so if I get you right,  in REBOL: 

contexts are actually closures, 
functs are actually functions 
and funcs are actually procedures

;-)

We actually had a function called FUNCTOR for a while, and it really 
created functors. And it went unused for more than a year, so we 
dropped it. It turned out that what FUNCT does is really useful, 
even though the concept is unique to REBOL. Apparently functors aren't.

FUNCTs and FUNCs are both procedure builders. Neither create functions. 
It's a common naming mistake in imperative languages.

Including C and the Pascal it was based on.

Then it isn't like FUNC, and people are more likely to misunderstand 
the difference. It really is a unique concept, certainly nothing 
like the proc concept in other languages that have that term.

I think proc would make things even worse. Nothing would indicate 
that FUNC and PROC are basically the same, except for a minor (but 
important difference). And choosing which does which is absolutely 
arbitrary.

I'd probably stop using func most of the time, and I can't see myself 
typing funct  20 times a day.


everytime I write it, I feel like I'm writing a less savory femal 
genital word in a strange dialect of german ;-)

Maxim, nothing in REBOL corresponds to a closure, though the closure! 
type is closer than other function types, and many other languages 
call something similar to that a closure too. We don't have contexts 
(though "dialects" are close). Neither FUNC nor FUNCT build real 
functions, but they both build what other imperative languages incorrectly 
call functions, so people won't get confused.

I have two reasons why I like keeping FUNC the way it is:

- FUNC is the simplest function-creating function, so giving it the 
shortest name seems appropriate.

- As a rule, we prefer to not rename old functions and then give 
their old names to new functions. That would be user-hostile.

The rule in bug#667: "We are trying to keep our breaks in compatibility 
of legacy functions limited to semantic changes, removed or changed 
options and such, and only when necessary (see #666). Some legacy 
functions have been removed altogether. None have been renamed yet 
- except as in the example above, with the old name still there."

yes, but its a refinement, and even then, it still acts "locally" 
within that object (I'm assuming its using function locals on words 
in didn't bind to).

(And FUNCT/WITH would warrant a discussion on it's own.)

Yeah. We really gave that and every other detail of the behavior 
of FUNCT a great deal of thought. If only we had given that much 
thought to the name: FUNCT is sort of the default name - Carl made 
a blog about it, and then the discussion never went anywhere, so 
we stuck with the initial name because it was better than the other 
suggestions.

Having trouble finding it. The function is more than 2 years old, 
and first came about during the first closed GUI development project.

what typo quality?  because x and c are adjacent on the keyboard?

If you're a touch typist, x and c use different fingers ... so it 
doesn't matter if they're adjaxent or not

I feel that when reading code, funx  sticks out very well from the 
rest, and it doesn't have that strange esoteric feel which funct 
 has.

I am only partially to blame. I think, even then, I expressed concern 
about the beauty of the word funct. That said, I don't think funx, 
funq, or lfunc are any better. I believe a number of people were 
there and really tried to find a good name.

It really is getting a bit late to bring this up now. FUNCT is already 
in R2 as well, and is in most R3 code that has been written so far.

Yup, everyone here, right now Max. ;-)  Give me a better option and 
I'm there.

yes its like empty? and tail?  I coudn't live without one or the 
other, though one is more stringent...  last? and single?  should 
follow the same path.

And as far as I can tell, the stuff you wrote has never been properly 
documented

and there were a number of reports, including one from Carl, to say 
that 2.7.7 sdk was broken

The whole point to R2/Forward was to replicate R3 behavior. And it 
does so wherever possible or practical.

At the time of the last R2 release the documentation was being reorganized 
and no third-parties had access to it. So I couldn't update the documentation.

As for R2/Forward, the documentation is in the source because part 
of the purpose of the source is to document R3's and R2's behavior, 
through comparison. It should have more docs, but without the context 
that the source provides it is difficult to understand what the docs 
mean. The source is written to be readable too.

It can be fixed, but I don't have the time to work on extra docs 
at the moment. I wrote a lot of documentation in the R2/Forward source, 
and it has the advantage of being tied to the specific version of 
the code that it refers to.

It works with 2.7.*, and likely earlier. My eventual goal is to make 
it work all the way back to 2.5.0, since that is the last R2 version 
on many platforms.

And of course he has to know he has to do this ... and where in devbase 
to find them.

I am strongly in favor of optional function arguments being none 
by default. When combined with type tests that prohibit the none! 
type, it allows you to easily use data flow analysis to handle the 
control flow of the different options. You have to realize that none 
is a non-value too. The main difference between none! and unset! 
is that unset! is usually chosen when a non-value is an error, and 
none! is chosen when it is less likely to be an error. And for function 
arguments, not choosing an option is normal behavior.

when rebol encounters (loads) a word with never encountered before, 
its automatically added to the globals and its is set to unset!  


so just the fact that you've actually put the word in a script, even 
if its never explicitely been explicitely managed by code yet, will 
force the value to be unset!

ex: 
>> ['!!!!!!!!]
>> probe copy/part ( sort first system/words ) 10
[! !!!!!!!! != !== * ** + ++ - --]


so you see, even using it as a lit-word, its already in the system 
words, so asking for an /any, will always return true.

AFAIK, your last example would trigger true no matter how we try 
to define it, cause the fact that you wrote 'orange and loaded it, 
it is defined as unset!  ' :-/


the reason is that words actually are just integers internally, and 
loading a word adds it to that list, so it can be used later.  this 
is why word comparison is so fast, its just comparing two integers.

Chris, we have another function already: DEFAULT. It converts none 
or unset to a default value. This deals with the most common case 
of what to do when you have uninitialized values. The other cases 
are handled by ASSERT/type or conditional functions, though conditional 
functions won't work without extra help if we make optional function 
args unset by default (the extra help being UNSET?, VALUE? or get-words 
and op tricks, the hassle I was talking about earlier).

console hasn't moved and likely won't move until hostkit is done.

Carl says he has tried to build R3 for Solaris, and AmigaOS

And is going to try a 64 bit build since the Solaris pc provided 
by TomC is 64 bit ( .. umm... aren't all PCs 64 bit ?? )

problem with the 64 bit win is that many HW drivers where not ported 
to 64 bit and many don't work as-is.  (my friend can't use her 1500$ 
 sony HD camera, for example  :(

Well, Rebol lost the battle for mindshare on desktops and servers 
.. time to see if we can get somewhere on phones

Graham, do you think phones are important enough to Carl to make 
the necessary effort and compromises?

And then figuring out what advantages REBOL can bring to the table.

Can Jpython and Jruby run on Android?

See http://www.tbray.org/ongoing/When/201x/2010/07/28/Ruby-and-Python-on-Android
for a good high-level discussion of scripting language support on 
Android.

Two pieces of note: JRuby is working on Android, see  Ruboto. And 
SL4A provides an easy way to get started with Android support for 
non-Java-based scripting languages.

Apple has recently relaxed the restrictions on interpreters, on a 
case-by-case basis. Most of REBOL would probably need to be excluded 
from iPhone builds (networking support, for instance). And it would 
be difficult to write cross-platform apps without them being rejected. 
But you could make a iPhone-specific version of R3, and it might 
be approved. Host kit apps only though, no scripts.

Here's an interesting subject: What value does R3 have as a library 
in another app with its own GUI and networking?

Ah, the REBOL data model and the processing of its syntax. Yes, that 
would be a value.

Graham, I'd like to be able to use it for normal scripting - to run 
any of the 100 little scripts that manage data for me on my desktop 
PC, to connect with REBOL formatted data files and text files on 
my web sites, etc.

I've often thought (and may even have suggested, though I'm normally 
so shy :-), that promoting REBOL as a data format would be a good 
thing.

Right. Well, I have friends with iPhones and we are starting the 
Stanford iPhone development coursees, so that would be interesting. 
You would have to figure out how to jailbreak the phone now that 
the security hole previously used is plugged.

And I doubt Carl, as an ex Apple employee, would be particularly 
interested in bypassing Apple's restrictions

What platforms are currently operational?  Win32, Linux32 and ??

The idea that there will only be one significant phone platform is 
silly. We will have to consider Android, iPhone, and maybe RIM and 
WP7.

Market leader is RIM, followed by Android and then IOS

I still have that phone, but I just carry a Windows 7 netbook everywhere 
I go, and a tiny clamshell phone - that setup is much more powerful 
and practical.

My biggest hope is still to see more developers attracted to REBOL, 
and mobile platforms are fresh meat.

Give us the power and the developers will flock

yes, I know - but so far, it seems to me, that most platforms are 
going towards more prohibitive way of accessing their APIs, and overall 
running other environments on them. For corporate sphere, Android, 
Win7 and BB are important, not so much iPhone imo, but if you introduce 
that as part of your app solution, some might accept it.

If the platforms are closed... well, than we leave it behind and 
use the once that are open. And if people use closed platforms, well 
than they have to do without cool solutions.

The only platform that I know of that would prohibit native REBOL 
is Win7 (don't know about BB). However, some platforms (especially 
iPhone) won't allow the full REBOL experience including the GUI. 
Most GUI layouts would need rethinking for the small screen anyways, 
and using native tookkits matters much more on phones (memory, consistency), 
so that's not as big a deal. It does mean that we need to pay more 
attention to embedded profiles of the host kit.

Native code is not allowed on WP7 - you must write for Silverlight 
or XBL (both .NET). This isn't a license restriction though, it's 
technological. .NET code becomes native before it is executed though, 
and GNU has a C compiler for .NET, so it's not so bad. WP7 has an 
app store but they have seen the fallout from Apple's restrictions 
so their store is much less restrictive.

The pricniple behind VID - simple dialected GUI layouts - is REBOL's 
strength. The actual implementation would not be as much of a strength 
on a memory-constrained system with a native GUI toolkit and strict 
UI design rules. However, you can make a simple cross-platform layout 
dialect for phone UIs that tells the native toolkit what to do, and 
then make platform-specific implementations for the various native 
toolkits. Dialecting is REBOL's greatest strength.

Exactly! You would need to redo your layout anyways for the small 
screen (unless the layout dialect is *really* properly strict about 
not allowing sizes, offsets and real colors in its layouts, the way 
the R3 GUI is supposed to be), but the layout dialect itself could 
be very compatible and you could reuse a lot of code.

WRT to all the discussions in ~Vent / Rebol3 GUI etc. I want to make 
some points clear. And, don't interpret things that are not written 
 as these will be false.

1. host-kit release: It's still Carl's job and responsebility to 
release official host-kits. We (RM-Asset team) won't do this.


2. host-kit support: Yes, we spend time to work on the host-kit source-code. 
And yes, we concentrate on these things we need for our upcoming 
projects. All this will flow into the host-kit and be available to 
you. And, I'm sponsoring this effort. Our goal is to help to get 
the host-kit to a stable state ASAP.

and it should be also noted, than many here appreciate the effort 
very much, so thanks Robert.

3. rebol3 gui: We are working on getting VID to a state that it can 
be used for app development. For this we did a complete new resizing 
system, changed the styles etc. This is not yet ready for release 
because to much flux in the design and code. We will release it either 
in form of the official VID via Carl or as our own VID fork, if Carl 
decides that the official VID should look differently.

No decision taken yet and I hope that we don't need to fork VID.

4. styles: We need a bunch of styles for our apps. We will create 
them all if necessary because we need a stable style set that is 
enterprise & bullet proof. Most likely I can't make use of hobby-styles 
in commercial apps. There is a bunch of other requirements to full-fill.


And yes, we will release these too. But, we set the priorities, we 
fix the bugs we think are critical, we work on the features we need. 
I listen to you, we think about it, but decisions are made on a pure: 
Urgent & necessary for business context.

5. Extensions: We will create a bunch of R3 extensions we need. Some 
will be quite special, some more generic. For these we use a mix 
from open-source libs, commercial frameworks etc. Which bings up 
the nice licensing issue stuff if things should be released.


As I hate licensing issues at all, and it's a big time killer, my 
rule is quite simple: RM Asset will have all necessary licenses we 
need, if I can release stuff we think about it. If not, than not. 
Sorry. I don't have time to get all this sorted out to provide a 
perfect-R3-framework to everyone.

6. collaboration: We are absolutly open to it. We support the community 
with everything that's possible. But, our main focus will not be 
to become the community runners. We have our own priorities and we 
stick to them. Next, we focus on getting things done.


If the community talks about a specific topic, no problem, if people 
code something, no problem. If we need something different, we will 
do it with or without the community.

7. financing / sponsoring: To be able to do it, one needs to have 
something to spend. And yes, making money form projects is the goal 
for us. This gives the freedom to spend money on non-project relasted 
R3 stuff we do. This is the sponsoring and investment we do into 
R3. As long as I can finance the sponsoring parts I will do it.


Again, I follow the golen rule: The one owning the gold makes the 
rules.


Meaning, I set the priorities to the things we need or which complete 
some aspects etc. But it won't be a community driven process.

All this won't stopp anyone to bite the bullet and do something on 
their own. If you want to avoid double work, cross-check with us. 
We will tell everyone what we are working on. I will tell everyone 
what our plans are. etc. As transparent as possible.

Again, we will move forward. You can "follow" us and use what we 
have done. You can "accompany" us to help driving things forward 
faster. At the end of the day it's your decision (of course).

But I won't enter any Kindergarten discussions that are not moving 
us forward or where some go nuts because we have clear red thread 
we follow and don't care to much what they think.

That's it. Overall, IMO we have moved R3 forward much faster and 
with greater progress than before. And it's not only because we are 
now coding everything etc. By far not. But at least we have helped 
to get more momentum to R3.

Thanks Robert. I like the fact that a goal is the use of R3 to build 
commercial apps. That means things like accelerator keys and other 
features have a better chance of being seen as important.

I have a XML file and want to handle it by tags like a nested block. 
Are there are any tricks? Or do I need to use PARSE / FIND etc.

What I mean is, do you want to convert the XML to a block and then 
access it like this?

  data/tag

2.100.99.3.1  the use of  function  at  with negative index simply 
returns the whole series - which reminds me to ask why   at   with 
index 0 doe not return the series atfter the last item i.e. place 
you at the end of the series?  The docs for  at   specify behavior 
for a negative index      "Using a negative index N, you can go N 
values backwards in a series:"   PS   I have relocated to Fredericton, 
NB, Canada.  Lovely, green and interesting.

I don't know how much of a pain this would be, but I would like to 
consider overloading of words such as empty?


It would like to see if there were an 'empty? actor if noun is an 
object ...and use that.

I presume that is something that needs to changed in the r3lib.dll 
and is not possible from the hostkit

Well, Gregg and I are only 50