Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

if and parens

 [1/12] from: laurent:giroud:libertysurf at: 5-Oct-2002 23:30


Hi everyone again, I have a little "problem" that I encounter quite frequently with 'if : in certain cases I need to use parens to make sure that the expression tested is correctly evaluated. While I understand that in some cases parens may be necessary to avoid ambiguities, in the following example I fail to see why they are needed : this simply prints the list of files in the current folder and works quite fine :
>> foreach elt read %. [if (get in info? to-file elt 'type) = 'file [print elt]]
... but when removing the parens we get :
>> foreach elt read %. [if get in info? to-file elt 'type = 'file [print elt]]
** Script Error: in expected word argument of type: word ** Where: halt-view ** Near: if get in info? to-file The code looks quite unambiguous to me since all the part beetween the 'if and the "=" character evaluates without problem if isolated :
>> elt: %afile ; "afile" being an existing file >> get in info? to-file elt 'type
== file Would anyone have an explanation ? Regards, Laurent -- Laurent Giroud

 [2/12] from: al:bri:xtra at: 6-Oct-2002 11:21


> While I understand that in some cases parens may be necessary to avoid
ambiguities, in the following example I fail to see why they are needed :
> this simply prints the list of files in the current folder and works quite
fine :
> >> foreach elt read %. [if (get in info? to-file elt 'type) = 'file [print
elt]]
> but when removing the parens we get : > > >> foreach elt read %. [if get in info? to-file elt 'type = 'file [print
elt]]
> ** Script Error: in expected word argument of type: word > ** Where: halt-view > ** Near: if get in info? to-file
That's because the '= is infix; it grabs the left and right arguments, as it were. Try this instead: foreach elt read %. [if 'file = get in info? to-file elt 'type [print elt]] Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [3/12] from: carl:cybercraft at: 6-Oct-2002 11:13


On 06-Oct-02, Laurent Giroud wrote:
> Hi everyone again, > I have a little "problem" that I encounter quite frequently with 'if
<<quoted lines omitted: 21>>
> == file > Would anyone have an explanation ?
Others can have a go at the explaination, but as you say, the problem (if it is one) can be solved in may cases by swapping the operator's values around. ie... foreach elt read %. [if 'file = get in info? to-file elt 'type [print elt]] -- Carl Read

 [4/12] from: al:bri:xtra at: 6-Oct-2002 11:59


Andrew wrote:
> Try this instead: > > foreach elt read %. [if 'file = get in info? to-file elt 'type [print
elt]] And this is far more simpler: foreach File read %. [if #"/" <> last File [print File]] Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [5/12] from: joel:neely:fedex at: 5-Oct-2002 20:10


Hi, Laurent, Infix (operators) has higher precedence than prefix (function evaluation), so the expression if get in info? to-file elt 'type = 'file [print elt] is actually treated by REBOL in the same order as if parenthesized as if get (in (info? (to-file elt)) ('type = 'file)) [print elt] that is, the IN is applied to the INFO? object, but the second argument is the LOGICAL! value FALSE, which, as the error message stated, is not a WORD! value. Since you just want to exclude subdirectories from the list of contents of the current directory, you could write foreach elt read %. [if not dir? elt [print elt]] instead. -jn- Laurent Giroud wrote:
> Hi everyone again, > > I have a little "problem" that I encounter quite frequently with 'if
...
> this simply prints the list of files in the current folder and works > quite fine : > > >> foreach elt read %. [if (get in info? to-file elt 'type) = 'file [print elt]]
...
-- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [6/12] from: jason:cunliffe:verizon at: 5-Oct-2002 23:10


Joel Neely wrote:
> Since you just want to exclude subdirectories from the list of > contents of the current directory, you could write > > foreach elt read %. [if not dir? elt [print elt]] > > instead.
Andrew Martin wrote:
> And this is far more simpler: > foreach File read %. [if #"/" <> last File [print File]]
Both are nioe, but as Andrew pointed out recently, using the trailing "/" method to determine directories overcomes a bug in 'dir? ./Jason

 [7/12] from: brett:codeconscious at: 6-Oct-2002 14:18


I'm not sure about any bug, but... info? which dir? is based on, queries the target system for information. For your local file system (hard disk) it is probably not much of an issue. However if your target happens to be FTP://..... then you can avoid a network access by using Andrew's character based test. Regards, Brett.

 [8/12] from: g:santilli:tiscalinet:it at: 6-Oct-2002 12:11


Hi Laurent, On Saturday, October 5, 2002, 11:30:50 PM, you wrote: LG> Would anyone have an explanation ? The problem is that infix operators are almost an hack in REBOL. If you write your code as: if 'file = get in info? to-file elt 'type [print elt] it doesn't need parens; also, you never need them if you use prefix operators, such as writing: if equal? get in info? to-file elt 'type 'file [print elt] The problem is that when you write: get in info? to-file elt 'type = 'file REBOL interprets it as: get in info? to-file elt ('type = 'file) HTH, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [9/12] from: laurent:giroud:libertysurf at: 6-Oct-2002 12:52


Hi everyone, Sunday, October 6, 2002, 6:18:12 AM, Brett Handley wrote :
> I'm not sure about any bug, but... > info? which dir? is based on, queries the target system for information. > For your local file system (hard disk) it is probably not much of an issue. > However if your target > happens to be FTP://..... then you can avoid a network access by using > Andrew's character based test.
thank you for all these answers, I got explanations and simpler code, what else could I ask for ? ;) You all pointed that my code could be simplified further, and reading the list it seems to be quite common to have working code but which is much heavier than needed. There is a page in Rebol Zine about Carl S. "mental reduction" tricks, I guess I need to practice them a bit more ;) Regards, Laurent

 [10/12] from: greggirwin::mindspring::com at: 7-Oct-2002 10:16


Hi Laurent, << There is a page in Rebol Zine about Carl S. "mental reduction" tricks, I guess I need to practice them a bit more ;) >> I've been using REBOL for just over a year now, and I think, at least for me, those kinds of insights come more often as time goes by, but they're also easy to miss, even for the experts, until you really let go of old habits, which I haven't been able to do completely yet. If I take the time to go back and refactor bits of code, they often get reduced pretty well. I also learn a lot by playing around with things when debugging. Sometimes, things you think can't possibly work (because they're too simple and obvious) are exactly the right thing to do. The more code I remove, the better things seem to work. :) --Gregg

 [11/12] from: al:bri:xtra at: 8-Oct-2002 16:23


Gregg wrote:
> The more code I remove, the better things seem to work. :)
I agree. I've found exactly the same as well. Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [12/12] from: brett:codeconscious at: 9-Oct-2002 9:34


> I'm not sure about any bug, but... > > info? which dir? is based on, queries the target system for information. > > For your local file system (hard disk) it is probably not much of an
issue. I take this back. It is not much of an issue to use dir? on your local file system if you have a low number of files. Checking the #"/" in the name is *much* faster. See "Reading directories faster" thread. Regards, Brett.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted