in reply to Re^3: howto parse (or determining end) of a line of perl
in thread howto parse (or determining end) of a line of perl

Wasn't unclear. Just that it's similar to the invoking an instance of perl to do the same except that it saves context, while up, more like my calc does (which is limited to 1 line).

It would be closer to what I want if you "assumed" 1 semi -- see if that parses. If so, goto next. If not, then this is where that PPI module could be useful -- run the parse w & w/o the semi and see if it only can work the 2nd way -- if so, ask for another line. If it can work w/a semi- default to closing the statement unless a backslash is on the end.

Of course if it works with or w/o a semi (like after a closing '}'), then you goback to ask for a new line.

Yours is more of a REPL (gee, wonder why!;-)), while mine was intended to print results like a calculator -- used to do a better job until I 'fixed' it some time back -- and haven't fixed it again -- printed the hex, string and fractional formats if they made sense.

BTW -- when I say 'calc', I really mean evaluate a perl expression and print the result, which was sufficient for my purposes.

It also stopped working right when my distro updated one of the Term::readchar/line routines and now it thinks it is talking to a dumb tty... real annoying, but those are 'transitory issues'... It's not something I use too much -- just now and then and now and then make changes in it -- and the "itch" of it not handling multiple lines like bash would, got "itchier", sorta, if that makes any sense.

Maybe going through the extra pain of the trying dual-parsing w/PPI and "with", and "with/out" semi's to determine whether to close input and return a result might be the shortest path to get where I might want to go, but that's too much work for a short scratching session and got bigger fish to fry before I can play in my playground...*sigh*.

  • Comment on Re^4: howto parse (or determining end) of a line of perl

Replies are listed 'Best First'.
Re^5: howto parse (or determining end) of a line of perl
by BrowserUk (Patriarch) on Aug 25, 2016 at 18:26 UTC
    It would be closer to what I want if you "assumed" 1 semi -- see if that parses. If so, goto next. If not, then this is where that PPI module could be useful -- run the parse w & w/o the semi and see if it only can work the 2nd way -- if so, ask for another line.

    Hm. My point in posting my solution to the problem is that it is extremely simple. And it works.

    As the user, I know exactly when what I've typed is complete and should be evaluated. And that is true every time I use the interface.

    There is -- IMO; definitely for my repl, but also from my understanding of your calculator -- simply no purpose or benefit from attempting to program in a heuristic to try and predict what the user -- sat right there at the keyboard entering the text your heuristic would be trying to analyse -- is thinking or wanting.

    With all of the complexity that is PPI and all the effort that would be required to try and achieve guessing what the user wants; when the user can simply indicate it directly...pointless.

    Of course, it's your time, your effort and your choice; but KISS is a fine principal to adopt.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      "...KISS is a fine principal to adopt"

      Agreed, but "simple" is also subjective.
      For me, simple is allowing for same or similar input, not based on context, but also not requiring extra "noise characters" to determine meaning.

      Example, one feature my calc has, is I can say a=2*pi*1 and for the LHS assign (_only_, right now), the sigil isn't needed (pi is a sub(){...}). Also doesn't require an ending semi -- allowing less "code-looking-like" input. I can add a semi or a '$' if I want -- and *have* to if 'a' is an array or hash, but for simple vars...allow "simple", non-decorated input. See, there's that word "simple" again... I'm just thinking along simpler lines... (whatever that might imply/mean! ;-)).

[reply]
[d/l]
[select]
        Example, one feature my calc has, is I can say a=2*pi*1 and for the LHS assign (_only_, right now), the sigil isn't needed ... See, there's that word "simple" again

        And how much complexity is required to allow you the "simplicity" of omitting one character under some circumstances?

        If you find typing sigils so onerous, I have a suggestion for you: http://www.scilab.org/

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom