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

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.
  • Comment on Re^5: howto parse (or determining end) of a line of perl

Replies are listed 'Best First'.
Re^6: howto parse (or determining end) of a line of perl
by perl-diddler (Chaplain) on Aug 26, 2016 at 00:40 UTC
    "...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]
        Sigils onerous? How about 'unnecessary'? Most languages don't need them. But more to the point, when's the last time you saw calculators using sigils.

        As for how much complexity: 1 line: 

            if (/^\w/) { /^\w+=/ and $_='$'.$_ }

        [download]
        Perl could go, *mostly*, sigil-free if it wanted and remain 100% compat w/previous progs.

        I.e. it would still accept sigils, but for vars w/o sigils -- they would be allowed if predeclared and perl would use the predeclared type. If there was ever a case where more than 1 type was declared for 1 name, then a sigil would be required to differentiate them when using one of them. But in most cases where the same name isn't used w/multiple types, perl would already know the intended type as stated in the declaration.

        Would likely reduce perl's "line noise" reputation and should be 100% compat w/old code (as old code has to have sigils in place, and when in place, then no predeclared-type-default would be used.

[reply]
[d/l]

In Section Seekers of Perl Wisdom