print(true and true) #=> the parenthesis issue

Discussion in 'Ruby' started by hakunin, Jun 17, 2008.

  1. hakunin

    hakunin Guest

    The parenthesis have been discussed before, but maybe this is another
    angle. In a nutshell:

    print(true and true) # => throws the following:

    SyntaxError: compile error
    (irb):14: syntax error, unexpected kAND, expecting ')'
    print(true and true)
    ^
    from (irb):14

    print (true and true) # => works. (notice the space)

    It looks obvious that the only parenthesis around the method args are
    containing the expression to be evaluated, so why would this cause
    ambiguity? Especially strange that the incorrect way - with the space
    - works as expected. Is there any fix in the works? Anything done
    about this?

    Thanks!
     
    hakunin, Jun 17, 2008
    #1
    1. Advertising

  2. hakunin wrote:
    > The parenthesis have been discussed before, but maybe this is another
    > angle. In a nutshell:
    >
    > print(true and true) # => throws the following:
    >
    > SyntaxError: compile error
    > (irb):14: syntax error, unexpected kAND, expecting ')'
    > print(true and true)
    > ^
    > from (irb):14
    >
    > print (true and true) # => works. (notice the space)
    >
    > It looks obvious that the only parenthesis around the method args are
    > containing the expression to be evaluated, so why would this cause
    > ambiguity? Especially strange that the incorrect way - with the space
    > - works as expected. Is there any fix in the works? Anything done
    > about this?
    >
    > Thanks!
    >
    >


    print (true and true) is not incorrect, it is just using parentheses for
    a different purpose.

    What you are seeing is just a precedence issue, because "and" and "or"
    have very low precedence.

    Compare:

    print(true && true)
    print(true or true)
    print(true || true)
    print((true and true))
    print((true or true))

    Maybe you already knew that, though?

    -Justin
     
    Justin Collins, Jun 17, 2008
    #2
    1. Advertising

  3. hakunin

    hakunin Guest

    On Jun 16, 10:48 pm, Justin Collins <> wrote:
    > hakunin wrote:
    > > The parenthesis have been discussed before, but maybe this is another
    > > angle. In a nutshell:

    >
    > > print(true and true) # => throws the following:

    >
    > > SyntaxError: compile error
    > > (irb):14: syntax error, unexpected kAND, expecting ')'
    > > print(true and true)
    > >               ^
    > >    from (irb):14

    >
    > > print (true and true) # => works. (notice the space)

    >
    > > It looks obvious that the only parenthesis around the method args are
    > > containing the expression to be evaluated, so why would this cause
    > > ambiguity?  Especially strange that the incorrect way - with the space
    > > - works as expected.  Is there any fix in the works? Anything done
    > > about this?

    >
    > > Thanks!

    >
    > print (true and true) is not incorrect, it is just using parentheses for
    > a different purpose.
    >
    > What you are seeing is just a precedence issue, because "and" and "or"
    > have very low precedence.
    >
    > Compare:
    >
    > print(true && true)
    > print(true or true)
    > print(true || true)
    > print((true and true))
    > print((true or true))
    >
    > Maybe you already knew that, though?
    >
    > -Justin


    That makes sense, and yes, that I realized. In print() parenthesis are
    enclosing the args, whereas in print () parenthesis are affecting
    precedence of passed-in expression. However, from the usability
    perspective, isn't it against some basic nature laws to leave it like
    this? I would understand if print(true and return) was to be made
    possible, although it looks quite ugly. In this case - Ruby says "i
    don't need it, but I won't give it to you either!" - an error occurs,
    but no reason provided for this to be restricted. If enclosed
    arguments can only either be replaced with args list, or with a high
    precedence expression (otherwise error), then why not allow arg-
    enclosing parenthesis to behave like precedence modifiers as well, so
    that expression inside them plays first? Overall it seems to be only
    better for the elegance of code, and wouldn't hurt anyone. Unless I'm
    missing the rest of the iceberg.
     
    hakunin, Jun 17, 2008
    #3
  4. On 17.06.2008 06:08, hakunin wrote:
    > On Jun 16, 10:48 pm, Justin Collins <> wrote:


    >> print(true && true)
    >> print(true or true)
    >> print(true || true)
    >> print((true and true))
    >> print((true or true))


    > That makes sense, and yes, that I realized. In print() parenthesis are
    > enclosing the args, whereas in print () parenthesis are affecting
    > precedence of passed-in expression. However, from the usability
    > perspective, isn't it against some basic nature laws to leave it like
    > this?


    There are no nature laws in IT.

    > I would understand if print(true and return) was to be made
    > possible, although it looks quite ugly. In this case - Ruby says "i
    > don't need it, but I won't give it to you either!" - an error occurs,
    > but no reason provided for this to be restricted. If enclosed
    > arguments can only either be replaced with args list, or with a high
    > precedence expression (otherwise error), then why not allow arg-
    > enclosing parenthesis to behave like precedence modifiers as well, so
    > that expression inside them plays first? Overall it seems to be only
    > better for the elegance of code, and wouldn't hurt anyone. Unless I'm
    > missing the rest of the iceberg.


    Two remarks:

    1. I was surprised of the error as well. But

    2. I cannot remember someone complaining about this. So, although my
    memory may be failing me, for most it does not seem to be an issue.

    Maybe it's simply a technical limitation of the parser.

    Kind regards

    robert
     
    Robert Klemme, Jun 17, 2008
    #4
  5. hakunin

    Tom Cloyd Guest

    Robert Klemme wrote:

    [snip]
    > That makes sense, and yes, that I realized. In print() parenthesis are
    >> enclosing the args, whereas in print () parenthesis are affecting
    >> precedence of passed-in expression. However, from the usability
    >> perspective, isn't it against some basic nature laws to leave it like
    >> this?

    >
    > There are no nature laws in IT.
    >

    Absolute nonsense.

    IT is not an entity unto itself. It is an artifact of the human brain.
    Furthermore, it must be USED by the human brain, else it is the
    proverbial tree falling in the forest when no one's around, and thus has
    no consequence. AND the human brain certainly does have laws, if by
    "laws" we mean something like "statements of pattern possessing a high
    probability of being true" (my definition). Philosophical idealists will
    not be satisfied by that, but such children should be ignored. Real men
    live with probability, as a fact of life. (Are we having fun yet?)
    So...natural law of IT exist, because all of IT must pass through the
    filter of the human brain.

    From that point reasonable point of view, we could well have the
    usability problem mentioned. I, for one, find this parenthesis problem
    obscure in the extreme. What happened to the principal of least
    surprise? Yikes.

    Keep it simple, when at all possible.

    t.

    --

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Tom Cloyd, MS MA, LMHC
    Private practice Psychotherapist
    Bellingham, Washington, U.S.A: (360) 920-1226
    << >> (email)
    << TomCloyd.com >> (website & psychotherapy weblog)
    << sleightmind.wordpress.com >> (mental health issues weblog)
    << directpathdesign.com >> (web site design & consultation)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Tom Cloyd, Jun 17, 2008
    #5
  6. 2008/6/17 Tom Cloyd <>:
    > Robert Klemme wrote:
    >
    > [snip]
    >>
    >> That makes sense, and yes, that I realized. In print() parenthesis are
    >>>
    >>> enclosing the args, whereas in print () parenthesis are affecting
    >>> precedence of passed-in expression. However, from the usability
    >>> perspective, isn't it against some basic nature laws to leave it like
    >>> this?

    >>
    >> There are no nature laws in IT.
    >>

    > Absolute nonsense.


    Thanks for your kind reply.

    > IT is not an entity unto itself. It is an artifact of the human brain.
    > Furthermore, it must be USED by the human brain, else it is the proverbial
    > tree falling in the forest when no one's around, and thus has no
    > consequence. AND the human brain certainly does have laws, if by "laws" we
    > mean something like "statements of pattern possessing a high probability of
    > being true" (my definition). Philosophical idealists will not be satisfied
    > by that, but such children should be ignored. Real men live with
    > probability, as a fact of life. (Are we having fun yet?) So...natural law of
    > IT exist, because all of IT must pass through the filter of the human brain.


    With that argument the statement "there are nature laws in X" becomes
    a tautology because they influence every aspect of reality. I prefer
    to keep the distinction because this allows me to make more
    interesting (i.e. non tautological) statements.

    The point here is that all formalisms in IT are human invented and
    there is certainly nothing like a natural law that will demand that
    "f(x and y)" is a valid expression.

    > From that point reasonable point of view, we could well have the usability
    > problem mentioned. I, for one, find this parenthesis problem obscure in the
    > extreme. What happened to the principal of least surprise? Yikes.


    Did it every surprise you before this thread? If not, I don't see any
    issue with POLS.

    > Keep it simple, when at all possible.


    Exactly. Having a feature that makes the language simple which is not
    used by anyone (or only rarely) does not justify complicating the
    parser more than necessary.

    Regards

    robert

    --
    use.inject do |as, often| as.you_can - without end
     
    Robert Klemme, Jun 17, 2008
    #6
  7. hakunin

    Michael Ulm Guest

    Justin Collins wrote:
    > hakunin wrote:
    >> The parenthesis have been discussed before, but maybe this is another
    >> angle. In a nutshell:
    >>
    >> print(true and true) # => throws the following:
    >>
    >> SyntaxError: compile error
    >> (irb):14: syntax error, unexpected kAND, expecting ')'
    >> print(true and true)
    >> ^
    >> from (irb):14
    >>
    >> print (true and true) # => works. (notice the space)
    >>
    >> It looks obvious that the only parenthesis around the method args are
    >> containing the expression to be evaluated, so why would this cause
    >> ambiguity? Especially strange that the incorrect way - with the space
    >> - works as expected. Is there any fix in the works? Anything done
    >> about this?
    >>
    >> Thanks!
    >>
    >>

    >
    > print (true and true) is not incorrect, it is just using parentheses for
    > a different purpose.
    >
    > What you are seeing is just a precedence issue, because "and" and "or"
    > have very low precedence.
    >
    > Compare:
    >
    > print(true && true)
    > print(true or true)
    > print(true || true)
    > print((true and true))
    > print((true or true))
    >
    > Maybe you already knew that, though?
    >


    This one really puzzles me. I know of the operator precedence
    hierarchy in Ruby, but this doesn't seem to help me figure
    out why the parser gets confused here. Could someone give
    some insights in the thought process of the parser when it
    encounters "print(true and true)" ?

    Thanks,

    Michael
     
    Michael Ulm, Jun 17, 2008
    #7
  8. On Tue, Jun 17, 2008 at 9:44 AM, Michael Ulm
    <> wrote:
    > Justin Collins wrote:
    >>
    >> hakunin wrote:
    >>>
    >>> The parenthesis have been discussed before, but maybe this is another
    >>> angle. In a nutshell:
    >>>
    >>> print(true and true) # => throws the following:
    >>>
    >>> SyntaxError: compile error
    >>> (irb):14: syntax error, unexpected kAND, expecting ')'
    >>> print(true and true)
    >>> ^
    >>> from (irb):14
    >>>
    >>> print (true and true) # => works. (notice the space)
    >>>
    >>> It looks obvious that the only parenthesis around the method args are
    >>> containing the expression to be evaluated, so why would this cause
    >>> ambiguity? Especially strange that the incorrect way - with the space
    >>> - works as expected. Is there any fix in the works? Anything done
    >>> about this?
    >>>
    >>> Thanks!
    >>>
    >>>

    >>
    >> print (true and true) is not incorrect, it is just using parentheses for a
    >> different purpose.
    >>
    >> What you are seeing is just a precedence issue, because "and" and "or"
    >> have very low precedence.
    >>
    >> Compare:
    >>
    >> print(true && true)
    >> print(true or true)
    >> print(true || true)
    >> print((true and true))
    >> print((true or true))
    >>
    >> Maybe you already knew that, though?
    >>

    >
    > This one really puzzles me. I know of the operator precedence
    > hierarchy in Ruby, but this doesn't seem to help me figure
    > out why the parser gets confused here. Could someone give
    > some insights in the thought process of the parser when it
    > encounters "print(true and true)" ?


    1. print (true and true)
    2. print(true and true)

    In the one case the parser first evaluates "true and true" for a
    boolean result (true) and
    then passes that to print. In the second case the parser seems to be expecting
    something like: print(true) and print "hello"

    It seems wrong to me too, since I'd expect the brackets to remove
    "print" from the
    equation until the bracketed section is evaluated. Perhaps someone can show some
    obscure syntax that requires this behavior.


    Les
     
    Leslie Viljoen, Jun 17, 2008
    #8
  9. hakunin

    Tom Cloyd Guest

    Robert Klemme wrote:
    > 2008/6/17 Tom Cloyd <>:
    >
    >> Robert Klemme wrote:
    >>
    >> [snip]
    >>
    >>> That makes sense, and yes, that I realized. In print() parenthesis are
    >>>
    >>>> enclosing the args, whereas in print () parenthesis are affecting
    >>>> precedence of passed-in expression. However, from the usability
    >>>> perspective, isn't it against some basic nature laws to leave it like
    >>>> this?
    >>>>
    >>> There are no nature laws in IT.
    >>>
    >>>

    >> Absolute nonsense.
    >>

    >
    > Thanks for your kind reply.
    >

    I was, of course, referring to your proposition, and not to you. My
    evaluation is supported (I would hope) by the rest of my statement -
    again referring to ideas, not person. The "Absolute" is, of course,
    hyperbole, and also an attempt at humorous irony, since the argument
    which followed I then made was an appeal to the relative world of real
    probability, in which absolutes ("laws") are not likely to exist.
    >
    >> IT is not an entity unto itself. It is an artifact of the human brain.
    >> Furthermore, it must be USED by the human brain, else it is the proverbial
    >> tree falling in the forest when no one's around, and thus has no
    >> consequence. AND the human brain certainly does have laws, if by "laws" we
    >> mean something like "statements of pattern possessing a high probability of
    >> being true" (my definition). Philosophical idealists will not be satisfied
    >> by that, but such children should be ignored. Real men live with
    >> probability, as a fact of life. (Are we having fun yet?) So...natural law of
    >> IT exist, because all of IT must pass through the filter of the human brain.
    >>

    >
    > With that argument the statement "there are nature laws in X" becomes
    > a tautology because they influence every aspect of reality.

    Law of IT need not have relevance outside of that domain. There IS no
    necessary "influence".
    > I prefer
    > to keep the distinction because this allows me to make more
    > interesting (i.e. non tautological) statements.
    >

    Clever, but...um...unfortunately wrong, if you reread my stipulated
    definition of "law". It's critical.

    To put it differently: the brain behaves in patterned ways, which are
    describable by stochastic statements, the strongest of which approximate
    what in philosophically (and scientifically) simpler times were referred
    to as "laws". If this non-chaotic behavior be granted, and if you grant
    that IT must work in the context of this same brain, else it be
    irrelevant, then IT must also be non-chaotic, which is to say 'something
    akin to law-like' - not inherently but functionally. Chaotic IT
    certainly could (and in some quarters likely does) exist. But USEFUL IT
    cannot be structured this way, because, as I said, it must pass through
    the filter of the brain.

    I think you are having trouble abandoning the idealist view of law. I
    certainly grasp that concept, but it seems useful to me only in study of
    the history of philosophy. Two words: quatum mechanics (which I believe
    IS supposed to "influence" all of nature). I rest my case.
    > The point here is that all formalisms in IT are human invented and
    > there is certainly nothing like a natural law that will demand that
    > "f(x and y)" is a valid expression.
    >
    >
    >> From that point reasonable point of view, we could well have the usability
    >> problem mentioned. I, for one, find this parenthesis problem obscure in the
    >> extreme. What happened to the principal of least surprise? Yikes.
    >>

    >
    > Did it every surprise you before this thread? If not, I don't see any
    > issue with POLS.
    >

    So, the falling tree in the forest makes no noise until I hear it? OK.
    But, pragmatically, if this sort of syntactic nonsense (the parenthesis
    thing - not the tree) exists in this case in Ruby, I become fearful
    about where else it might exist. Simply a practical concern. Otherwise,
    it is, as you point out, likely to be of so little import as to deserve
    no further attention.
    >
    >> Keep it simple, when at all possible.
    >>

    >
    > Exactly. Having a feature that makes the language simple which is not
    > used by anyone (or only rarely) does not justify complicating the
    > parser more than necessary.
    >

    A pragmatic question, and you may well be right.

    Let's hope so. Of course, the next time my Ruby program fails (and I'm
    good at that), I WILL have to wonder if I'm hearing a distant tree falling.

    t.

    --

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Tom Cloyd, MS MA, LMHC
    Private practice Psychotherapist
    Bellingham, Washington, U.S.A: (360) 920-1226
    << >> (email)
    << TomCloyd.com >> (website & psychotherapy weblog)
    << sleightmind.wordpress.com >> (mental health issues weblog)
    << directpathdesign.com >> (web site design & consultation)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Tom Cloyd, Jun 17, 2008
    #9
  10. hakunin

    Calamitas Guest

    On Tue, Jun 17, 2008 at 9:44 AM, Michael Ulm
    <> wrote:
    > This one really puzzles me. I know of the operator precedence
    > hierarchy in Ruby, but this doesn't seem to help me figure
    > out why the parser gets confused here. Could someone give
    > some insights in the thought process of the parser when it
    > encounters "print(true and true)" ?


    The parser doesn't get confused; this is in there totally
    deliberately. I don't have Ruby's parser handy here, but I think Ruby
    only allows expressions as parameter if they can go on the right hand
    side of an assignment. If you want "true and true" on the right hand
    side of an assignment, you need parentheses as well, because otherwise
    "a = true and true" is interpreted as "(a = true) and true". Other
    things that don't go as arguments unless parenthesized: semicolons,
    control statements, statement modifiers, etc. Everything that operates
    on statements really.

    To me, "or" and "and" are not equivalents of "||" and "&&"; the
    difference in precedence is a definite hint here. While "||" and "&&"
    work on expressions, "or" and "and" work on statements. If you don't
    use them as "statement operators", you're bound to run into trouble
    and you'll have to put extra parentheses all over.

    Peter
     
    Calamitas, Jun 17, 2008
    #10
  11. hakunin

    Peña, Botp Guest

    From: Robert Klemme [mailto:]=20
    #..
    # Maybe it's simply a technical limitation of the parser.

    that is my hunch too.

    since ruby 1.8.6, i have made it a point to put the parens close to the =
    method name since i always dislike the msg "warning: don't put space =
    before argument parentheses". But yet this "and/or" behaviour seems very =
    counter to ruby, for me.

    i encountered something similar like this when i tried creating my own =
    partition/grouping method. the issue was on accessing/debugging a hash, =
    or something like,

    h=3D{}
    #=3D> {}

    h[true] =3D true
    #=3D> true

    h[false] =3D false
    #=3D> false

    h[true]
    #=3D> true

    h[true and false]
    SyntaxError: compile error
    (irb):37: syntax error, unexpected kAND, expecting ']'
    h[true and false]
    ^

    h [true or false]
    SyntaxError: compile error
    (irb):41: syntax error, unexpected kOR, expecting ']'
    h [true or false]
    ^


    h [true if 1=3D=3D1]
    SyntaxError: compile error
    (irb):56: syntax error, unexpected kIF_MOD, expecting ']'
    h [true if 1=3D=3D1]
    ^

    i got the hint when i used a var just to make sure

    x =3D (true and false)
    #=3D> false

    x =3D (false and true)
    #=3D> false

    h[x]
    #=3D> false

    so,

    h [(true and false)]
    #=3D> false

    h [(true or false)]
    #=3D> true

    h [(true if 1=3D=3D1)]
    #=3D> true

    note that the ff does not err though

    h [if 1=3D=3D1 and 2=3D=3D2 then true else false end]
    #=3D> true

    h [if 1=3D=3D1 or 2=3D=3D2 then true else false end]
    #=3D> true


    generally, i personally think this is a parser bug (but who am i to say =
    that, and i haven't even read the whole ruby manual yet :-(.. sad since =
    ruby1.9 behaviour is same.

    nonetheless, i made my own C/LISP-like motto just to avoid this type of =
    nasty errors/msgs, and that is: "when in doubt, ENCLOSE expressions in =
    parens" --wc emphasize the use of parens more. Rubyish or not, POLS or =
    not (C/LISP-like or not ;), it always works, --for me.=20

    kind regards -botp
     
    Peña, Botp, Jun 17, 2008
    #11
  12. hakunin

    Marc Heiler Guest

    Dear Tom Cloyd,

    "What happened to the principal of least surprise? Yikes.

    Keep it simple, when at all possible."

    Your suggestive (and false) remarks are irritating at best. There is
    only one principle of least surprise, if ever, and this is by the one
    who designs the language. There is no GENERAL CONSENSUS applicable to a
    "principle of least surprise" because different expectations, patterns,
    experience will yield to different perceptions of any given situation.

    The KISS strategy is only one more strategy in a pool of different
    strategies.

    I have seen it used in the game Wesnoth and what this basically means it
    that they slavishly reject features that "would make the game too
    complicated".
    To the extreme that, when one suggests simplification to a game
    interface, a similar reasoning is used to reject it ("would make the
    code too complicated")

    Whether this is intentional or not, it is their decision, but it would
    not be the ONLY available strategy to create/solve something.

    I'd rather not stick to ANYONE's "keep it simple" mantra, definitely not
    when multiple people jump on it and pick it up to shout something is a
    bug when it is not what they expect.

    If anyone wants to know my principle of leat surprise, then I'd never
    have a parser that makes a difference between && and "and" or similar.
    But I am no language designer.
    --
    Posted via http://www.ruby-forum.com/.
     
    Marc Heiler, Jun 17, 2008
    #12
  13. hakunin

    Tom Cloyd Guest

    Marc Heiler wrote:
    > Dear Tom Cloyd,
    >
    > "What happened to the principal of least surprise? Yikes.
    >
    > Keep it simple, when at all possible."
    >
    > Your suggestive (and false) remarks are irritating at best.

    Interest assertions...or rather they might be if there were an argument
    accompanying them. Name calling is easy. My argument(s) may be false,
    but at least I made an effort. If you find them false, point out the
    error. As for the "irritating" part - I'm supposing that that might have
    to do with a perception that to attempt this might take time and effort.
    But...I'm speculating.
    > There is
    > only one principle of least surprise, if ever, and this is by the one
    > who designs the language.

    My questions stands. You do not address it. And...I believe there is
    more than one hand stirring Ruby's pot, and that is common knowledge.
    > There is no GENERAL CONSENSUS applicable to a
    > "principle of least surprise" because different expectations, patterns,
    > experience will yield to different perceptions of any given situation.
    >

    Certainly. No issue here.
    > The KISS strategy is only one more strategy in a pool of different
    > strategies.
    >

    Obviously, but what's your point? The "principle of parsimony" (often
    attributed to William of Occam) is well established and accepted in
    philosophy, the law, and in argumentation in general. It's NOT simply
    one among many, to paraphrase you. It's fundamental - to good reason
    and, one could assert (and I do) to good design in general. And to
    aesthetics.

    The point of parsimony, aside from the avoidance or the error which tend
    to propagate as a function of complexity, would seem to have to do with
    the issue of usability which the original poster brought up. That which
    is simple is generally more understandable and thus more useful. Seems
    like a truly key idea, to me.
    > I have seen it used in the game Wesnoth and what this basically means it
    > that they slavishly reject features that "would make the game too
    > complicated".
    > To the extreme that, when one suggests simplification to a game
    > interface, a similar reasoning is used to reject it ("would make the
    > code too complicated")
    >

    A good tool, poorly applied, is none the worse for it.
    > Whether this is intentional or not, it is their decision, but it would
    > not be the ONLY available strategy to create/solve something.
    >

    Who made THAT silly assertion? Not me.
    > I'd rather not stick to ANYONE's "keep it simple" mantra, definitely not
    > when multiple people jump on it and pick it up to shout something is a
    > bug when it is not what they expect.
    >
    > If anyone wants to know my principle of leat surprise, then I'd never
    > have a parser that makes a difference between && and "and" or similar.
    > But I am no language designer.
    >

    To repeat (and I do so in part because you did not address these
    matters) - I agreed that the particular syntactic issue at hand appears
    to be trivial to most of us most of the time, and also that its
    surprising nature leads me, at least, to wonder about other sorts of
    subtle, hidden issues which may be causing trouble in Ruby. (And give me
    credit for suggesting that such trouble as I encounter is far more
    likely to be self-caused than language caused.). It's reasonable to
    suppose such hidden issues
    exist, though probably not reasonable to worry too much about them.
    They can be fun to talk about however.

    t.

    --

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Tom Cloyd, MS MA, LMHC
    Private practice Psychotherapist
    Bellingham, Washington, U.S.A: (360) 920-1226
    << >> (email)
    << TomCloyd.com >> (website & psychotherapy weblog)
    << sleightmind.wordpress.com >> (mental health issues weblog)
    << directpathdesign.com >> (web site design & consultation)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Tom Cloyd, Jun 17, 2008
    #13
  14. hakunin

    Todd Benson Guest

    On Tue, Jun 17, 2008 at 2:09 AM, Tom Cloyd <> wrote:
    > Robert Klemme wrote:
    >> There are no nature laws in IT.
    >>

    > Absolute nonsense.
    >
    > IT is not an entity unto itself. It is an artifact of the human brain.


    <snip/>

    > From that point reasonable point of view, we could well have the usability
    > problem mentioned. I, for one, find this parenthesis problem obscure in the
    > extreme. What happened to the principal of least surprise? Yikes.
    >
    > Keep it simple, when at all possible.


    You should study linguistics. Then, you might have an idea of how
    hard it is to KISS.

    Todd
     
    Todd Benson, Jun 17, 2008
    #14
  15. hakunin

    hakunin Guest

    > Having a feature that makes the language simple which is not
    > used by anyone (or only rarely) does not justify complicating the
    > parser more than necessary.


    I wouldn't say that this is unused. I came across this issue when
    trying to write an ACL method, looking something like this:
    only( a :guest and not the @user ) do end # => 'a' and 'the' are both
    methods returning boolean based on supplied arg

    Am I unable to have methods which rely on the result of a boolean
    expression, without having to resort to double parenthesis, or
    remembering to put the subtle extra space? That surprises me very
    much, and definitely prevents me from using it. It's a source of hard-
    to-find bugs.
     
    hakunin, Jun 17, 2008
    #15
  16. hakunin

    hakunin Guest

    On Jun 17, 8:42 am, hakunin <> wrote:
    > > Having a feature that makes the language simple which is not
    > > used by anyone (or only rarely) does not justify complicating the
    > > parser more than necessary.

    >
    > I wouldn't say that this is unused.  I came across this issue when
    > trying to write an ACL method, looking something like this:
    > only( a :guest and not the @user ) do end # => 'a' and 'the' are both
    > methods returning boolean based on supplied arg
    >
    > Am I unable to have methods which rely on the result of a boolean
    > expression, without having to resort to double parenthesis, or
    > remembering to put the subtle extra space? That surprises me very
    > much, and definitely prevents me from using it. It's a source of hard-
    > to-find bugs.



    Certainly I could do only( a:)guest) && !the(@user) ) but you can see
    what this does to a nice convenient acl method.
     
    hakunin, Jun 17, 2008
    #16
  17. On 17 Jun., 14:42, hakunin <> wrote:
    > > Having a feature that makes the language simple which is not
    > > used by anyone (or only rarely) does not justify complicating the
    > > parser more than necessary.

    >
    > I wouldn't say that this is unused. I came across this issue when
    > trying to write an ACL method, looking something like this:
    > only( a :guest and not the @user ) do end # => 'a' and 'the' are both
    > methods returning boolean based on supplied arg


    Not sure how this can work since obviously you want to evaluate the
    ACL on access time and not when you define it. Why don't you use a
    block?

    only { a :guest and not the @user }

    Cheers

    robert
     
    Robert Klemme, Jun 17, 2008
    #17
  18. hakunin

    Tom Cloyd Guest

    Todd Benson wrote:
    > On Tue, Jun 17, 2008 at 2:09 AM, Tom Cloyd <> wrote:
    >
    >> Robert Klemme wrote:
    >>
    >>> There are no nature laws in IT.
    >>>
    >>>

    >> Absolute nonsense.
    >>
    >> IT is not an entity unto itself. It is an artifact of the human brain.
    >>

    >
    > <snip/>
    >
    >
    >> From that point reasonable point of view, we could well have the usability
    >> problem mentioned. I, for one, find this parenthesis problem obscure in the
    >> extreme. What happened to the principal of least surprise? Yikes.
    >>
    >> Keep it simple, when at all possible.
    >>

    >
    > You should study linguistics. Then, you might have an idea of how
    > hard it is to KISS.
    >
    > Todd
    >
    >
    >

    Actually, I have, at the graduate level...and I do. It's a principle
    (got the spelling right this time, I hope). One aims at it, and hope to
    get close. I suggest that in this case Ruby may not have gotten close
    enough. That's all.

    t.

    --

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Tom Cloyd, MS MA, LMHC
    Private practice Psychotherapist
    Bellingham, Washington, U.S.A: (360) 920-1226
    << >> (email)
    << TomCloyd.com >> (website & psychotherapy weblog)
    << sleightmind.wordpress.com >> (mental health issues weblog)
    << directpathdesign.com >> (web site design & consultation)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Tom Cloyd, Jun 17, 2008
    #18
  19. hakunin

    hakunin Guest

    On Jun 17, 8:52 am, Robert Klemme <> wrote:
    > On 17 Jun., 14:42, hakunin <> wrote:
    >
    > > > Having a feature that makes the language simple which is not
    > > > used by anyone (or only rarely) does not justify complicating the
    > > > parser more than necessary.

    >
    > > I wouldn't say that this is unused.  I came across this issue when
    > > trying to write an ACL method, looking something like this:
    > > only( a :guest and not the @user ) do end # => 'a' and 'the' are both
    > > methods returning boolean based on supplied arg

    >
    > Not sure how this can work since obviously you want to evaluate the
    > ACL on access time and not when you define it.  Why don't you use a
    > block?
    >
    > only { a :guest and not the @user }
    >
    > Cheers
    >
    > robert


    I don't want to go too off-topic, as I just wanted to show a usage
    example. To be quick - I'm doing web dev, and in my case the role
    "guest" and the object @user are stored in current_user session
    object. The method is supposed to be like this: only(who){ #do
    something for this particular "who" }-- the block passed to "only"
    will run only if the boolean returns true.
     
    hakunin, Jun 17, 2008
    #19
  20. hakunin

    hakunin Guest

    On Jun 17, 9:11 am, hakunin <> wrote:
    > On Jun 17, 8:52 am, Robert Klemme <> wrote:
    >
    >
    >
    > > On 17 Jun., 14:42, hakunin <> wrote:

    >
    > > > > Having a feature that makes the language simple which is not
    > > > > used by anyone (or only rarely) does not justify complicating the
    > > > > parser more than necessary.

    >
    > > > I wouldn't say that this is unused.  I came across this issue when
    > > > trying to write an ACL method, looking something like this:
    > > > only( a :guest and not the @user ) do end # => 'a' and 'the' are both
    > > > methods returning boolean based on supplied arg

    >
    > > Not sure how this can work since obviously you want to evaluate the
    > > ACL on access time and not when you define it.  Why don't you use a
    > > block?

    >
    > > only { a :guest and not the @user }

    >
    > > Cheers

    >
    > > robert

    >
    > I don't want to go too off-topic, as I just wanted to show a usage
    > example. To be quick - I'm doing web dev, and in my case the role
    > "guest" and the object @user are stored in current_user session
    > object. The method is supposed to be like this: only(who){ #do
    > something for this particular "who" }-- the block passed to "only"
    > will run only if the boolean returns true.


    It will make more sense if I mentioned this is used by designer in
    html templates to output or omit certain parts. : ) But that's beyond
    the subject, once again.
     
    hakunin, Jun 17, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. effbiae

    preprocessor and parenthesis

    effbiae, Feb 6, 2006, in forum: C Programming
    Replies:
    5
    Views:
    347
    Jordan Abel
    Feb 7, 2006
  2. keto
    Replies:
    0
    Views:
    1,022
  3. IveCal
    Replies:
    4
    Views:
    395
    stefanomnn
    Jun 22, 2007
  4. David Cournapeau

    print a vs print '%s' % a vs print '%f' a

    David Cournapeau, Dec 30, 2008, in forum: Python
    Replies:
    0
    Views:
    387
    David Cournapeau
    Dec 30, 2008
  5. bdb112
    Replies:
    45
    Views:
    1,401
    jazbees
    Apr 29, 2009
Loading...

Share This Page