AltME groups: search

Example:
Let's say, our date is 6 digits YYMMDD.
>> date: "230812"
We deside, it's the year 2023:
>> insert date "20"
Now dashes are inserted to form a date understandable by REBOL:
>> insert skip date 6 "-"
>> insert skip date 4 "-"
Date now looks like this:
>> date
== "2023-08-12"
And we can control, it's a valid date with:
>> to-date date
== 12-Aug-2023

If it's not a valid date, like if the original had other characters 
than digits, we'll get an error. Errors can be caught with:
>> error? try [to-date "foobar"]
== true

Hope it helps.

Oh! I was persuming - wrongly -  that no check was done.  I thought 
that because at first glance Rebol did not produce an error on the 
function   >> a: to-date "afrt-01-02"  which results in == "afrt-01-02". 
 Thanks for the explanation; then checking all the digits in a date 
is not usefull.

if you load a string with a date, it will be checked:

>> load "25-mar-2006"             
== 25-Mar-2006
>> load "25-12-2006" 
== 25-Dec-2006
>> load "3-3-6" 
== 3-Mar-2006
>> error? try [load "32-13-2006"] 
== true
>> error? try [load "01-16-2006"]
== true

Multiple refinement functions :  I need to formulate a function with 
more than one refinement.  I know in Rebol we usually use the word 
'either to formulate them, but with more than 3 refinements (and 
its following default case) it becomes tedious.   Structures like 
'record-operations: func [/delit /addit /modit] [ either  delit [print 
"delete"] [either addit [print "add"] [either modit [print "modify"][print 
"no refinement"]]]]'  are overly complicated.  I would like a more 
flat structure, to be able to distinguish the conditions which are 
independants from the ones mutually dependants, albeit mutually exclusive. 
 I tried multiple if's but that does not seem to work.  What are 
the good options to code multiple refinements functions.  The mail 
list does not seem to have an example discussing just that.  And 
in the source, most functions with multiple refinements are native.

Multiple ifs should work....
   if addit [addit code termined with a return]
  if modit [ modit code terminated with a return]


If you have multiple refinements that make up one logical unit, try 
something like this:


f: func [/a /b /c /d] [if all [a b c] [print 'abc return true] print 
'not-triggered]
f/a
not-triggered
f/b/c/a
abc
true

If you allow more than one refinement at a time, an approach is to 
build up the code in a block, depending on the refinements (using 
if), and then evaluate the block at the end of the function. Example:


f: func [/a /b /c] [blk: copy [] if a [append blk [print "ref a active"]] 
if b [append blk [print "ref b active"]] if c [append blk [print 
"ref c active"]] do blk]

>> f/c/a
ref a active
ref c active

How about this ?
f: func [/aref /bref /cref /local refs symbs][
	refs: copy [aref bref cref]
	symbs: copy []

 forall refs [if get refs/1 [append symbs to-char #"a" - 1 + index? 
 refs]] ; convert to #"a" #"b" #"c" ...
	switch rejoin symbs [
		"abc" [print "All of them"]
		"ac" [print "Just A and C"]
		"b" [print "Just B"]
	]
]

Using an issue (or could be a string) instead of a block:

f: func [/aref /bref /cref /local refs symbs][
	refs: copy [aref bref cref]
	symbs: copy #

 forall refs [if get refs/1 [append symbs to-char #"a" - 1 + index? 
 refs]] ; convert to #"a" #"b" #"c" ...
	switch symbs [
		#abc [print "All of them"]
		#ac [print "Just A and C"]
		#b [print "Just B"]
	]
]

normand,  a lot of us forget about the two following words:  ANY 
  ALL

here is an example for handling multiple non-exlusive switches:


lets say you have refinements /a /b /c /d.      /d is mutually-exlusive 
to all others and a + b reacts differently than when alone... trying 
to wrap that in if/either can be a nightmare, and its impossible 
using case or switch... BUT using any/all actually makes it quite 
visual and simple to see flow:

option:	ANY [
	ALL [d (print "Exclusive d submitted") 1]
	ALL [a b (print "A and B supplied together") 2]
	ALL [a (print "A alone") 3]
	ALL [b (print "B alone") 4]
	0
]

if d [print "D also specified" option: option + 10]

here, the first occurence of any possible refinement combination 
returns a number, the trailing 0 is there so that ANY does not return 
none (which could also be what you want)

the /d is checked a part since its not exclusive.

Glad to see that in Rebol there are many ways to Rome.

Alphabetical sort - Is there a built-in way to obtain the right sort 
order for the french language.

a b c d e é è ë f g ... I dont see it as a 'sort refinement, and 
'am a bit surprised.  Else why fuss with 8 bit chars?  So I suppose 
it is there, but don't see it.

In plain sort, the accented caracters are coming last! a: [é è ê 
ë a c b d e g f h i k j l m n p o q r t s u v x w y z]   sort a
== [a b c d e f g h i j k l m n o p q r s t u v w x y z è é ê ë]

I'll ask Cindy: only thing I wish to know is if DLL access is not 
free in R3 if there will be a (cheap) upgrade path for R2 licensees.

BenK, I waited a real long time to purchase Pro/sdk but glad I did 
as I had a project come up that required binding my app into a simple 
to use .exe.

good question on the licensing. I'm also about to buy the SDK and 
it would be nice to know how much it's going to be worth until a 
3.0 SDK comes out.

For thos einterested: just received e-mail from Cindy stating that 
there will be a (cheaper) upgrade path to R3 for R2 licensees, butno 
details available just yet.

I'm new to REBOL (discovered it by accident searching for internet 
operating systems) and was pleasantly surprised to discover this 
powerful language/environment with an active/passionate community. 
I'm not a programming guru, but would like to understand the language/environment 
and the types of applications it is good for (and not good for). 
So would anybody be able to point me to the "idiot's guide to REBOL"? 
Does REBOL provide architecture documentation/guidelines and/or frameworks 
for the development of scalable, fault tolerant, manageable, with 
hot code swapping for soft real-time 24x7 applications? Thank you 
in advance for your recommendations.

I agree. Toi master a language, i have to master the core-features. 
And if there are a lot of them, that slows down. And i can do the 
same things with current features in a slightly diferent way, i am 
lazy, so keep core small :)

I think that REBOL right now is in a hard place.  It wants to stay 
pure... yet it wants adoption.

but I don't think the language should change in a way that it depends 
on them.

just like trying to understand a german sentence  ;-)

A thing that hurts is this copy-thing. You have to know it, that 
effct occurs everywhere. Thats what i call a core-"feature".

but its a feature. its not a bug.

Or multithreading would be a core-feature, or language-feature. If 
it is present, you have to expect random changes everywhere.

A rebolized or erlangized multithreading is something else.

Maxim: "what I have seen a lot through the years about people suggesting 
things (me included) on how to improve REBOL, is the tendency to 
ask for things from other languages."

I would add "how to do them in rebol". In case of namespaces, maybe 
a more dialected approach could be usefull.

making a dialect is not trivial, however you want to approach it. 
 you must "understand" REBOL to a certain extent.

A parse-rule is not that different from a set of functions. And the 
way to write them could even be changed closer to functions.

Volker - then any new concept addition will ruin rebol for you, as 
you will have to learn it ... View is gonna be overhauled too - changes 
to face and who knows what .... from recent blogs, I can only see 
positives in getting them. I have a trust in Carl and that he is 
going to do those things in sensitive way ...

Glass was an example of a programmable dialect.

I am not against modules. I am against thinking "put things in namespaces 
and you can hide and forget them and they still work smothly together". 
That works when i am ready to hide a lot more than i would write 
otherwise. (that "only 25mb!!"-thing)

I guess the question is does library code isolation *need*  a language 
extension like modules or namespaces?

Or are existing contexts good enough provided we take care to avoid 
creating global words?

I opt for auto-protection for global words. So i think modules are 
a good think.

Thats the other thing. IMHO modules go not far enough. For frameworks 
i want complete sandboxing of user-code, including quotas. Modules 
go not far enough. For libraries i am worried modules make large 
amounts of code to easy to write (only a little bit worried, or maybe 
just paranoia?).

The issues you are touching on  are all easily circumvented.

If I have your *source* I can easily preprocess it before DOing or 
LOADing it to make whatever behaviour changes I like.

That makes it impossible in a source-level library to get total protection.
Binary modules, that's another issue.
Paranoia is good!

Currently i thnik about including a web-server and use cgis which 
call cgis. then i have no need open things up later, just close them 
enough, do job, exit.

Sunanda, its about the protection of the loader, not the loaded IMHO. 
The loader should be able to protect the exe before doing untrusted 
code, and unprotect it later ("shoudl" as in "thats a wish.")

Yep, that bugs are a problem, not only intent. If i have a daemon 
24/7, add a feature which bugs 2 hours later, when i am away, and 
i am bag tomorrow, with the daemon down, thats uncool.

Volker. That's true (and I've said it myself too: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMGVC
)
But we need to protect "my" library against your loader too.
That's a separate problem.

can you imagine that not being able to know the current login name 
is case enough for REBOL not being used in multiuser office environments. 
 that is something which MUST be addressed in R3 its a simple call 
to the socket lib (IIRC) and if protected, then that info can force 
apps into being multi-user oriented.

WIndows does not store the name in a user-var?

Script to implement a sandbox:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlDGDS
No idea if it works ot how easy it is to cirumvent.
But maybe it could be used to prototype modules.

Maxim: No, but if i cant trust the user, can i trust the machine? 
But i guess for most uses yes. Could be a nice feature in R3, possible 
in combination with rebservices. Currently, could such things be 
done with 'call?

just run a batch script with set VARNAME VALUE  before your command...

A thing i use personally is
  join read dns:// what-dir

Not for security, but to keep my configurations apart. But maybe 
it helps here?

create a file and check ownership? does get-modes tell?

yeah...  plus not having a user name solves that issue on Amiga ;-)

i guess real user-name could be a cross-platform-problem. Specially 
on amiga ;)

Playing marketing, would it helpto add browser-access too? Then that 
cookies could be a good idea. If you do not tell that all that web-interfacing 
is a quic workaround around not having user-names.. :)

It has just occured to me that if REBOL needs a niche and actually 
wants to have REBOL work in the Large... that they need to do only 
one thing.   Embrace XML.   its got everything going for it, there 
is nothing to invent (just read specs and implement, like protocol 
RFCs).

just like we just SEND a mail, READ a web site, or WRITE an ftp server. 
 if we could also LOAD/SAVE any XML technologies (XML files, DTDs, 
Schemas, etc), then R3 would immediately get appeal in the corporate 
world.  It would actually have value to them .

I agree. That's a good thought.

And R3 would have the excuse of being able to be IT friendly.. which 
it currently isn't.   AND it would benefit of having access to a 
slew of tools which actually help some people get work done integrating 
Heterogenous systems, which is something REBOL is currently incapable 
of stating.

If you get any salesman in an IT dept which has XML capabilities 
(and they are getting used, really) and in 15 minutes, LOADS their 
data structures, instances, edits them and spits them right back 
out using a simple command line interface... welll...  case closed.

you at least get a chance at having REBOL being used for some little 
tidbits, and as we all know, it will become addictive and soon will 
get used more and more.

Yup, I've heard that before. It's a valid concern.

I can vouche for henriks point.  That is the single most used Anti-technology 
adoption argument.  What if  "developperX  gets hit by a train?" 
 :-(

so, that is a factor that rebol developers should not play on

I was told "by a bus."

The tools exist,  senior XML developers also, heck some people even 
wrote the damned specs...  nothing is keeping RT from contracting 
out someone (or licensing technology) to add those capabilites in 
rebol natively, or as a module if its too large to keep REBOL lightweight, 
(no pro-con libs wars please).

That's right, so a function could be interrupted mid-evaluation and 
restarted later.

so, a function that maintains state ?

don't closures also help with the copy problem?  where each time 
you run the closure, a series is indeed new?

Is there a succinct way of demonstrating a situation where a closure 
would be used (with hypothetical Rebol code)?

having a local

yes, its a context within a function.

I guess shortcut-things and a little speed. and i made a mistake, 
my example must be
 f: closure[/local ta sl]

Maxim: no, it does not solve the copy problem; however, closures 
need to copy deep the function body at each call; so, it somewhat 
solves the copy problem as a side effect (only for blocks and parens 
though, probably, as there's no need to copy anything else). (however, 
i would not rely on it, since for example it would be a useful optimization 
not to copy empty blocks or blocks that contain no words etc)

well I didn't say "solve"  ;-)  but by what I understand of closures 
(and I have been reading a lot lately) if 'closure does a deep copy 
without empty series optimisation, then we could rely on it.


actually, NOT copying empty series would make closures bugged, since 
all generated closures would referrence the same empty block from 
the context of the closure's definition.  which is in direct contradiction 
to the concept no?

Personally, I've never really considered the "copy problem" a problem. 
When you don't copy something it doesn't get copied. When you do 
it does. Series aren't immediate values, they are reference values. 
Same for objects. Every language design choice could be considered 
a bug or a feature - it all depends on how you use it. I've found 
more advantages to the way that REBOL functions work now.


The only real problem I've run into is functions keeping references 
to their temporary data after they return, at least until they are 
run again (a memory hole). The closure example above with the adders 
stops being a problem when you realise that FUNC is a function that 
does something when passed a  couple blocks - it's not syntax. You 
didn't copy the block, so it gets reused, go figure. You are building 
functions - is it such a stretch to build code blocks?

make-adder: func [n] [func [x] compose [x + (n)]]

and for the record, I hate the fact that I have to return first reduce 
[value value: none] all the time.  its slow, ugly and its a BIG memory 
hole in view and something within the stylesheet system.

That  return first reduce [value value: none]  is a nice trick - 
I hadn't thought of that. I did suggest on RAMBO that the unset native 
return the old value of the word it is unsetting, allowing a trick 
like  return unset value  but they haven't made that change yet.

I guess, that Brian didn't consider writing a more complicated asynchronous 
framework, where the advantages of closures cannot be overlooked

Ladislav, it's not that I don't see the advantage to closures in 
principle, and that I wouldn't use them occasionally if they were 
there. It's that Carl's description of how the closures would be 
implemented seems a little heavyweight, largely as a result of REBOL's 
direct binding. I would use closures, but only when creating my own 
contexts manually or copying a subset of the data would not have 
the efficiency gains they would normally have.

;The changed build function would be:
build: func [
    {Build a block using given values}
    block [block! paren! path! lit-path! set-path!]
    /with
    values [block!]
    /local context inner
] [
    values: any [values [only: :encl ins: :dtto]]
    context: make object! values
    inner: func [block /local item item' pos result] [
        result: make :block length? :block
        parse block [
            any [
                pos: set item word! (

                    either all [item': in context item item <> 'self] [
                        change pos item'
                        set/any [item pos] do/next pos
                        insert tail :result get/any 'item
                    ] [insert tail :result item pos: next pos]
                ) :pos | set item get-word! (

                    either all [item': in context item item <> 'self] [
                        insert/only tail :result get/any item'
                    ] [insert tail :result item]
                ) | set item [

                    block! | paren! | path! | set-path! | lit-path!
                ] (
                    insert/only tail :result inner :item

                ) | set item skip (insert/only tail :result get/any 'item)
            ]
        ]
        :result
    ]
    inner :block
]

You need to change all of the
    insert tail result
to
    insert tail :result

to keep the result from being converted from a lit-path! to a different 
path! every time.

>> result: first ['a/b]
== 'a/b
>> insert tail result 's
==
>> :result
== 'a/b/s

That means that the path! returned by DOing a lit-path! returns the 
same data rather than a copy. Interesting.

Still, changing them would make your build dialect compatible with 
older versions of REBOL that evaluated path and paren values when 
you referenced them with a word rather than a get-word. It all depends 
on how far you value backwards compatibility.

(I am using PSPad, but wanted to give a try to SciTE)

Sure. I prefer Notepad++ but it doesn't have REBOL enabled as a language. 
What's with the IN patch?

Here's a good installer for SciTE on Windows:
http://gisdeveloper.tripod.com/scite.html

Henrik, good suggestion with the loop working on more than one series 
(in your reply to Carl's blog). That must be possible with a function 
definition. But it should probably be part of REBOL, at least a mezzanine.

I realized that it's not possible with FOREACH since it would need 
to know the difference between two and three blocks as input (don't 
know if a refinement would take care of that)

but I use this a lot and it would make it easier to interlace many 
blocks this way

A new mezz, formany perhaps?

Henrik, try to implement your ideas in REBOL code. Post it to AltME 
if you need help. Let us hash out the details, improve it. If it 
turns out well, it could become a mezzanine function.

I think Carl was talking about his Include. I meant Ladislav mentioning 
the build dialect yesterday in this group and me suggesting bug fixes 
immediately. It's a little better than it was before as a result. 
Sometimes it seems that the best REBOL optimizer is its community 
showing off.

my nforeach took a different approach, that is   nforeach [c1 a c2 
b] [...]

r3's one will probably be   foreach [[c1] [c2]] [a b]  [...]

but, note that it is very likely that foreach will be a mezz, so 
we you can improve on it :)

such a construct would make certain loops much simpler

Sure, as long as it's fast, make it a mezz and let it evolve.

I posted a comment to hash that contains the reason why Carl is reconsidering 
the HASH! datatype

re the BUILD issue - it has been used quite regularly, although not 
for lit-paths, because they are "rare" in a sense

Sometimes I return a hash index as a query result set, for database-like 
functions. If I had to use an assoc instead I'm sure it would be 
fine as long as select was still O(1) like a hash.

Most of the time I use it like an assoc, or like a fully indexed 
table.

The main advantage a hash has over an assoc is that you aren't limited 
to simple key-value records, you can use longer records.