AltME groups: search

What about a polymorphic function ?


if=: func [:sw :gw :op val][op: get op gw: get gw if (gw op val) 
[set sw gw]]

>>a: 1
>>b: 5
>>if= a: b < 10
== 5
>>if= a: b < 5
==none

(and behaves in a little bit different way)

the same goes for R2, a little different though...

but honestly i don't see the gain with that mezz.
if b < 5 [a: b] 
...is short enough and syntaxly less obfuscated.

Steeve also your last expression should this if your trying to capture 
the same mezz    if a < 5 [b: a]

Paul, aha, you do not like the prefix form, and insist on the infix 
form you wrote. Then I have a surprise for you: it isn't REBOL Do 
dialect, since the Do dialect does not allow the infix op to take 
more than two arguments. Nevertheless, you are totally missing the 
point stating, that it would require changing the tokenization - 
that is patently wrong.

Sure it would be - just do a TRACE and you will see that it has to 
be changed.  Do evaluates - it has to be supplied the correct structure 
in order to evaluate correctly.

Paul, you want `b: a < 10` to roughly behave like `b: either a < 
10 [a] [b]`, if I am not mistaken.

If so, such a change would neither affect tokenization nor parsing 
in any way:


That's immediately obvious when you consider that `b: a < 10` is 
just syntactic sugar for `set 'b lesser? a 10`. You surely will have 
no troubles to write appropriate `my-set`  and `my-lesser?` according 
to your desired behaviour. With that done, the only change necessary 
to implement this as default behaviour in REBOL is to use your set 
and lesser? (etc.) implementations instead of the current ones. Tokenization 
and parsing needs not be touched.

It could also be:
b: a - 3 > 11

Again, `b: a - 3 > 11` is syntactic sugar for `set 'b greater? subtract 
a 3 11`.

No change in syntax or parsing would be required. However, the DO's 
evaluation rules for the set-word expression *would* need to be changed. 
Note that these evaluation rules are *not* performed by a parser, 
so changing parsing would not be required, Paul.


However, this change to the evaluation rules of the DO dialect would 
be so fundamental that we would essentially be changing the semantics 
of the language to that of another language. And that other language 
would resemble Icon more than it would REBOL, semantically. And changing 
the behavior of the SET, LESSER?, ... functions would not be enough 
because DO doesn't actually call those functions directly - it calls 
internal code, which may or may not also be called by those functions.


But this is not a problem, because at least you wouldn't have to 
change the parsing. This means that all you would have to do is write 
your own evaluator and pass the code to that instead of DO. And create 
new versions of all the functions that call DO internally, behaving 
the same but calling your DO replacement instead. And create a context 
to reference those functions, and bind to that context instead of 
the standard system context. Basically, all you have to do is create 
a new dialect on the scale of the DO dialect, using the same REBOL 
parser, but different semantic rules.

`b: a - 3 > 11` is *not* syntactic sugar for `set 'b greater? subtract 
a 3 11`, instead it is sugar for the internal code that those functions 
call. So changing the meaning of those functions wouldn't be enough. 
To really make the change, you would have to replace DO. But not 
completely, because all of our code depends on DO remaining as it 
is - so you would need to make a new sort-of DO-like dialect that 
would be used in addition to DO, for those circumstances where you 
need this semantic model. Just like any other additional dialect, 
really.

On the other hand, if you want to change DO's behavior to this, then 
it would require you to create a *new* language, with the same parser 
as REBOL, or one that is completely compatible. Basically, an incompatible 
REBOL clone. It would be hard to use the same parser though because 
the existing runtime code depends on the current semantics, so you'd 
have to replace that code too.

(do not forget, that it would require a nonnegligible effort, from 
me, which I can use for more sensible purposes)

pekr... stripping view out of core and making it work again is probably 
the most complex task Carl has had to do since he's been working 
on R3.


it means he has to formalize quite a few of the core as official 
APIs which he didn't need or intend to do at first.  He  didn't  
*design*  the core with view extraction in mind.  it was a far distant 
goal... as in "someday we could extract view and make it an extension".

other things have been tedious work, but more linear and just implementation 
(unicode support comes to mind here) ... extracting view is all about 
breaking things, and making them work again.  adding bridge code, 
making sure once internal code is safe for use by the outside.  carefull 
planning of design so its improvable.  Correctly naming things which 
internally didn't have to be named so specifically.  


 these things really are a lot of headaches cause there are a lot 
 of decisions to be made which have dire and far reaching consequences. 
   its not just a question of "does it work".

Claude, the R2 mezzanine source, including PARSE-XML, is in DevBase 
(aka R3 chat). It shouldn't be too difficult to adapt it to R3, for 
a library module. It would probably be a bad idea to include it in 
R3 as mezzanine though: History has shown that most people don't 
need to parse XML, and the ones who do usually need to parse XML 
differently from how PARSE-XML does so, and differently from each 
other as well. This kind of situation is what the module system and 
community libraries are for :)

and rebol would be the perfect match  for a light weight extensive 
os like meegoo more the  time pass and more the oportunities to make 
rebol find it's way out are wasted  one after other

the actual big rush in computing area is all in one webrowser no 
such deferencies like local or distant applications will exists anymore 
and in a way rebol/desktop was pioneer in that scope

but at same time what happend in R3 project is somewhat some of the 
coolest thing I ever seen a true complicity is rising between carl 
and rebolers. unfortunatly that's not the kind of things easy to 
communicate around. but yes 3 years of alpha stage because the reboler 
community really involved in the creation bringing at every steps 
their comments  etc ... so it's arsh to say that's a fruitless tree 
of efforts

Which makes me wonder about this separation because there's always 
been a core product

View was not developed by Cyphre. Original View was developed in-house, 
by Jim Goodnow (Carl's friend from Amiga days (author of Aztek C, 
or something like that). What Cyphre did was adding AGG in there. 
Cyphre often tested AGG functionality in form of a DLL, externally 
then Carl patched it in into View IIRC.

Petr, being separate as a separate binary is a different concept 
than being a separate module in the code. View has always been "optional" 
even in R2. Having it as a separate binary means that you need a 
way to "load" it, and that's not trivial if the external part has 
to be able to call in to the internal part.

this is a lot of things to change in the code, but I disagree it's 
a big difference design-wise.

R3's View has always been "external" in the sense that it was in 
the host side. I have seen its sources. the interface between host 
and rebol dll (core) has gone through a couple redesigns (starting 
with the Unicode changes), but in principle View has always been 
"separate".

so my point is, a lot of code changes (due to C not being a very 
nice language from this point of view), but the design itself is 
not going to change very much IMHO. since Carl is a perfectionist, 
he won't release a host that is just "half done" or something like 
that.

I was surprised  that the ++ function returns the value before the 
increment. I believe this is counter intuitive especially when  in 
C-type syntax ++ as a prefix increments the value before it is used 
as opposed to ++ as a postfix where the value is implemented afterwards.

So ++ i in REBOLl is equivalent to i++ and not ++i.

Gab, yes I actually have some secret little links into the batcave 
 ;-)


but I don't have specific details beyond the fact that he is commited 
to the view extraction and that its not a piece of cake.


the rest of my comments really are just by obvious architectural 
analysis and having tried to plug into the core myself and realizing 
how much is still missing to provide an integrated GUI which cooperates 
with the core.   even the event/device/messaging system isn't totally 
usable externally right now.


the command! concept is being rewritten from the ground up so it 
supports some kind of contextualized operation (could this be the 
basis for callbacks into the core?  :-)

and when I mean design changes, Its realy things like: 

   before we could call an action directly within a face... there is 
   no callback procedure in R3 hostkit beyond running a string in the 
   global context.


   there is no object/function support in the extensions, cause that 
   opens up a big can of worms (and some secrets into the interpreter's 
   operation?).


   the current R3 relies on the protection it has living within core, 
   now, Carl will have to open up the core a lot so that he can plug 
   back into it, and yes, since Carl is a perfectionist, he won't allow 
   that openess to be a security risk or half-assed solution.

the command! rewrite was exposed by Carl a while back, Brian can 
probably give more precise details.

PeterWood, when ++ and -- were originally proposed, I called them 
INC and DEC. They changed to the C-like naming later. The behavior 
is good, but the names confuse the very C programmers they were supposed 
to be a shout-out to.

Same here. Especially since the other half of my proposal was INCREMENT 
and DECREMENT functions that did the a: a + x operation. But that 
ended up being too many characters for something so simple.

ok, since post fix are usually unary operations I don't see that 
as a limitation.

yes I can see that there would require a little change in the op! 
datatype to let do know how to handle values before & after, but 
the dialect itself isn't limited in the sense that it couldn't be 
modified...  just being curious for discussion's sake... not a request

a special use of R3 ;-)

Brian can probably give more precise details.
 - No, but perhaps a more precise guess.


Currently a command! contains a reference to a dispatcher (handle 
to the extension, which contains an RX_Call function) and a selector 
(an integer). In theory, the implementation of a command! could include 
(or be) a bit of native code - that is generated at command! creation 
time - to call the dispatcher with the selector, and the address 
of that native code could be provided to an external native function 
for the native function to call. The native code inside a command! 
or its dispatcher would need some kind of synchronization stuff too, 
to manage the transition from external to internal process models. 
Or we could get a callback! type, which would have a GC-safe reference 
to that native code and the dispatcher. Either as the standard command! 
type or as a callback! type, when used as a callback the function 
would need to be GC-safe because external native code doesn't track 
REBOL heap references.

Or we could end up with something completely different :)

Peterwood not only C/C++ the ++ operand exists in most of the languages 
now in days compiled or interpreted... (python, perl, tcl/tk, ruby, 
java, etc...)

most people want i++, instead of i= i + 1 but i always thought the 
right operand instead of "++" should be "=+"  somthing like i=+ is 
in my opinion more explicit...


Pekr; some time the Carl says things we can't understand and mainly 
cause we don't have a full view on the source code he is talking 
about...

modular coding is obvious but  you have several ways to realise it... 
puting preporcesor flag to include or not part of the code when you 
compile is one solution

having them indeferent folders and binaries or libraries is another.. 
And that was always one of my  biggest comment rebol wants to do 
all every where so it ends being

weak every where and doing incompletly most of the things it pretends 
to do ...

he can read the chat thru a browser .. no need to fire up r3

Hmm... Script Error: This script needs View 2.100.28 or better to 
run correctly
So, why does a console app need view ?

Graham:

If I want to set something to the index of a series, or something 
else if it's not there I have to do this

b: either a: find series var [
	index? a
][ 	default ]

when I'd rather do

 b: any [ index? find series var default ]

So how about letting index? also take none as an argument ?

Cool, thanks! We can post a comment to the EMPTY? none blog mentioning 
this ticket as well :)

Done. Also tweaked the ticket to be more specific, and added a comment 
in favor of it.

I can make a prediction, Gradually, other functions will

be modified to propagate the value # none instead of returning an 
error.
This is only the beginning.

I hate having to trap for errors when I always have a default behaviour

Currently, just a bunch of natives have been tweaked in that sense.
remove, take, (and some other i can'"t remember now).

But there is no reason to restrain the invasion of the pass-thru 
behavior.


Indeed, just stop the propagation when a control flow function is 
reached :)

Not systematically yet, but yes on an ad-hoc basis for a few years 
now. Even during the GUI design phase before the first 2.100 public 
alpha.

The real problems blocking systematic fixing of awkward code is:

- A lack of a large enough set of R3 code to examine. R3 is already 
different enough from R2 that the code isn't comparable in this way.

- Not having metrics for "awkward". We've been eyeballing it so far, 
and meijeru and I have been the most systematic about that approach.

But we've made a rather large set of changes to R3 already that fix 
most of the R2 awkwardness.

APPEND is a modifying operation. This is an excellent example of 
where the propagation should stop.

did you know rebol has a fantastic thing called.... a function?  
and yes... you are allowed to write these !!  ;-D

well, 'include is a polysemic vocable, not the best choice.

Yeah, discouraging that use in R3 is a good reason to call the function 
INCLUDE.

Sorry it's a term I like to use in French and I just googled a traduction.

No, I usually can't use words in conversation unless the person understands 
them. Most non-technical conversations fall apart when too many words 
have to be looked up in a dictionary - it breaks the flow. So, unfortunately, 
I don't often get to use cool words like "polysemic", and have to 
translate them to more accessible language instead.

But back on topic, we all know that Ladislav and Maxim have been 
using functions named INCLUDE to write their own code organizing 
or module systems over the years. But R3 has a standard module system 
already. We want to encourage people to use *that* module system, 
or to improve it if it isn't good enough for them. Code written for 
incompatible module systems is incompatible because of that, and 
thus can't easily be integrated or reused. This leads to fragmentation 
of the community code base, which we definitely *don't* want. Especially 
since the proposed standard library of community-provided R3 modules 
is supposed to be compatible with R3's module system, and each other.


So we definitely don't want to reserve the word "include" for use 
by alternative module systems, because we don't want people to *make* 
alternative module systems for R3 unless they are compatible supersets 
of R3's module system, which uses IMPORT instead (different concept 
too).


R2 is a different matter: We're already stuck with different module 
systems and incompatible code bases, and they have to keep working. 
Even if a R3-style module system gets backported to R2 (and it will 
be) it will have to be an optional addon. And if INCLUDE gets added 
to R3 as the opposite of EXCLUDE, there would be downsides to adding 
it to R2. We wouldn't be able to use it in any mezzanine code because 
the function would be overriden by Maxim's module system or Ladislav's 
non-modular code organization system. So INCLUDE probably wouldn't 
be backported.

Do we have anything in R3 that equals PREBOL? I use this pre-processing 
quite a lot to include code (features), logos, colors etc. user dependent.

It's the next thing on my list to rewrite PREBOL to be compatible 
with R3's module system. The syntax should be a compatible superset, 
but the internals will be a lot different.

Yeah, discouraging that use in R3 is a good reason to call the function 
INCLUDE.

 - if I understand you well, by "discouraging that use in R3"  you 
 simply mean, that you discourage to use a Rebol preprocessor in R3 
 (since my INCLUDE is just that). Then, I see it as inconsistent, 
 taking into account, that later you expressed an opposite viewpoint.

we all know that Ladislav and Maxim have been using functions named 
INCLUDE to write their own code organizing or module systems over 
the years. 

 - I have to disagree with this. AFAIK, Maxim never used 'include 
 as a name for that purpose

So we definitely don't want to reserve the word 

include" for use by alternative module systems" - have to disagree, 
again. My INCLUDE is not an alternative to a module system - it is 
a preprocessor, as everybody using it knows.

Is that a contest ?

It's the next thing on my list to rewrite PREBOL to be compatible 
with R3's module system. The syntax should be a compatible superset, 
but the internals will be a lot different.

  - hmm, reinventing the wheel? (my INCLUDE is already available from 
  rebol.org library and it has the properties you listed)

Ah, sorry, I forgot. I did not put it to Rebol.org, since there already 
was a simplified alternative from Carl, so INCLUDE for R2 as well 
as INCLUDE for R3 are only at http://www.fm.tul.cz/~ladislav/rebol/

I'm conflicted. I can see the logic of Brian's INCLUDE (though still 
wondering if it should be a set operation), but I use Ladislav's 
INCLUDE heavily. For me, the important thing is that we all, Carl 
included, keep communicating and work to leverage community efforts.

Yes, I have an old include system too, using the INCLUDE function 
name. It's hard to stop using it, unfortunately. I am quite ok to 
have a native INCLUDE added and to mean the opposite of EXCLUDE, 
however.

Gregg, I don't use the set operations very often (but I still want 
them there), but I do conditional APPENDs quite often, and I miss 
a native function for it definitely.

EXPLODE? Sounds as a good suggestion to me, if that name should be 
accepted ;-)

Sorry, I meant a modifying INCLUDE, as being the opposite of a modifying 
EXCLUDE. We had a long discussion about this.

UNION is non-modifying. EXCLUDE is currently non-modifying, but misnamed 
because of that (shouldn't be a verb).

Ladislav, I have no problem in principle with adapting some of the 
code in your include stuff to make a PREBOL superset with inherent 
support for R3's modules. However, if your preprocessor doesn't support 
collecting modules with R3's module syntax, then it's of no direct 
use to me for R3 code. And the great thing about a PREBOL superset 
is that #include is *not* a function, it's a directive.

Hmm, EXCLUDING's not a bad way to avoid clashing meanings for EXCLUDE.

A problem with INCLUDE is that it sounds like INSERT, but the functionality 
is APPEND (which is INSERT TAIL, ok). So what if we also want conditional 
INSERT ? I think we don't want it as often as APPEND, but it could 
be more flexible, allowing different positions to insert.

Is it really so bad to do conditional code with conditional code? 
We have IF, EITHER and UNTIL for a reason. They are not awkward.

It's a pity if the reason we don't add convenient functions like 
this is just because we haven't found good names for them.

we have already weird naming conventions, e.g. in case of 'ajoin. 
So what about cinsert, cappend? ('"c" like conditional, or "a", to 
be compatible with 'ajoin)

Btw, "it's on my list" is more of a desperate cry for help nowadays. 
It's more of a "it's on my list to get done, because it's needed". 
Actually doing it myself is the last resort; getting someone else 
to do it is the preferred method. I'm more than happy to provide 
advice, but it's hard for me to budget time to program this myself.

I was thinking of "cinsert" and "cappend" too. But note, "adjoin" 
is a normal existing english word, from Anglo-French "ajoindre".

That last resort seems to happen a lot though.

That's not a long list of people at this point, but at least it's 
not just one person :)

The non-modifying version of EXCLUDE should be called EXCLUDING
 - for me this is as good as "EXPLODE", just a mess

Last 3 or 4 months. I've been averaging about 1 day a week in front 
of a computer. I spend more time in my car.

Then you need a laptom in your car .... :-)

I spend all my time solving problems now. My mind is what needs budgeting, 
more than time or money. A laptop in the car wouldn't help with that.

Ladislav, I don't really need to get into the naming mess. I have 
needed the functionality I described for the modifying INCLUDE and 
EXCLUDE for a long time now, especially as modifying set functions 
rather than just single values like ALTER. But I can continue to 
get by without. And it turns out that the set functions often need 
to allocate another series anyways, for hashing, so the modifying 
versions probably don't have enough of a benefit to be worth adding.

However, that doesn't mean that I would call your preprocessor INCLUDE 
in the standard distribution. We need a superset of PREBOL to *be* 
the new PREBOL. The functionality we are missing is the bare minimum 
that we need to make it useful for R3 development, so if we make 
a standard preprocessor it would have to have that feature. And if 
your %include.r is a better codebase to start with, cool.

Mixins in R3 often serve the purpose that #include did in PREBOL, 
but currently need to be loaded from files at runtime. We need a 
preprocessor in order to get the mixin functionality from embedded 
modules. This is what is needed to do the R3 equivalent of encapping 
(host builds).

Samsung announced a bada Developer Challenge developer.bada.com/challenge.
How far away is a host-kit for ARM devices?

as far away as it was a few months ago

I hope someone will soon post something on a more positive note :-)

Carl is working on bug-fixing, did two releases last week, and is 
working on extracting view from the core, which he has stated a while 
ago.


What do you want Carl to do more?     AFAIK, there is nothing "unknown" 
right now.   we are simply waiting for Carl to finish this cumbersome 
task before any  of the above *can* be done.


so far, Carl has been telling us everything he's doing every step 
of the way.   some things just take time.  its not as if Carl is 
waiting doing nothing.  

He's been working his ass off  tackling huge items on the list.  
Some of the very things you (and many of us) have been "complaining" 
about for years.

the atmosphere is a bit tense lately

the biggest problem is not the development, or the lack of thereof, 
but the lack of communication. I think that one short message per 
week or two on Twitter would not hurt :-) Just last two working days, 
 I experienced the same - I am leading our corporate site roll-out 
to 8 branches abroad. Marketing managers involved. While I worked 
like mad for last week, I started to receive emails, asking for the 
status update - and that's it - ppl just want to plan a bit their 
things. When I explained other branches, what I am busy with, they 
stopped asking, and I will update them once per week, till I finish 
the job ... and that's it ... correct communications ....

You do realize that Carl went to a conference after a99, right? He 
twittered about it and everything.

Is there some simple way how to extract values of one datatype (eg. 
string!) from a block! ? Something like filter [...] string! ?

and is there a function like ALTER but that adds a value to a block 
if not present and leaves block as is if value is already present?

I think this was just discussed a few days ago in this group. Search 
for ENTAIL.

I just see a lengthy discussion about that function's name... Nevermind, 
I wrote one myself already. It's faster than to use AltME's search.

INCLUDE.   why is everyone dancing around this word.  <sigh>

this is what the word means.  


union is merging two sets.  Including, means adding to a set.  since 
a set is by definition a collection of unique items, I don't see 
what's the problem.

INCLUDE has the drawback to be already used for other purposes in 
computer languages (like preprocessor).
We simply could peek a synonym, they are many.

COMPRISE, CONSIST, CONTAIN, HOLD, CONTAIN, BEAR, CARRY, INTEGRATE.
A short one if possible...

it has a sense of a contionnal action... no ?