C:\test>p1
[0]{} Perl> print 123 * 346;;
42558
[0]{} Perl> print 123 * 456;
print 'pqr';;
56088
pqr
[0]{} Perl> sub xyz{
my( $a, $b ) = @_;
my $c = $a + $b;
$c += $a * $b;
$c += $a - $b;
$c += $a / $b;
return $c ** 2;
};;
[0]{} Perl> print xyz( 123, 456 );;
3173549946.78328
[0]{} Perl> Terminating on signal SIGINT(2)
C:\test>
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
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*.
| [reply] |
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |