[REBOL] Re: remove/part on open file port
Tom Foster napsal(a): hi! if I do a: open %file remove/part (find a this)(find a that) close a it acts like I expect. If I try to loop it through a directory, though, foreach file read %dir/ [ a: open file remove/part (find a this)(find a that) close a ] I get this error remove expected range argument of type: number series port what am I doing wrong? thanks, -- signature to baby: doobywoobybooboo -tom It looks like Find didn't find any occurrence of that. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Boruvka's Minimum Spanning Tree algorithm
Brett Handley napsal(a): Hi Ladislav, I like your choice of edge representation - flexible. ...snip... yes, that was my primary goal, but for this algorithm (and maybe for some other), the adjacency structure used instead of a block of graph edges might lead to a simpler formulation. (But there would be a problem, where to store edge weights - any idea?) -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Using repeat in write/append/lines
Hi Stuart: repeat i 10 [write/append/lines %output.txt *] should do it But instead of ** in the appended line I would get a single * Can anyone help? Stuart try: repeat i 10 [write/append %output.txt *] -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [context] How to compose in a local context
Hi Ashley, ... How can I prevent 'compose from binding to the global context? you can't, because Compose doesn't do any binding. Here is one way, where Has is allowed to do the binding, but I don't know whether this is the one you need: b: 'a do has [a] compose/deep [do [set [(b)] 0]] -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Notes on seeding 'random/seed (long)
Hi all, I would like to remind you, that there are more reliable methods of producing random numbers than using a pseudo-random generator function. You can e.g. use Andrew's function to access www.random.org I plan to post my version (usable as the Random function replacement) to www.compkarori.com/vanilla/display -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Undocumented: Index value local to FOR loop
Gregg Irwin napsal(a): ...REBOL uses 'definitional scoping', which may seem a bit confusing at first when used with literal arguments. fn: func ['word] [print word word: 10 print word] fn hello hello 10 hello ** Script Error: hello has no value ** Near: hello HTH! The above code doesn't explain what is going on. esterno: does [ print [indice] ] use [indice] [ indice: 25 esterno ] here you can see, that esterno doesn't use initialized local word, because it uses the uninitialized global. -L -- Gregg -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Apply and Named
I experimented a bit with Apply and Named functions. The latest versions can be found at http://www.fm.vslib.cz/~ladislav/rebol/apply.r The functions are optimized to work under Core 2.6. Examples: ; Named argument passing without refinements named :subtract [value2: 1 value1: 2] ; Named argument passing with refinements test-fn: func [a b /ref-c c /ref-d d] [ print [A: a] print [B: b] if ref-c [ print [C: c] ] if ref-d [ print [D: d] ] ] named :test-fn [ref-d: ref-c: true d: 1 c: 2 b: 3 a: 4] ; Example: apply :subtract [2 1] ; Example: apply :type? [()] ;Joel's examples: bunchanums: [3 1 35 8 4 5 52 42 19 13 32 43 81 2 6 34 46] tally: make object! [ tot: 0 zero: does [tot: 0] up: func [/by n [number!]] [tot: tot + either by [n] [1]] down: func [/by n [number!]] [tot: tot - either by [n] [1]] now?: does [tot] ] ; Joel's example #1: use [evens odds] [ evens: make tally [] odds: make tally [] foreach num bunchanums [ apply [(either even? num [evens] [odds]) up by] [num] ] print [evens: apply [evens now?] [] odds: apply [odds now?] []] ] ;Result: ;evens: 226 odds: 200 ; Joel's example #2: use [diffs] [ diffs: make tally [] foreach num bunchanums [ apply [diffs (either even? num ['up] ['down]) by] [num] ] print [net sum: apply [diffs now?] []] ] ;Result: ;net sum: 26 ;Example #3: apply [(now) time second] [] ;Example #4: probe head apply [insert if find ask Only?(y/n) y only] [copy [] [1]] ;Example #5: a: [1 2 3] apply [a (1 + 1)] [] Any suggestions welcome -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Right mouse button popup-menu for all my REBOl apps.
Al TS napsal(a): I now the Rebol Style is not to have libs concept but put all the source in the same file That is a subjective POV. I *am* using libraries. I am using http://www.fm.vslib.cz/~ladislav/rebol/include.r to handle my optimizing routines, matrix processing routines etc. BUT if you want to try Rebol PROGRAMMING IN THE LARGE not in the small how do you do ? Many thanks again to all of you for all the informations you give on this ML !! -yos -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: localized func alternative...
Maxim Olivier-Adlhoch napsal(a): Hi all, Has anyone programed an alternative to func (function, has, does) which declares every set-word as local by default? I find rebol's liberal use of global namespace to be the most limiting factor in scaling rebol to large tools. I'd rather have to define global words than local words (especially in api tools). There is MUCH less chance that incidious errors will be generated or exposed. A notable example is the recent S: variable useage in the sql tool which would not have occured. TIA! -MAx you can use http://www.fm.vslib.cz/~ladislav/rebol/lfunc.r (uses local variables), or, if you want to have a function having *static* local variables in addition, use http://www.fm.vslib.cz/~ladislav/rebol/sfunc.r -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] The complete Rebol named argument passing
I wrote a function, that can create a block handling complete Rebol named argument passing. (i.e. values, refinements, normal arguments, fetched arguments and unevaluated arguments) The function supposes, that there is a context containing all locals of the function which refer to the values and refinements that shall be passed. I will be grateful for any tests, optimizations and improvements. Sample test: f: func ['x [any-type!]] [type? get/any 'x] b: pass-args 'x [] :f x: 1 do b ; == integer! unset 'x do b ; == unset! the function: comment [ ; the Pass-args function result ; looks as follows: [ path: to path! 'fn call: make block! 4 + length? prefix insert call prefix insert/only tail call path ; unevaluated argument passing goes here ; ... ; args are corresponding argument values insert tail call args ; here goes refinement handling ; ref is a refinement if ref [ insert tail path 'ref insert tail call args ] ; ... do call ] ] pass-args: function [ {Compose a block passing arguments and refinements to the given function} context [word!] prefix [block!] f [any-function!] ] [item item2 args result result2] [ ; the result shall have its own 'fn, 'path and 'call variables use [fn path call] [ ; 'fn variable shall refer to the function fn: :f ; the ARGS block collects arguments for CALL args: make block! 0 result: copy [ path: to path! 'fn call: make block! 4 + length? prefix insert call prefix insert/only tail call path ; here is the place to handle unevaluated arguments ] result2: compose [ insert tail call (reduce [args]) ; here goes refinement handling ] parse first :f [ any [ set item word! ( ; normal argument passing item: bind to lit-word! item context insert tail args compose [get/any (:item)] ) | set item refinement! ( ; refinement handling item: bind to word! item context insert tail call (reduce [args]) ; create fresh argument block args: make block! 0 insert tail result2 compose/deep [ if (item) [ insert tail path (to lit-word! item) insert tail call (reduce [args]) ] ] ) | set item lit-word! ( ; unevaluated argument passing item: bind :item context item2: bind to get-word! :item context insert p: tail args none insert tail result compose/deep [ change (reduce [p]) either value? (:item) [ ; this handles any value except unset! type (item2) ] [ ; this handles unset! type value ] ] ) | set item get-word! ( ; fetched argument passing item: bind to word! item context insert tail args item ) | skip ] ] compose [(result) (result2) do call] ] ] p.s. (for Romano and Gabriele) this can be used as the basic part of SUBFUNC. It substitutes PREPARE-AR and makes FUNCALL unnecessary. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: The complete Rebol named argument passing
hi, there is a bug in the code I posted. I decided to put the repaired code to the REP site: http://www.compkarori.com/vanilla/display/pass-args.r for everyone to be able to access it. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Can I define an anti function?
Tom Conlin napsal(a): how bout ... antif: func [fn-args[block!]][not do fn-args] then anitif [fn args1 argn] That doesn't correspond to the specification -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Can I define an anti function?
Hi Romano, Ok, Lad this is my solution, (without refinements handling and without get and lit arguments and without optimizations) I have got a few notes: 1) I am still not convinced, that a get argument, (alias fetched argument) is a good argument passing method. The disadvantage of it is, that you cannot easily supply a result of an expression as an argument. Example: anti func [x [logic!]] [x] ; this is hard to write correctly using the above method No native or mezzanine Core function uses this argument-passing method (although there are natives in Rebol/Core that can take functions as arguments). Allow me to poll other users: how many of you use this argument passing method? anti: func [:f ] [...] 2) Otherwise your solution is very close. The only bug is probably this: f: func [get] [true] anti-f: anti f anti-f false ** Script Error: Cannot use path on logic! value ** Where: anti-f ** Near: native func [get][true] get/any 'get -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Can I define an anti function?
Anton Rolls napsal(a): What is the purpose and utility of such a function ? Anton. {Suppose f is a function returning a boolean.Is there a way of defining a function anti, which, when given f, returns not f? This is a higher-order function. This style of programming is known as Functional Programming and some use it in Rebol - cf. Map as an example. Otherwise this specific case is probably just a homework and I brought it here just to show you how some people judge Rebol or other programming languages. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Can I define an anti function?
Anton Rolls napsal(a): The function it produces is interesting. f: func [a b][a = b] g: anti f probe :g func [a b][native func [a b][a = b] get/any 'a get/any 'b] This 'native function is undocumented and it's not obvious to me what it does. Anton. that is just the NOT function used as a Rebol value. See this: reduce [:not] ; == [native] -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Can I define an anti function?
Hi Romano, ...but i agree, the :arg notation is never used and it requires a reference to a value instead of the value itself, so it is not totally correct to be used it in context like this. About Scheme people, if they would speak in general, they could be right: we cannot create an anti :do and anti :make which work in every situations, but if they speak only of strict bolean functions, i think they are wrong ;-) That's the point I was prepared to make :-) If we translate a function returning boolean to Rebol as a function always returning Logic! (for any input), then we are safe as you said, because DO (as well as MAKE) sometimes return different datatypes. ... yes, i forgot to delay the get/any insertion after the bind to the function context. there are many modes to do it, and this is one of them: ... yes. To present a solution, that looks as simple as possible, we can write: anti: func [f [any-function!] /local exec] [ exec: func [block] reduce ['not 'apply 'first reduce [:f] 'block] func load mold third :f reduce [:exec first :f] ] , where the only missing part is an APPLY function, which takes a block of words and passes their values to the function. An easy ;-) exercise for the reader. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Can I define an anti function?
Maxim Olivier-Adlhoch napsal(a): you could use my encompass function to create an anti function. ..., but it wouldn't work for some cases. Have a look at http://www.compkarori.com/vanilla/display/subfunc.r , which does (essentially) the same thing ;-) and is optimized for speed by Romano (I recently found that some improvements can still be made - 67% speed-up and a correction for unevaluated argument passing) -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Can I define an anti function?
Doc draw my attention to the %subject%, which was discussed at comp.lang.scheme. The thread started with: {Suppose f is a function returning a boolean.Is there a way of defining a function anti, which, when given f, returns not f?} the discussion continued: { (define (anti f) (lambda args (not (apply f args Why is this objectionable? It provides the ability to do something that hardly any other languages can do. } { This last statement is a bit too strong, even in Python you can do Sheesh, I clearly said hardly any other languages, not no other languages. I stand by my original statement -- most programming languages can't do this. Python and Scheme are some of the few that can. C can do it for functions of a specific arity, but can't generalize (e.g. you can write anti_f1 for 1-argument functions, anti_f2 for 2-argument functions, etc.) } { I expect most general-purpose dynamically typed languages can, at least those using a conventional syntax. Perl can, Ruby can (but its treatment of higher orded functions is weird), Dylan can, and probably all Lisp variants too. Smalltalk can't because variable arity doesn't make sense: the method name implies the arity syntactically. Rebol probably can't: here the arity of a function tells how many words to parse as its argument and where the next function call begins. Forth and Postscript can't. Among statically typed languages C# can, and it's the only one I know. } Question: Is the guess about Rebol correct? (I will post my answer later) -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Can I define an anti function?
Romano Paolo Tenca napsal(a): My first attempt, but i do not know if it is a right answer: antif: func [:f [any-function!] args[block!]][do head insert copy args :f] --- Ciao Romano It isn't, because it takes 2 arguments, while ANTI has to take just one: F -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Rebol Poetry
help :add :-) -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Endianness
Gabriele helped me to correct my error W.R.T. processor endianness (although he claims he doesn't remember what little and big endian means :-) in http://www.compkarori.com/vanilla/display/peek_and_poke.r sorry for any inconveniences. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Timing Functions and Merge Sort (was: forever loops and cpu usage)
Paul Tretter napsal(a): That's very interesting. With your functions are you able to determine the optimum performance wait time? Yes. I am using my timing functions to determine optimum performance in many situations. And if so, is it platform independent? The system clock tick is platform dependent. OTOH, the 0.001 limit for the WAIT function looks like platform independent. Below the limit the WAIT function doesn't wait at all, it returns immediately as my measurements seem to prove. This information is really necessary to get published if people are making platform independent scripts. You can find the functions here: http://www.compkarori.com/vanilla/display/include.r - My dependancy-resolving function http://www.compkarori.com/vanilla/display/seconds.r - Function computing time between two dates in seconds http://www.compkarori.com/vanilla/display/timblk.r - Timing functions Moreover, I uploaded my Merge Sort implementation (I am using it since Rebol 1.x days and this is not the first time I am publishing it): http://www.compkarori.com/vanilla/display/msort.r -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: forever loops and cpu usage
Paul Tretter napsal(a): On WinXP here I can get as precise as .001 on the wait time. However, it appears that anything less than that storms the cpu back up to 99 percent. I suppose that .001 is the lowest number that the wait function can support. I'm curious why you arrived at .002. Was it the balance point for windows and linux. I would like others to report on what OS they use and report their findings. HOW LOW CAN YOU GO? I have got a timing function working as follows: tick-time: time-tick 0.1 ; == 1.002183E-2 , which computes the internal system timer resolution, 0.1 is an argument asking for 10% relative error at most. Other results: time-block [wait 0.02] 0,05 == 2.0031251019E-2 time-block [wait 0.01] 0,05 == 1.0015625509E-2 time-block [wait 0.005] 0,05 == 1.0015625509E-2 time-block [wait 0.002] 0,05 == 1.00156249998236E-2 time-block [wait 0.001] 0,05 == 1.00117187499791E-2 look like showing, that all below the system timer resolution are rounded up to the system timer. OTOH, times below 0.001 exhibit this: time-block [wait 0.00099] 0,05 == 4.85229492186434E-6 -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] the endianness of the processor
big-endian?: 1 = first convert 1 see http://www.compkarori.com/vanilla/display/peek_and_poke.r -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: the endianness of the processor
Gabriele Santilli napsal(a): Hi Ladislav, On Thursday, February 5, 2004, 8:59:31 AM, you wrote: LM big-endian?: 1 = first convert 1 LM see http://www.compkarori.com/vanilla/display/peek_and_poke.r get-modes system/ports/system 'system-modes == [window winmsg tray endian] get-modes system/ports/system 'endian == little Regards, Gabriele. aha, didn't notice that thanks -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] How to obtain a 64-bit IEEE754 representation of a decimal number
convert: func [ x /local y ] [ y: make struct! compose/deep [x [(type?/word x)]] reduce [x] third y ] Usage: convert 0.2 ; == #{9A99C93F} this is a big endian form of the number (in Windows). If you prefer a little endian form, which is more (human) readable, use: head reverse convert 0.2 ; == #{3FCA} -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: How to obtain a 64-bit IEEE754 representation of a decimal number
Hi Ashley, convert: func [ x /local y ] [ y: make struct! compose/deep [x [(type?/word x)]] reduce [x] third y ] OK, this one has me stumpted. For us mere mortals, could you explain: help y Y is a struct of value: make struct! [x [decimal!]] [0.2] first y == [x [decimal!]] second y == [0.2] third y == #{9A99C93F} how and why this works, in particular where third y comes from? Also, how does one reverse the conversion (i.e. get 0.2 from #{9A99C93F} )? This is a library interface, which is documented in: http://www.rebol.com/docs/library.html , where I found the informations needed to write the above function as well as: http://www.compkarori.com/vanilla/display/peek_and_poke.r reverse-conversion: func [ x [binary!] type [word!] ] [ y: make struct! compose/deep [x [(type)]] none change third y x y/x ] Usage: reverse-conversion #{9A99C93F} 'decimal! ; == 0.2 I assume this is another useful spinoff from the rounding project? ;) Not exactly, it is mostly independent. Regards, Ashley -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: the utility of 'bind
Andreas Bolka napsal(a): I will spare you my thoughts about REBOL's contexts and 'bind (for now) but I have a practical question: What is the utility of 'bind? No, I don't necessarily mean the typical cases where bind is needed to prevent errors. What I'm really thinking about are situations, where REBOL's behaviour regarding contexts and bind is actually contributing towards an elegant solution for a real problem. I think I remember various parse-based solutions posted to the list, that utilized bind. This is basically a question to those who understand _and_ use 'bind to actually solve problems: What do you use it for? Do you think REBOL's behaviour in those regards is practical? Are you aware of elegant solutions based on 'bind? Hi Andreas, BIND can be used to program e.g. a WITH function like with object [do something] I don't remember all cases where I used BIND. One case I recently actualized was when I tried to circumvent the limitations of RETURN and function attributes. To describe the usage of BIND there: I defined (locally) the functions called RETURN', THROW' and EXIT' having different behaviour, than their native counterparts. Then I supposed, that a user would supply a code block using the above words. I used BIND to give the meaning to the words supplied from outside. When I think about it now, I could do it without BIND using the USE function only, but it would be less readable at least. -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Identity
Hi all, I decided to actualize the wording of: http://www.fm.vslib.cz/~ladislav/rebol/identity.html it now reflects the properties of Rebol/Core 2.5.6 Due to an adjustment IDENTICAL? is now stronger than ever and I hope, that it really is the strongest equivalence in Rebol :-o Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: a new switch-like flow-control function
Hi Alain, Here is a function for only 1 condition but 3 cases : if it can be useful to anyone trif: func [ ... ; example: print trif request give an answer [yes][no][cancel] by the way, is it good that not none equals true ? Alain Goyé. yes, it is useful. The following improvement uses the [throw] attribute to make the behaviour of the function more standard with respect to Return: trif: func [ {Three case if} [throw] condition iftrue [block!] iffalse [block!] ifnone [block!] ] [ do either condition [ iftrue ] [ either none? condition [ ifnone ] [ iffalse ] ] ] ; example: f: does [trif request give an answer [return yes] [return no] [return cancel] Shoudn't get here] Merry Christmas -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: a new switch-like flow-control function
Hi Pat, What is the meaning of thro? I have seen it here and there but never quite understood its purpose. Regards Patrick - Original Message - From: Ladislav Mecir yes, it is useful. The following improvement uses the [throw] attribute to make the behaviour of the function more standard with respect to Return: trif: func [ {Three case if} [throw] condition iftrue [block!] iffalse [block!] ifnone [block!] ] [ do either condition [ iftrue ] [ either none? condition [ ifnone ] [ iffalse ] ] ] ; example: f: does [trif request give an answer [return yes] [return no] [return cancel] Shoudn't get here] Try to use the version of the above function without the [throw] attribute and you will find out, that the result of F will be: == Shoudn't get here , which indicates, that the Return got consumed by Trif , while what we intended was to throw Return to F. The throw attribute does exactly that - throws Return to caller functions. Merry Christmas -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Rebol API to DyBASE
Hi Joel, I think, that: 1) Konstantin tries to use an Associative Array. I doubt, that the suggested implementation is the best one. INSERTs into a fresh hash (created each time with MAKE HASH! []): Appears to be increasing faster than quadratically! # eltsseconds ratio quad slowdown 1 3.065 2 25.8178.423 4 2.106 3 63.682 20.777 9 2.309 4123.417 40.267 16 2.517 2) this seems to be different from my measurements (slower). Can you post the code? -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: What does REBOL fix?
A J Martin napsal(a): REBOL - When one language just isn't enough. I like it. :-) -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: read directory
Anton Rolls napsal(a): I am starting to wonder now. Has anybody seen this? Anton. I am curious too AR you can't have a dir and a file with same name. I wrote some time ago, that I was convinced the above statement would be true for all known OSes. Under Windows that may be true, but is it true for all platforms? --Gregg -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: rot13
Hi Julian, thank you for taking time to discuss the things. Some opinions are well informed: First, to be fair, some things I like about rebol: - very obvious influence from both lisp and forth, both of which are interesting, complementary languages. (this covers a lot of aspects of the language and its distribution) Yes, it is observable, that Rebol has inherited some advantages of both languages. - prototype-based OO, like self. This may be a matter of personal preferences. I like it too, but some users prefer a class-based approach. It may be mimicked to some extent. - the syntax elements are relatively orthogonal. Agreement here. - the way that evaluation is structured so as to make it unnecessary to have a fancy macro system is neat, although I don't fully know the ins and outs of it so I'm not sure exactly how it stacks up against CL, or scheme. This is the true innovation. It brings the feature its author calls dialecting. Without it Rebol wouldn't be as malleable and appealing as it is. Meanwhile, the following are some utterly subjective reasons, off the top of my head, why I still do not use rebol: (and, it should be noted, some of these may spring out of ignorance, or just that I'm feeling tired today.) - no open source compiler for the language, it seems, and the language appears to be controlled by a single company. (a negative to me, no matter how good-willed the employees of that company) This can be called and utterly subjective reason. It ceases to be true these days, because there are open source projects cloning language features. - a lot of things seem magic (as with perl), and the line between the language, its libraries, and its necessary runtime support is very unclear (also a fault, to some extent, of both forth and lisp). I take is as an overall description of the things detailed below. A specific example of the above that bugs me is that operators and functions behave differently (and you don't seem to be able to define infix functions). Yes, the behaviour of operators differs from the behaviour of the (prefix) functions. Although there isn't a way to define your own infix operators yet, this can be easily fixed in the future. I would say, that infix operators are there to allow programmers to use the ordinary formulas. For more andvanced uses you can always switch to prefix notation and do whatever you like. Another one is that, while all these magic datatypes are certainly handy, how do I define my own, with their own behavior, or override existing behavior? (perhaps this is a fault of the documentation, which I've just skimmed over again to make sure I'm not missing out.) You are not missing out, the mechanism for defining your own datatypes isn't there. You can only define new kinds of objects. There are three aspects of user datatypes: 1) in other languages datatypes protect their internal attributes. Rebol by design doesn't protect internal attributes of datatypes - e.g. native functions are mutable in Rebol, which may not always be considered an advantage. This is advocated as an orthogonality. (you can inspect/change virtually any complicated value) 2) Rebol actions (native functions operating on values of different datatypes) should be extended for every new user datatype. This looks like a hard task for a user and that may be the reason, why the language designer didn't want to allow it. 3) the type-checking mechanism has to change to allow new datatypes. - I don't like the way it looks and feels, personally... it's as if John McCarthy invented COBOL in some parallel universe. I find it can be a bit hard to read while trying to remember exactly the order in which the elements of a complicated statement are evaluated. (not that those rules are complicated) This is a subjective statement, hard to comment on. - it doesn't seem to do anything that my existing languages don't do. From the computational completeness POV clearly true. OTOH, there isn't another language with the built-in dialecting ability. The dialecting ability is a feature, that is more general and useful, than the ability to define new user datatypes or operators. (it is an ability to define completely new sublanguages) While there is always the danger of the blub paradox here, I guess what I'm saying is -- no type inference, no extension of the base types at runtime, not obviously easily embedded into an application written in another language, no clearly defined FFI, et cetera. This isn't to say those things are necessary, but it means that I don't see a compelling reason for me to use rebol. (this is where you come in ;-) ... not that I'm actually looking for reasons to use it.) Fairly stated :-), see my comment above. I make a living writing code and I've coded in over a dozen languages. Rebol's the most productive I've
[REBOL] Re: What does REBOL fix?
- everybody can teach me a dialect - lisp is scary - other languages aren't portable -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: read directory
Hi Romano, this looks like a windows specialty: read %/c/rebol ** Access Error: Cannot open /c/rebol ** Near: read %/c/rebol read %/c/rebol/ == [%core/ %view/] Isn't it annoying? I think that all Rebol should be uniformin reading directory port, the ftp: shows this error without the final slash: ** User Error: Server error: tcp 550 : Not a regular file So i think that the Windows behaviour is good, are the others (what?) to be changed. --- Ciao Romano well, it is annoying for me, because the %/c/rebol specification uniquely determines the target of my operation. Linux Rebol/Core behaves differently, but the behaviour looks unacceptable too. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: collect-in
Romano Paolo Tenca napsal(a): This is my idea of collect: collect-in: func [ {Append block evaluations to a series, use as body in For, Repeat, etc.} dest [block! hash! list! any-string!] Series to append results block [block!] Block to evaluate. /only Inserts into dest using the Only refinement. /local main ][ change/only change change second main: func [res [any-type!]][ none none none get/any 'res get/any 'res ] pick [insert insert/only] not only 'tail dest reduce [:main to-paren block] ] ;Usage: dest: make block! 100 repeat n 10 collect-in dest [n * 100] The advantages: is trasparent for break works with empty block inside the body you know where values are stored is not slow I should like to submit it the view 1.3 project What do you think? --- Ciao Romano Does this behave well w.r.t. Return? -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] read directory
hi, this looks like a windows specialty: read %/c/rebol ** Access Error: Cannot open /c/rebol ** Near: read %/c/rebol read %/c/rebol/ == [%core/ %view/] Isn't it annoying? -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: sort/compare
Anton Rolls napsal(a): In any case, I have implemented a customized shell-sort for the job, working fine so far. Regards, I have got a Merge Sort implementation for quite a long time (from 1.x days). It works fast (no exceptional cases), uses only one additional block and it is stable. Let me know, if you have got a use for it. The function used to be on my site once. I should put it to the library now. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: REBOL mailing list problems
Maarten Koopmans napsal(a): John, I take it you still have problems with getting off the list? Although I understand the *major* annoyance 64 forwards isn't too swell for the rest of us. What's the point in annoying hundreds of people because you have a problem? How would you feel if you were on a list and somebody behaves like you do? --Maarten Hi all, I checked with Ecartis and John was listed again. Check now send [EMAIL PROTECTED] who rebol Cheers -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: COLLECTing results
Hi Brett, Andrew, Romano et al., ---latest version collect: func [ {Collects block evaluations, use as body in For, Repeat, etc.} block [block!] Block to evaluate. /initial result [series! datatype!] Initialise the result. /only Inserts into result using Only refinement. ] [ if not initial [result: block!] result: any [all [datatype? result make result 1000] result] reduce ['head pick [insert insert/only] not only 'tail result 'do :block] ] I am sorry I missed your contribution on the subject somehow. I like it. My two cents changing the behaviour of the function in cases like: foreach head heads [...] foreach insert inserts [...] foreach tail tails [...] foreach do does [...] use [insert-only] [ insert-only: func [series value] [insert/only series value] collect: func [ {Collects block evaluations, use as body in For, Repeat, etc.} block [block!] Block to evaluate. /initial result [series!] Initialise the result. /only Inserts into result using the Only refinement. ] [ result: any [make result result make block! 10] reduce [ :head pick reduce [ :insert :insert-only ] not only :tail result :do block ] ] ] -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: COLLECTing results
Hi all, two more cents to let Return work as usual: use [insert-only] [ insert-only: func [series value] [insert/only series value] collect: func [ {Collects block evaluations, use as body in For, Repeat, etc.} [throw] block [block!] Block to evaluate. /initial result [series!] Initialise the result. /only Inserts into result using the Only refinement. ] [ result: any [make result result make block! 10] reduce [ :head pick reduce [ :insert :insert-only ] not only :tail result :do block ] ] ] -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: COLLECTing results
Forget about the last post, just an error. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [data structures] (was Re: [append][series]Appending to a series of strings)
Hi Joel and all, Joel Neely napsal(a): ...snip... The design of every language with which I'm familiar reflects at least two issues: the conceptual model used by the designer(s) (or lack thereof!) and the decisions about what things to make easy for the programmer using the language. Both Perl and REBOL make it easy to use a variable -- you just start using it and the language keeps up with what you're doing; no advance declaration is required. OTOH Java makes it easy to detect errors in type mismatch as early as possible (at compile time), which REBOL and Perl can't catch until the program is running. Perl goes further and makes it easy to use data structures; if you try to modify/store data, the appropriate place is automagically created (and initialized to an appropriate value, depending on the operation you are performing). The Perl expression ++$array[$n] means add one to the nth element of array. If the array doesn't have n elements (or if the array doesn't even exist!), Perl will allocate that position and and initialize it to zero before evaluating your expression. REBOL seems to occupy a middle-ground position on this issue; it does not require you to declare the existence of a data structure (as e.g. Java does) but it *does* require that you allocate and initialize it explicitly. I think, that you are describing *only* a top-down approach here. A bottom-up approach might lead to: get-value: function [ { get an element of a numeric array using zero-based index, default value is zero } array [block!] index [integer!] ] [value] [ value: pick array index + 1 either value [value] [0] ] set-value: func [ { set element of a numeric array using zero-based index, default value is zero } array [block!] index [integer!] value [number!] ] [ insert/dup tail array 0 index + 1 - length? array poke array index + 1 value ] inc: func [ { increment an element of a numeric array using zero-based index, default value is zero } array [block!] ] [ set-value array index 1 + get-value array index ] REBOL certainly has some nice built-in facilities for processing series data, but once you leave those you are *really* on your own. In Rebol you can teach the language to do what you want it to, because Rebol facilitates the process of the language extension. Language design decisions have far-reaching (and often subliminal) effects on the subsequent design thinking of programmers using the language(s) in question. One such issue that I find interesting is the question of when I -- as the programmer -- must commit to a decision regarding the data structures used within my programs. COBOL and Pascal require that I commit to the type and size of every array before submitting my programs to the compiler, and initialize the structures appropriately (at run time, but before any other use). Java requires me to commit to the type of an array, but lets me defer the size committment until run-time when I actually initialize it. Newer versions of Java provide the Vector class, which can be thought of as an array that can change size during use. Perl and REBOL (and Python, et cetera) arrays/blocks not only let me dynamically resize during use, I don't even have to commit to a single type of data to put there! Finally, (back to the original discussion) Perl will even automatically figure out when to allocate/initialize structures and elements for me. What if you needed a different default value, wouldn't that leave you on your own in Perl? Advocates of each of these languages will offer passionate arguments for why the binding-time choices of their preferred language are good. As a polyglot, I'm less interested in picking sides in a political debate than understanding deeply the effects on my own thinking when I begin to think like a native in one or more of them. -jn- I think, that the effect on thinking in Rebol may be caused more by inertia than by language limitations. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: FW: Re: [append][series]Appending to a series of strings
Hi, my solution using Parse (I think, that it is much faster, than other solutions): scores: clear [] loop 30 [append scores random 20] group: [p: set i integer! any i q: (print [score: i tallies: offset? p q])] parse probe sort scores [any group] Anton Rolls napsal(a): -Original Message- From: Anton Rolls [mailto:[EMAIL PROTECTED] Sent: Wednesday, 19 November 2003 12:36 pm To: [EMAIL PROTECTED] Subject: RE: [REBOL] Re: [append][series]Appending to a series of strings How about this? ; initialize some random scores scores: clear [] loop 30 [append scores random 20] ; figure out how many of each score tallies: clear [] foreach uscore sort unique scores [ append/only tallies reduce [uscore length? remove-each score copy scores [uscore score]] ] Anton. Suppose one has a collection of small natural numbers (such as test scores ranging from 0 to 100) and one wants to know how many occurrences of each distinct number there are. Using Perl arrays: # assume @scores contains the raw data with dups @tallies = (); foreach $score (@scores) { ++$tallies[$score]; } foreach $score (0..$#tallies) { print $score: $tallies[$score]\n if $tallies[$score]; } Using REBOL blocks: ; assume SCORES contains the raw data with dups tallies: [] foreach score scores [ insert/dup tail tallies 0 score + 1 - length? tallies change at tallies score + 1 1 + pick tallies score + 1 ] forall tallies [ if 0 tallies/1 [print [-1 + index? tallies : tallies/1]] ] or ; assume SCORES contains the raw data with dups tallies: [] foreach score scores [ either found? here: select tallies score [ here/1: here/1 + 1 ][ append tallies reduce [score copy [1]] ] ] foreach [score tally] sort/skip tallies 2 [ print [score ; tally/1] ] REBOL is much more literal; there are no values that one does not explicitly create (although it is possible to be implicitly explicit at times ;-). On the other hand, it is necessary explicitly to manage details that aren't at the same logical level as the original problem (making sure that there enough places to store the next tally needed, etc). I'd be interested in any *self-contained* solutions to the above task that might be clearer than the above. -jn- -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Apparent newbie question
Hi Steven, This must be something dumb, but I want to test the length of a block and can't seem to do it, yet I can print the length of the block. What am I missing? Thank you. *_*_*_*_* Sample script *_*_*_*_* REBOL [ ] TEST-BLOCK: [ Y 100 200 ] print [Length of TEST-BLOCK is length? TEST-BLOCK] if length? TEST-BLOCK 4 [ print block too short ] length? test-block 4 is equivalent to: length? (test-block 4) , while you wanted: (length? test-block) 4 -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: PLEASE REMOVE ME
Hi all, I unsubscribed John from the list, because the subject has become annoying for me. I doubt, that John seriously tried to unsubscribe. I unsubscribed him with a very simple Rebol script, but I am not sure, if I should post it here. Anyway, [EMAIL PROTECTED] is no longer present as I checked with Ecartis. -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: syntax across languages
Anton Rolls wrote: I am not completely sure what function composition means. Pixel said: function composition is a function taking 2 functions and returning a new one. Looking at some Haskell posts I see it kind of glues two functions together, passing the result from the first function into the second one. There are (resolvable) problems when the number of arguments are not the same, but, anyway... Doesn't this just mean that this is function composition: add: func [a b][a + b] mul3: func [a][a * 3] add-mul3: func [a b][mul3 add a b] ? Or it doesn't count because the composition is specified in the body block, whereas Haskell does it by referring only to the function names. It doesn't count, an answer in Rebol (needs some polishing): composition: func [ f [any-function!] g [any-function!] ] [ use [f' g' body] copy/deep [ f': :f g': :g body: [f' g'] foreach arg first :g [ insert tail body reduce ['get/any to lit-word! arg] ] func load mold third :g body ] ] Usage: add-mul3: composition :mul3 :add -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: PLEASE REMOVE ME
Tom Conlin napsal(a): oh good! now we can all forge ahead(er) his list flooding and personal mail to me (without answering my question) didn't give me much of a choice, although I didn't double-check, whether it was really him. I hope you don't know more than I do :-[ ah, what a relief! It looks, that it really was him O:-) -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Another coffee break problem?
Hi, how about this one: basic-magic: [ [0 8 4] [7 3 2] [5 1 6] ] permuts: [[1 2 3] [1 3 2] [2 1 3] [2 3 1] [3 1 2] [3 2 1]] id: func [block] [reduce [block/1 block/2]] swap: func [block] [reduce [block/2 block/1]] magic: copy/deep basic-magic foreach rp permuts [ foreach cp permuts [ foreach k reduce [:id :swap] [ repeat r 3 [ repeat c 3 [ set [pr pc] k reduce [rp/:r cp/:c] poke magic/:pr pc basic-magic/:r/:c ] ] probe magic ] ] ] -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: rebol headers when sending mail have no textual user name
Hi Max, see http://www.escribe.com/internet/rebol/m28017.html something is nagging me about the way rebol builds the header when sending mail. we can't seem to add a label to the from: mail address here are two valid headers: From: Maxim Olivier-Adlhoch [EMAIL PROTECTED] To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] note that the first one contains a string-based name to itself, so that all the tools like a mailer, can properly identify the sender, by something others than a cryptic mail address... is there a way to construct a mail header is such a way that the name is always included like in the first example? thanks! -MAx -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Script styles
Hi Andrew, Volker wrote (in another thread): Hmm, eventually rebol.org could mark RT-style-scripts so people can look up official examples when in doubt? Perhaps this could be a declaration in the header? For example: Style: 'Rebol-Official People who prefer different styles could then propose different style standards which they think might be better or just different, like: Style: 'Cobol-Like Style: 'Natural Style: none Style: Andrew ; :) After all, with out variation in style, how can it improve? What do people think? Sorry, I don't like this idea. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Please help me to promote REBOL
Hi, [EMAIL PROTECTED] napsal(a): Amending my original suggestion to take into account TRY'd code unsetting 'true or 'set, I'd suggest this for a simple, foolproof way to catch an error: don't use 'true, use 1: if error? error-code: try [do %config.r 1] [probe disarm error-code] if error? error-code: try [print 1] [probe disarm error-code] It's harder to unset 1. This may be as safe as you want it to be, but it is not convenient (append something just to be sure it returns a value). I prefer my Default function for this purpose instead. But the DO'd code could still have messed with 'if or 'error? or 'probe. That raises a wider question about DOing untrusted code. If you don't trust it at all, maybe it's better not to DO it in the first place. To seriously stop it messing things up while debugging: protect-system unset 'unprotect if error? error-code: try [do %config.r 1] [probe disarm error-code] This is not sufficient as I have proven long time ago. (Rebol functions are mutable, which means, that you can change the behaviour of any function - even a native without unprotecting the word referring to it. :-( Sunanda. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: syntax across languages
Hi, ... Does the attempt to provide a Berlitz-phrase-book mapping across really different languages do more harm than good, or is it a reasonable foot in the door for beginners? My 2 cents: it is reasonable, especially if it contains a reference to a more thorough text. I hate to write read once texts too, but I don't question the usefulness of this. Would a (for example) Perl-to-REBOL cookbook be of enough value to justify the (substantial) effort to produce it with reasonable quality and completeness, and would there be a large enough market for such a thing to have reasonable ROI? Where could I place the balance between simplicity/brevity versus honesty/completeness to maximize the value? It is up to you, but it will find its readers, I bet. ... Any/all feedback/comments are welcome! -jn- -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: (no subject)
Welcome, could you give us some examples of input and output? (I am a bit confused, what do you want to get for embedded parentheses). -L How parsing a string like : (STRING1=(STRING2=val2)(STRING3=(STRING4=)(STRING5=val5)(STRING6=val6))) to get the pairs string1/value1, etc...? with possible null val1. A recursive rule ? Thanks for help. Philippe -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Trapping an error
Hi Sunanda, this is worth a record at the R.E.P. site -L ... one such error (it'll crash 1.2.1.3.1 REBOL) is: aa: make object! [] bb: make object! aa The second line should be: bb: make aa [] Sunanda. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Coffee break problem anyone?
Hi Sunanda, ... but just to stick up for the finite machine state approach I took in the original code... you don't need SWITCH for a Finite State Machine implementation in Rebol (as has been discussed some time ago, Joel and others supplied nice examples), you can use functions or code blocks and DO. -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Why I don't need get-word here!
Hi, Indeed, it looks like lit-words are still word-active... Hmm, do you see any reason for this? Backward compatibility? --- Ciao Romano My guess is, that it has been overlooked... -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Coffee break problem anyone?
Hi Sunanda, here is my tea break result: find-longest-run: function [ [catch] data-array [block!] ] [ longest-run-size longest-run-start size position number ] [ if empty? data-array [throw make error! a non-empty array expected] longest-run-start: position: back tail data-array longest-run-size: size: 1 while [not head? position] [ if not number? first position [throw make error! an integer array expected] number: first position position: back position either (first position) = (number - 1) [ size: size + 1 if size = longest-run-size [ longest-run-size: size longest-run-start: position ] ] [size: 1] ] reduce [longest-run-size longest-run-start] ] -L - Original Message - Here's a little problem I needed an answer to yesterday. As I needed the answer yesterday, I hacked together some code. But there has got to be a more elegant way, surely. Maybe using parse on a block? The problem is this..You have a block containing integers, like this: sparse-array: [ 12 13 14 15 16 17 7 8 20 21 22 23 24 25 26 19 59 58 57 56 55 54 53 52 20 21 22 23 101 102 103 104 105 106 107 ] They are not in ascending order, and there are some numbers duplicated. But there are runs of consecutive, ascending integers: 12--17, 7--8 etc. We want to find the location in the block of the first longest, such sequence. The answer for this dataset is 20--26. 101--107 is as long, but isn't the first. 59--52 is longer, but it is descending. My solution is below. Someone can do better, surely! Thanks, Sunanda -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Rebol copy semantics
I am interested and I appreciated help from Colin, Pat, or others. The best may be to just send me questions (or suggestions) and I will try to incorporate the answers to the text. Other approaches are possible too. TIA -L ...and these articles are very valuable even sometimes (at least for me) hard to follow. While reading your documents I often think back at university times ;-) How about making them easiert to understand for the Rebol novice? I would like to help with this. Let me know. Robert -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Rebol copy semantics
Hi Robert, Hi, even doing Rebol for several years now, I'm hit by the question hmm... is this now a reference or a copy?. Especially in complicated cases, where you work a lot with blocks, inserts, copying etc. it's easy to loos track (at least IMO). Things get even more complicate as some functions seem to create implicit copies as well. So, for series you get a reference for scalar types you get the value (see my other posting). Is there a how-to/tutorial/... that collects all this information in one doc? If not, do you think it would make sense to write such a thing? Robert I wrote a few articles: http://www.compkarori.com/vanilla/display/Rebol+Series or http://www.fm.vslib.cz/~ladislav/rebol/identity.html or check: http://www.compkarori.com/vanilla/display/Rebol+Tutorials Regards -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: reduce/deep
Hi Andrew, you wrote: I'm assuming that this would work on tree structured blocks, not blocks that are are recursively 'insert-ed into each other? Andrew J Martin Grail Jedi actually, even cyclic (or recursive, whatever you prefer) blocks can be handled as I have proven in http://www.fm.vslib.cz/~ladislav/rebol/identity.html#section-24 , but the usefulness of such structures is questionable. Anyway, if you need such a construct, it is a matter of minutes for me. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: reduce/deep
Hi Maarten, Don't take away my hobby project ;-) I assume you'd traverse the block structure recursively using tail-func with the block and the last position that was evaluated? --Maarten I am not sure we understand each other. I think, that Andrew meant cyclic blocks like a: [1] insert/only a a I wouldn't use tail-func probably, but you are close. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Newbie: need help with COMPOSE
Hi Arie, - Original Message - From: Arie van Wingerden Hi list, below a extracted piece of program containing 2 times a do rejoin. I tried hard to not use rejoin, but compose instead, but it did'nt work out properly. Could you show me how to rewrite the code in both cases? Thanks in advance, Arie van Wingerden http://home.zonnet.nl/rebolution ;;; = Code follows here REBOL [] ; ; This function extends a 2nd level object with a function ; add-affix-func: does [ do rejoin [ rules/ fxname : make rules/ fxname [ ; Extend 2nd level object rule fxcount : func ; Function name [ inword [ string! ] ] ; Function spec block [ print 200 ] ] ] ] ; ; Main program starts here ; fxname: A ; name of 2nd level object fxcount: 1 ; counter rules: make object! [] ; create 1st level object do rejoin [ rules: make rules [; create 2nd level object fxname : make object! [ x: 100 ]] ] probe rules ; show intermediate result input ; pause console add-affix-func ; extend 2nd level object probe rules ; show final result input ; pause console I (and the documentation) suggest you to avoid doing strings. Try the code below: add-affix-func: has [fxn] [ fxn: in rules fxname set fxn make get fxn compose [ (to set-word! join rule fxcount) ; Function name func [inword [string!]] ; Function spec block [print 200] ] ] fxname: 'A ; name of 2nd level object fxcount: 1 ; counter rules: make object! [] ; create 1st level object rules: make rules compose [; create 2nd level object (to set-word! fxname) make object! [x: 100] ] probe rules ; show intermediate result ; input ; pause console add-affix-func ; extend 2nd level object probe rules ; show final result ; input ; pause console -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Tail end recursion
I think, that my version looks different/shorter, but uses the same basic principle. It is at: http://www.fm.vslib.cz/~ladislav/rebol/tailfunc.r -L - Original Message - From: Ged Byrne Thanks for that. I look forward to the day that I can understand it :) -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Parse limitation ?
Hi Pat, - Original Message - From: patrick à la poste Hi List, I'd like to parse a string searching for two things at the same time. it seems to me that this is impossible. For example, a text from which I want to extract the HREF and the SRC target. myText: {A HREF=#section1IMG SRC=foobar.gifA HREF=#section1} parse myText [ any [ thru HREF= copy target to (print target) | thru SRC= copy target to (print target) ] ; any ] ; parse #section1 #section1 parse myText [ any [ thru SRC= copy target to (print target) | thru HREF= copy target to (print target) ] ; any ] ; parse foobar.gif #section1 The result is different depending which rule comes first. The only way I see as a workaround is to parse the text twice. Is there a better (smarter) way? Regards Patrick This is possible with PARSE. You can use my parse enhancements e.g. Have a look at: http://www.fm.vslib.cz/~ladislav/rebol/parseen.r Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: to-number does not work
Hi all, - Original Message - From: Brett Handley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 6:40 AM Subject: [REBOL] Re: to-number does not work It looks like these to-* functions have been created for the pseudo types.. I think my pick of the bunch would be: to-any-type make my day :^) Anybody else sent this to feedback yet? Just looking up the public bug tracking system... oops we don't have one! You better send it then :^) Regards, Brett. edit: http://www.compkarori.com/vanilla/display/Core+Level , please. - Original Message - From: Ashley Truter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 1:53 PM Subject: [REBOL] to-number does not work I get the following with 1.2.10.3.1: to-integer 1 == 1 to-decimal 1 == 1 to-number 1 ** Script Error: Cannot use to on datatype! value ** Where: to-number ** Near: to number! :value Anybody else sent this to feedback yet? Regards, Ashley -Ladislav -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: steel latest news.. pretty long... Ignore if you wish..
altough the subject is getting offtopic, I had to make a couple of comments, because less informed readers may be misled by the discussion: Yeah, anything you did before getting a commercial license is bound to GPL (even while evaluating the software) and that's not much fun... this is an error, you aren't bound by the GPL if you aren't distributing code. Moreover, you aren't bound by the GPL if you are distributing code under a different license which has been agreed upon by the copyright owner(s). And then, even getting a commercial license does not free that code from GPL... The code isn't freed from GPL in the sense, that everyone using the software legally under the GPL doesn't lose his right to do so. OTOH, the code distributed under a non-GPL license is free from GPL in the sense, that anybody using it isn't bound by the GPL at all, even though the software may have been released by the GPL too. -L -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Parsing bug?
Hi Franck, you can do: parse/all text [ (result: copy []) start: any [ #| end: (append result copy/part start back end) start: | skip ] (append result copy start) ] result - Original Message - From: Franck MARCIA Hi all, Is that a bug or is there something I don't understand? text: {The|quick brown|fox jumps|over the lazy|dog} == {The|quick brown|fox jumps|over the lazy|dog} parse/all text | == [The {quick brown} fox jumps {over the lazy} dog] Look at the field which contains {fox jumps}! How can I get [The {quick brown} {fox jumps} {over the lazy} dog]? Franck. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Rebol pickling recipes ?
Hi Laurent, What exactly do you mean by loading words without using 'load ? As I see it, Gabriele meant, that you can make a word without using LOAD as follows: a-word: first make block! xxxyyy probe a-word ; xxxyyy The word we made this way cannot be found in REBOL/WORDS: in rebol/words a-word ; == none LG If I am right this would allow a kind of persistent rebol environment : 'molding LG system before quitting and 'loading it a few days later and finding the LG environment exactly in the same state. That could have many applications. That's what you get with FORTH. I don't think it is possible in REBOL in the general case, but you could do it partially. I guess that by partially you mean only for the context that your script(s) have knowledge of ? Would that mean that, for example, one would have to store all code and data within a single object to make sure everything he needs is correctly restored (puting aside the need to handle circular references properly) ? Not exactly. Let's see this: block1: reduce [a-word] ; == [xxxyyy] block2: compose/deep [[(a-word)]] ; == [[xxxyyy]] block3: reduce [first use block1 block2 first use block1 block2] set first block3 1 set second block3 2 Now we can explore the properties of BLOCK3: probe block3 ; == [xxxyyy xxxyyy] reduce block3 ; == [1 2] Let's suppose, that we just use the MOLD function to make BLOCK3 persistent. If we LOAD the result back, we don't get a block having the same properties as BLOCK3 and that is the trouble. Regards -Ladislav -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Rebol pickling recipes ?
Hi Gabriele, BTW, I just found out this curious behavior: find first system/words to-word never-defined-this == none find first system/words to-word never-defined-this == [never-defined-this] which shows that using TO-WORD the word gets added AFTER the evaluation of that expression. I cannot give an explanation of this; it might be some kind of side effect of the current implementation (this is REBOL/View 1.2.8.3.1 3-Aug-2002); Ladislav, Romano, do you have any ideas? this is just an evaluation order artifact - FIRST SYSTEM/WORDS isn't a living thing, it is just a freezed copy. You can get a normal behaviour, if you try this: in rebol/words to-word never-defined-this ; == never-defined-this , while: in rebol/words first to-block never-defined-this-2 ; == none Cheers -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Rebol Resources
Hi Tim, my articles are at: http://www.rebolforces.com/~ladislav - Original Message - From: Tim Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 01, 2002 8:37 PM Subject: [REBOL] Re: Rebol Resources Hello Gerard: * Gerard Cote [EMAIL PROTECTED] [020930 18:27]: Even if I didn't get sufficient time to look at any one of the advertised FRENCH REBOL Forums some time ago, it seems these could be added to your list. Do you have links? Even my 2 sons (12 and 15 years old) don't speak English at all, but they look regularly at English Forums and other Web sites with the help of online translators. May be this could be suggested to your students too as another way to learn REBOL (and other languages by the same occasion if anyone shows some interest about this) in a different way ... and presenting the English summary of some HOT discussion would be required by you as a teacher ??? However Team work generally helps in this case! Regards, Gerard P.S. In any other cases I could also suggest the .cz Web sites references like the one site where are hosted Ladislav's articles about advanced REBOL's inside view. You'll find his ref's on the reboltech site or write me if you can't afford to looks for, I'll post them to you directly. And links for these too...? Thanks! -- Tim Johnson [EMAIL PROTECTED] http://www.alaska-internet-solutions.com http://www.johnsons-web.com -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Parsing comment
Hi Pat, this is a matter of personal preference. I always use the TO function. (speed, generality) Speaking about personal preferences: I am eliminatig the usage of functions with unevaluated arguments and I suggest everyone to do that (see my Rep for the reasons). The only reason I used them in my example is, that they change the evaluation order in an unexpected way, which is normally a bad thing (IMO - this is another point where my POV differs from Tim Peters'). - Original Message - From: pat665 Hi Ladislav, Could you explain a bit your code ? especially this line print: func ['x] [reduce ['print to paren! x]] Why is it not print: func ['x] [reduce ['print to-paren x]] Ciao Patrick -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Parsing comment
Hi, allow me to jump in. Tim Peters was a regular Rebol list member for quite some time, so he knows what he is speaking about. The comment on function free-formness surprises me like it surprised Gabriele, because anyone can use parens at will. Some expressions really need parentheses for readability. The only trouble with the free-formness is, that the interpreter has got more work to do, which may slow down the interpretation. Operators: I wrote some comments on operators in http://www.rebolforces.com/~ladislav/rep.html - the section on Evaluation Order. Basically, the interpreter considers some words to be slightly different than others - I call them OP-WORDS. Gabriele revealed, that there is an unused OP-WORD !=. If an OP-WORD has a value of the OP! type, it becomes a Rebol operator. -L - Original Message - From: Andrew Martin Carl Read wrote: (Or can we write operators, for that matter.) ... + 1 2 == 3 1 + 2 == 3 sum: func [a b][a + b] sum 1 2 == 3 1 sum 2 ** Script Error: sum is missing its b argument ** Near: sum 2 Can it be done? We can do something like it (acknowledgements to Gabriele): !=: get first [] And use it like: 0 != 2 == true 4 != 4 == false But I don't know how to make other infix operator functions. It would be nice to have them. I've got at least one application for it. Andrew Martin ICQ: 26227169 http://valley.150m.com/ -- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Parsing comment
Hi, I don't understand your post. I am pretty sure, that even print (a + b) has no meaning in Rebol without a context supplying additional info. Example of an atypical meaning: use [print a] [ print: func ['x] [reduce ['print to paren! x]] a: func ['x 'y] [compose [a (x) (y)]] print (a + b) ] ; == [print (a + b)] Cheers -L - Original Message - Sent: Wednesday, September 25, 2002 5:23 PM Subject: [REBOL] Re: Parsing comment Also, the whole idea is that REBOL is dynamic. It couldn't be if there was punctuation. I.e.: print a + b DOES NOT have a meaning, unless evaluated under some rules and some context. When you use syntax to give meaning (as opposed to context), you are imposing artificial limits. Whether they are useful or not, depends. I think that the point of REBOL is simplifying, also by removing some artificial limits. Of course, IMHO. print a + b would have meaning if evauation order was right to left or parentheses were used print (a+b) -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: text-list bug
Hi Phil, no bug here rebol/version == 1.2.1.3.1 Windows 2000 Cheers -L - Original Message - Hi All, After selecting multiple items from a text list it doesnt seem possible to unselect a particular item. They get unselected in the order that they were selected. for example type at the console view layout [text-list data [1 2 3 4 5 6 7 8 9]] Hold down the ctrl key ... select items 1 2 3 4 5 6 7 in that order, then try and unselect item 5 by ctrl clicking on it item 1 is unselected? Is this a known bug? Cheers Phil -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] parse/recycle bug
Hi all, Romano wrote a small macro interpreter. I simplified it a bit, used two variants (the second variant uses explicit RECYCLE command) and here are my results: delimit: [*(] notpar: complement charset ) compose-string: function [ [catch] String [string!] /trace ][ macro start end comm ][ macro: [ some [ start: delimit [ any [ [ (macro: use [start] reduce [copy/deep macro]) macro ] | notpar ] #) end: ] opt ( if = comm: copy/part skip start 2 back end [comm: {}] change/part start do comm end ) :start ] ] either parse/all String: copy String [some [macro | skip]][ string ][throw make error! Invalid string] ] compose-string-2: function [ [catch] String [string!] /trace ][ macro start end comm ][ macro: [ some [ start: delimit [ any [ [ (recycle macro: use [start] reduce [copy/deep macro]) macro ] | notpar ] #) end: ] opt ( if = comm: copy/part skip start 2 back end [comm: {}] change/part start do comm end ) :start ] ] either parse/all String: copy String [some [macro | skip]][ string ][throw make error! Invalid string] ] home: to comment [ ; the following crashes Rebol loop 500 [compose-string go *(home) *(home)] ; while this doesn't crash, but leaves the interpreter in a strange state compose-string-2 go *(home) *(home) ] I would guess, that this is another recycle bug. Cheers -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: parse/recycle bug
Hi myself and all others, I succeeded to simplify further the issue. The following PARSE crashes Rebol rule1: [ (rule: copy/deep rule2) rule (print rule1 done) ] rule2: [ (rule: copy/deep rule3) rule (print rule2 done) ] rule3: [ ( recycle print rule3 done ) ] parse rule1 Cheers -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: parse crash - (was: Re: parse consumption)
Hi Anton, thanks for your example. I think, that it can be reduced to: parse/all / [start: skip opt (remove start) to *] It is interesting, that the following code doesn't cause the crash: parse/all / [start: skip opt (remove start) to #*] Cheers -L - Original Message - From: Anton Well, here is a simple example, tested on a clean REBOL/View 1.2.8.3.1 3-Aug-2002 (beta) and a clean REBOL/View 1.2.1.3.1 21-Jun-2001 I could probably do some more experiments and figure out some more details, but anyway: --- crash: func [demonstrates a bug in parse that crashes rebol target [any-string!] {try /../} /local start post ][ parse/all target [ start: / any [ ../ post: (remove/part start post) | to / ; to or thru will cause the crash ] ] ] crash /../ --- Maybe someone can reduce it further. Anton. I am sure it can crash rebol. I just don't have a simple example yet. I will try to strip it down to a small example. Anton. It has been discussed with RT, but they preferred to explain the current behaviour rather than to change it (compatibility reasons?). If you (or others) let them know that you prefer simplicity, they may change their mind. (Please, do!) OTOH, I am not sure if any crashes can happen this way? - Original Message - From: Anton... I agree with your proposed behaviour for parse. I suppose you have submitted this idea to feedback a long time ago? It might also be submitted with more urgency because such a dangerous removal can crash rebol. Anton. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Error trapping (Was: Beginner's questions on REBOL/Core and REBOL/View)
Hi Anton, I almost did, see the DEFAULT2 function I posted some time ago :-). But, seriously: 1) we are unable to handle crashes 2) we are unable to catch some errors (especially throw-errors) 3) do/next cannot handle cases like: do/next [ do [ lots-of-code-here ] ] with sufficient granularity. 4) it would really be better to traverse the interpreter stack: a: func [x] [1 / x] a 0 ** Math Error: Attempt to divide by zero ** Where: a ** Near: 1 / x I would prefer the message to be: ** Math Error: Attempt to divide by zero ** Near: 1 / x ** Where: a 0 Another (more complicated) example: a: func [f x] [f x] a func [x] [1 / x] 0 ** Math Error: Attempt to divide by zero ** Where: f ** Near: 1 / x Similarly as above, the two-level message I prefer would be: ** Math Error: Attempt to divide by zero ** Near: 1 / x ** Where: f x , but a three-level message: ** Math Error: Attempt to divide by zero ** Near: 1 / x ** Where: f x ** Where: a func [x] [1 / x] 0 would be more helpful in this case. Cheers -L - Original Message - From: Anton We could probably make our own line by line, or expression-by-expression interpreter. Check out do/next. Anton. Unless I'm way off, REBOL has a stack-based architecture to it - could we not have a Smalltalk-like walkback window that shows the call sequence, and what lines each call is related to (where they are related)? Clicking on a line item shows the context/state of all relevant store at that point. Very handy. Kemp -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: More dialects than you think, validating function input.
Hi Brett, I don't know, why you didn't write it as follows: f3: func [ [catch] block [block!] ] [ if not parse block [any [number!] end] [ throw make error! F3 can only process numbers. ] ] The parse rule contains END only for compatibility with my proposed PARSE behaviour, otherwise it isn't necessary. Cheers -L - Original Message - From: Brett Handley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 12, 2002 2:05 PM Subject: [REBOL] More dialects than you think, validating function input. I have a function that takes a block! as an argument. This block! should contain only numbers. The question is how do I check for valid input and throw an error on encountering a problem in an efficient manner? My first thought was something like this: f1: function [ [catch] block [block!] ] [kount] [ kount: 0 repeat value block [ if not number? value [ throw make error! F1 can only process numbers. ] kount: kount + 1 ] ] After reflecting on this, I thought about how a block! passed to a function is one sense is being interpreted by the function according to an implied grammar. That is my requirement in the above function for only numbers, in a sense, implies that my function is processing a fairly simple REBOL based grammar (ie dialect). I don't think it is too outlandish to say every function that processes a block! is implementing grammar processing even if trivial. Hence, the subject title of this message. As a side note, I reckon every offline script can be considered as an out of memory block! ready for loading. Anyway, this thought leads me to PARSE, REBOL's grammar validator. So I recoded my function to look something like this: f2: function [ [catch] block [block!] ] [kount value] [ kount: 0 if not parse block [ any [set value number! (kount: kount + 1)] | set value any! to end ] [throw make error! F2 can only process numbers.] ] Then I did some quick and dirty testing to see which was faster. On my machine, F2 takes half the time that F1 does. Just thought I'd share my little ramble. Test code below. Cheers, Brett. REBOL [] data: copy [] repeat i 2000 [insert tail data i] f1: function [ [catch] block [block!] ] [kount] [ kount: 0 repeat value block [ if not number? value [ throw make error! F1 can only process numbers. ] kount: kount + 1 ] ] f2: function [ [catch] block [block!] ] [kount value] [ kount: 0 if not parse block [ any [set value number! (kount: kount + 1)] | set value any! to end ] [throw make error! F2 can only process numbers.] ] timeit: func [f] [ t1: now/precise repeat i 300 [error? try [f data]] t2: now/precise t2/time - t1/time ] print [f1 timeit :f1] print [f2 timeit :f2] insert at data 1001 'a-word print [f1 - error half way timeit :f1] print [f2 - error half way timeit :f2] --- Website: http://www.codeconscious.com Rebsite: http://www.codeconscious.com/index.r -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: More dialects than you think, validating function input.
Thanks. -L - Original Message - From: Brett Handley ... Here is the actual function I was working on: bayes: function [ {Calculate combined probability.} [catch] probabilities [any-block!] ] [p0 p1 d] [ p0: p1: 1.0 if not parse probabilities [ any [ set value number! (p0: value * p0 p1: 1 - value * p1) | set value any-type! to end skip ] ] [throw make error! reduce ['script 'cannot-use 'bayes mold type? get/any 'value]] if zero? d: add p0 p1 [throw make error! The probabilities cannot be combined.] divide p0 d ] Sorry for the confusion. Brett. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: parse consumption
Hi Anton, this is an old parse glitch. The difference between your rules is, that the second one didn't cause the internal pointer to get past the end of the input and therefore it didn't fail. Current parse behaviour: 1) If a rule causes the internal pointer to get past the end of the input, PARSE considers it a failure. This means, that even a PAREN! rule can fail, if it removes a part of input. 2) to yield TRUE PARSE must 2a) get successfully through the whole rule 2b) get to the end position of the input My favourite behaviour looks different: 1) past end position doesn't mean a failure 2) to yield TRUE PARSE has to get successfully through the whole rule If you want PARSE to behave like I proposed above, you can use the following workaround: parse abc [start: abc opt (remove/part start 3) :start to end] ; == true HTH -L - Original Message - From: Anton I have here a bit of confusion: parse abc [start: abc (remove/part start 3) :start end] ;== false parse abc [start: to abc (remove/part start 3) :start end] ;== true The first parse consumes the abc before removal, and the second one doesn't. Why does it matter whether abc is consumed or not? I am setting the input position to the start of the string afterwards with :start. I have verified that before the removal, start is at the beginning of the string. Also, this is the same both in latest beta and last full release. Anton. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: parse consumption
It has been discussed with RT, but they preferred to explain the current behaviour rather than to change it (compatibility reasons?). If you (or others) let them know that you prefer simplicity, they may change their mind. (Please, do!) OTOH, I am not sure if any crashes can happen this way? - Original Message - From: Anton... I agree with your proposed behaviour for parse. I suppose you have submitted this idea to feedback a long time ago? It might also be submitted with more urgency because such a dangerous removal can crash rebol. Anton. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi all, I thank Romano for his finding and try to comprise out knowledge about Rebol errors. We can classify errors by the interpreter behaviour to three groups: 1) crashes (errors, that crash the interpreter). I think, that such errors shouldn't exist at all. (Opinions?) 1a) Native function crashes, like SAME? crash, where it is enough to modify the function - my IDENTICAL? doesn't crash. (I don't understand, why this crash still persists?!) 1b) Self-modifying code crashes - there is only one recipe to cure this - rewrite the interpreter, i.e. use a slightly different interpretation strategy. An example of such crash is: a: func [x] [1] a a: 1 This crash has already been cured, but the behaviour still is strange - compare it to the Freebell interpreter's behaviour, where the above code isn't self-modifying at all! These crashes can be eliminated - e.g. using a strategy I proposed. (Opinions?) 2) Errors are representable by Rebol values which don't crash the interpreter. 2a) Errors, that cannot be caught. Examples are THROW ERRORS caused by RETURN or EXIT out of function, THROW out of a catch block or BREAK out of a loop. I think, that the interpreter should be modified to be able to catch these. (Opinions?) 2b) Normal errors, that can be caught by the TRY function (or my DEFAULT/DEFAULT2). Another possibility is to classify errors by aggressivity of their evaluation. Almost every error is second class like: II) type? make error! ; == error! , which is OK, but: type? (make error! ) ** User Error: ** Near: make error! doesn't yield the same result as the former expression, which is an interpreter quirk. I propose to change all errors to first class, which would be: I) Hypothetical! type? (make error! ) ; == error! III) Romano revealed, that some errors are third class, like: type? make error! [throw no-loop] ** Throw Error: Nothing to break ** Near: type? make error! [throw no-loop] , which is a bigger quirk than above. Opposite opinions welcome Cheers Ladislav -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Romano, the behaviour seems to have more to do with function attributes: Romano ... no-loop error! seems to have the same beaviour which has any others error, when a function has at least the attribute []: error? do func[][return make error! any] ;== true error? do func[[]][return make error! any] ** Throw Error: Return or exit not in function ** Where: func [[]][return make error! any] ** Near: return make error! any /Romano See the following code samples: type? do does [type? do func [] [return make error! ]] ; == datatype! type? do does [type? do func [[throw]] [return make error! ]] ; == error! type? do does [type? do func [[]] [return make error! ]] ; == error! The empty attribute is interpreted like the [throw] attribute in this case! It looks like an implementation issue. Ciao Ladislav -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Romano, no objection to your analyse. The fact, that the expression (first block2) is illegal, while (error? first block2) isn't justifies my POV, that this behaviour is a Rebol quirk. I want the interpreter/language to be less aggressive (and faster and simpler and logical ...). I am saying the same about the exposition of the UNSET! datatype, and I was saying it about the exposition of the END! datatype, but the last one got straightened. Romano Hi Ladislav and Gabriele, Your IS-REALLY-ERROR? function works for simple code like above, but, AFAIK, we cannot handle all possible cases, like e.g.: is-really-error? [1 first block2] ; == true (until errors will be first class). You are right about first class, but i think the code above gives the correct result in the actual implementation of Rebol, because, for example, the execution of the block: [x: 1 first block2 x: 2] is interrupted with a real error when the expression first block2 is executed, and x: 2 is never executed: do [x: 1 first block2 x: 2] x ; == 1 so this is a real error in the actual Rebol implementation. I think, indeed, that is not correct to return false with: is-really-error? [first block2] ;==false for the same reason. The function should answer to this question: the code fires an error when evaluated? and [first block2] fires an error when evaluated. While the expression: [type? first block2] does not fires an error when evaluated I think there is no difference from this point of view between [first block]- error [first block2] - error but there is a difference between [type? first block] - error [type? first block2] - not error And Try is enough to discern them. Is-really-error? should be called: can-some-functions-accept-this-argument-without-an-error? and the blocks [first block2] can be accepted by many functions if not evaluated, but when you do it, before passing the result to a function, it always fires an error! BTW, actual implementation fails with is-really-error? first block2 ;== *** error! but can be corrected. --- Ciao Romano -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Gabriele, Romano, myself and others, when I said: L IS-REALLY-ERROR? function works for simple code like above, but, AFAIK, we cannot handle all possible cases, like e.g.: is-really-error? [1 first block2] ; == true (until errors will be first class) /L , I was wrong. Here is a (complicated, but working) version of the DEFAULT function, that can handle it: do http://www.rebolforces.com/~ladislav/highfun.r default2: transp-func [ code [block!] fault [block!] /good pass [block!] /local result error code2 ] [ transp-while [not tail? code] [ code: if error? set/any 'error try [ set/any 'code2 second do/next compose [ error? set/any 'result (code) ] skip code (index? code2) - 3 ] [tail code] ] either error? get/any 'error [ fault: func [[throw] error [error!]] fault local-return fault error ] [ do any [pass [local-return get/any 'result]] ] ] block2: head insert copy [] try [first []] default2/good [first block2 1] [error] [pass] ; == pass default2/good [first block2] [error] [pass] ; == pass default2/good [first []] [error] [pass] ; == error Ciao Ladislav -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Correction, I posted a wrong version, so once again: do http://www.rebolforces.com/~ladislav/highfun.r default2: transp-func [ code [block!] fault [block!] /good pass [block!] /local result error code2 ] [ transp-while [not tail? code] [ if error? set/any 'error try [ code2: second do/next compose [ error? set/any 'result (code) ] code: skip code (index? code2) - 3 ] [code: tail code] ] either error? get/any 'error [ fault: func [[throw] error [error!]] fault fault error ] [ do any [pass [local-return get/any 'result]] ] ] block2: head insert copy [] try [first []] default2/good [first block2 1] [error] [pass] ; == pass default2/good [first block2] [error] [pass] ; == pass default2/good [first []] [error] [pass] ; == error Ciao Ladislav -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Gabriele and all, LM I am still curious, if many Rebol users prefer to allow UNSET! valued LM expressions (eventually why?). Gabriele There's no reason to have them, and that's just likely to be an implementation issue with the current interpreter (it needs unset! for unset words, and once you have that is pretty natural to have: f: func [] [return] return unset!, being RETURN's argument unset; so they have probably decided that empty blocks should have returned unset! too...) /Gabriele L You are right, it looks logical at a first glance. Nevertheless, the following looks logical too: type? while [false] [] ; == none! and it differs from type? do [] ; == unset! I think, that the behaviour should be unified. My proposition is to use the former convention, which is much less complicated. I am not against using UNSET! values internally for the interpreter purposes (detection of uninitialized variables). OTOH, this purpose is totally internal and shouldn't be exposed to the user. A similar quirk with an END! type value has already been straightened by RT. /L LM OTOH, both versions of DEFAULT cannot discern illegal and legal errors, LM which is another quirk in Rebol I would prefer to have straightened. Gabriele I was looking in your site to see what you intend for an illegal error, but I wasn't able to find it. /Gabriele L It is my fault, I wrote it too lazily. Here is a more thorough explanation: block: [] probe disarm try [first block] ; == make object! [ ; code: 315 ; type: 'script ; id: 'past-end ; arg1: none ; arg2: none ; arg3: none ; near: [first block] ; where: none ; ] The result of the (first block) expression evaluation doesn't exist in a sense. Try creates its result catching the fired error you see above. Now a more complicated code sample: block2: head insert tail copy [] try [first block] probe disarm try [first block2] The difference is, that in this case the result of the (first block2) expression evaluation legally exists, that is why I call it a legal error. A function like TRY cannot discern these cases, while a native version of the DEFAULT function could. Ciao -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi again, LM The difference is, that in this case the result of the (first block2) LM expression evaluation legally exists, that is why I call it a legal LM error. Gabriele I see. I'd more likely have errors as first class, instead of a DEFAULT function able to make the distinction. Anyway, it is possible to discern the two cases with: is-really-error?: func [code] [error? try compose [error? (code)]] is-really-error? [first block] == true is-really-error? [first block2] == false I haven't tried it with any other case tough. /Gabriele It looks to me, that the first class error and the legal vs. illegal error distinction are two sides of the same coin. Your IS-REALLY-ERROR? function works for simple code like above, but, AFAIK, we cannot handle all possible cases, like e.g.: is-really-error? [1 first block2] ; == true (until errors will be first class). Ciao -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi all, Ed ... Personally, I would call it a quirk, but every language has its quirks, why should REBOL be any different. :) /Ed I call it a quirk too and I suggested to straighten the things some time ago. Meanwhile I use my DEFAULT function: default action error-handling The source of the function is: Rebol [ Title: Default File: %default.r Author: Ladislav Mecir Email: [EMAIL PROTECTED] Reb: reb://Sites/Ladislav Web: http://www.rebolforces.com/~ladislav Purpose: { An error handling function } Category: [General] ] default: function [ { Try to evaluate code. Evaluate the fault block, if an error occurs } [throw] code [block!] fault [block!] /good pass [block!] ] [result] [ either error? set/any 'result try code [ use [error] compose [ any-type? error: :result do (reduce [fault]) ] ] [ either good [do pass] [get/any 'result] ] ] -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Gabriele, G ... BTW Ladislav, do you think there could be any problems with this alternative version? default: func [ [throw] code [block!] fault [block!] /good pass [block!] /local result ] [ either error? set/any 'result try code [ fault: func [[throw] error [error!]] fault fault result ] [ do any [pass [get/any 'result]] ] ] /G I think, that your version is more understandable and more robust. That is why I suggest others to use Gabriele's version instead of mine. I am still curious, if many Rebol users prefer to allow UNSET! valued expressions (eventually why?). OTOH, both versions of DEFAULT cannot discern illegal and legal errors, which is another glitch in Rebol I would prefer to have straightened. Ciao -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Ed, it looks, that you missed my advice on this. Ed ... If Error? try [Fred: Print See?][Print Whatever!] See? Whatever! Yes. But the value that I was trying to assign Fred was the error that was to occur when I attempted my action. More accurately, I have written a couple of daemons, that execute a command that I pass to it as a parameter. I wanted the daemon to send out an email if it could not execute the action it was assigned. Something like this (where Action is the variable that holds the statement to be executed: If Error? Error: Try [ Do Action] [ Send Warning email ] Realizing that Try is similar to Do, I even used: If Error? Error: Try [ Action] [ Send Warning email ] The first executed without issue, making me think that everything was executing OK; it wasn't. The second gave me the no value error. But this is why I'm confused: If try is to be used to help trap errors, why does it care if a value is set or not? That's why I pointed out that I got the error when issuing a write command. If anything needed to be trapped, it was that. How else can I tell if a file is not there, or I don't have access permission, or the file system is too full, etc? /Ed L the situation is simpler than you think. You can use: if error? set/any 'error try action [send warning email] Try doesn't care what is the result value. Your problem is, that if you use an expression like (error: ...), the interpreter fires an error, if the result of the (...) expression is of the UNSET! datatype. This means, that the error occurs outside of the try block, which means, that TRY cannot trap it. /L Ed ... The above statements, BTW, were taken (in form) from a REBOL manual. They were text-book examples... /Ed L yes, there are some misleading informations in the documentation... /L Ed I suppose I could use that technique as part of my error trapping, the question still remains: why? Error trapping should have to do with trapping errors, not (just) return values. /Ed L you can, you just need to know how and why... /L Cheers -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Ed, Rebforce can easily help you. Try these: If Error? set/any 'Fred Try [ Print Get a grip! ] [ Print Whatever! ] If Error? set/any 'Fred Try [ Write %Temp.txt Yup! ] [ Print Whatever! ] We might call it a subtle intricacy of the language. This is a feature, that deserves a lengthy discussion. I would prefer a different behaviour instead, but the above solution works... The whole trouble is caused by a situation similar to this: a: () , while this works: set/any 'a () Cheers -L - Original Message - From: Ed Dana [EMAIL PROTECTED] To: REBOL List [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 4:51 AM Subject: [REBOL] Help me, Obi Reb Kenobi, you're my only hope! OK, so what's going on here. I'm trying to put a little error handling around my application. If it fails, I need it to send out an alarm. But, depending on the statement, I get an error when trying to trap the error. For example, this works as expected: If Error? Fred: Try [ 1 / 0 ] [ Print Whatever! ] Whatever! As does this: If Error? Fred: Try [ 1 / 1 ] [ Print Whatever! ] == none This too: If Error? Fred: Try [ Print ] [ Print Whatever! ] Whatever! But this doesn't: If Error? Fred: Try [ Print Get a grip! ] [ Print Whatever! ] Get a grip! ** Script Error: Fred needs a value ** Near: If Error? Fred: Try [Print Get a grip!] This is confusing because why should I get an error on something that doesn't and shouldn't cause an error. This works, of course: If Error? Fred: Try [ x: 1 ] [ Print Whatever! ] == none And this: If Error? Fred: Try [ x: 1 / 0 ] [ Print Whatever! ] Whatever! And so do these: If Error? Fred: Try [ Do [ 1 / 0 ] ] [ Print Whatever! ] Whatever! If Error? Fred: Try [ Do [ 1 / 1 ] ] [ Print Whatever! ] == none What's perplexing about the previous two is that it is a Do statement that I am trying to execute and trap. Instead of functioning as above, it blows up and gives me the needs a value error. And curiously, not only does Print fail, but so does Write. And that is a function that I need error trapping on, if ever there was one. If Error? Fred: Try [ Write %Temp.txt Yup! ] [ Print Whatever! ] ** Script Error: Fred needs a value ** Near: If Error? Fred: Try [Write %Temp.txt Yup!] I've even tried disarming the error, but to no avail: If Error? Fred: Try [ Write %Temp.txt Yup! ] [ Print Whatever! ] Disarm Fred ** Script Error: Fred needs a value ** Near: If Error? Fred: Try [Write %Temp.txt Yup!] So what gives? Is this some subtle intricacy of the language, a bug, or my normal state of confusion? -- Sincerely, | Mud can make you prisoner, and the plains can bake Ed Dana| you dry. Snow can burn your eyes, but only people Software Developer | make you cry. 1Ghz Athlon Amiga | -- Lee Marvin, Paint Your Wagon. === http://OurWorld.CompuServe.com/Homepages/EDanaII === -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope!
Hi Jason, even Rebol expressions such as: try [print hello] or do [print hello] or () yield a Rebol value, which, is of type UNSET!. Check: type? try [print hello] ; == unset! or probe head insert [] try [print hello] ; == [unset] etc. The only trouble with a value of that type is, that you cannot use it in an expression like: a: () , which fires an error. OTOH, you can use UNSET! type value like this: set/any 'a () probe head insert [] () ; == [unset] type? () ; == unset! error? () ; == false unset? () ; == true etc. Generally spoken, if your expression can yield an UNSET! type value, you have to use (set/any 'a ...) instead of (a: ...). The trouble with this approach is, that in the former case you lose the typo protection you normally have. If no Rebol expression was allowed to yield an UNSET! type value, this problem wouldn't exist. - Original Message - From: Jason Cunliffe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 8:12 AM Subject: [REBOL] Re: Help me, Obi Reb Kenobi, you're my only hope! hmmm.. I also be glad if someone can explain this issue well Fred: Try [hello] == hello fred == hello Fred: Try [print hello] hello ** Script Error: Fred needs a value ** Near: Fred: Try [print hello] ? try USAGE: TRY block DESCRIPTION: Tries to DO a block and returns its value or an error. TRY is a native value. ARGUMENTS: block -- (Type: block) do [print hello] hello fred: do [print hello] hello ** Script Error: fred needs a value ** Near: fred: do [print hello] fred: do [hello] == hello Looks like REBOL is being very consistent. So RebGurus, how do you interpret returns its value in this context? Which Rebol statements have value? thanks ./Jason -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Fw: prime solution
Hi Anton, Anton Are you saying that you implemented the algorithm in rebol? If so, that's pretty clever. Anton. /Anton Hi Charles, thanks for the info. Using Rebol I found out, that it is unlikely that the algorithm will be faster than a brute force approach for numbers smaller than 706'044'139 (except for the powers). -L Not exactly. I tried to simulate only the While part of the algorithm. I don't know the Fast Fourier Multiplication the article mentioned (though a slower version can be implemented without it). Moreover, the algorithm looks impractical for Rebol - see the number mentioned - and that number is only a lower bound! A more realistic lower bound estimate is: 4,29e9. -L -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Fw: prime solution
Hi Charles, thanks for the info. Using Rebol I found out, that it is unlikely that the algorithm will be faster than a brute force approach for numbers smaller than 706'044'139 (except for the powers). -L - Original Message - From: Charles [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 11, 2002 12:23 AM Subject: [REBOL] Fw: prime solution An interesting little something my mother sent along to me. Figured there'd be a few people on this list interested in it. Prime solution wows the math world Scientists say algorithm offers 'foolproof' way to find primes http://www.cse.iitk.ac.in/news/primality.html ASSOCIATED PRESS NEW DELHI, Aug. 9 - Indian computer scientists say they have solved a mathematical problem that has eluded researchers for 2,200 years - and could be crucial in modern times in improving computer configurations. A THREE-MEMBER TEAM of scientists at the Indian Institute of Technology in the northern Indian city of Kanpur have devised a method that will make no mistake in quickly determining a prime number - those that are divisible only by themselves and 1. Prime numbers hold the key to solving many mathematical problems and play an important a role in cryptography. Scientists have long worked on ways to improve methods to identify a prime number. Greek mathematician Eratosthenes was the first to raise this problem around 200 B.C., when he offered one way of determining whether a number is prime. Computer scientists and mathematicians have since devised many faster ways to solve the problem, but all such methods carry a small risk of error. Some methods occasionally fail to detect a prime number, while others may select a nonprime number. Our algorithm is deterministic; it has no chance of committing any error, said Manindra Agrawal, the principal author of the formula. An algorithm is a set of instructions for solving a specific mathematical problem in a limited number of steps. Agrawal and his two associates - Neeraj Kayal and Nitin Saxena - have written a paper detailing the formula, which was posted on their department's Web site Sunday. Copies of the paper were also dispatched to leading computer scientists and mathematicians across the world. We have received several responses. All of them have expressed satisfaction with the new algorithm, Agrawal told The Associated Press by telephone. No one has doubted our claim. The new algorithm will have no immediate applications, however, because current methods used in computers are faster. We have used more steps than the current methods in use, explains Agrawal. Our first objective was to find a method that is foolproof. Now, I am sure other researchers, or may be some of us, will start asking how can the number of steps be cut down and make the computation faster. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: REBOL/Core 2.5.3 Released
Hi Romano, it looks that my testing wasn't thorough enough. Sorry for misinforming. You should send it to feedback. Romano ... It seems that the function is referenced two times through the variable name: the first to collect the argument number, the second to collect the body code. --- Ciao Romano /Romano Yes, you are right! The only problem is, that this isn't the proper way how to do it (IMO!). The variable should be examined just once to get the function. Any subsequent usage of the variable for the same purpose is an unnecessary hazard. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.