mayer@sono.uucp (Ronald &) (05/25/91)
[In a recent email message I asked for a more user-friendly
interactive interface with access to perl commands kinda like
a combination of perl, a shell, and a calculator.
In this message a was asking for a method to determine whether a
line of input entered by the user contains a syntax error of if it
is potentially part of a valid multi-line perl statement.]
All responses I recieved told me that the best way they knew of to
determine this is to '$@ =~ /at EOF/'. While this works fine for
some programming styles, it fails for others. i.e.
eval 'for $i (1..10) {' # ($@ =~ /at EOF/) == TRUE
eval 'for $i (1..10)' # ($@ =~ /at EOF/) == FALSE
The source of my difficulty seems to be related to the fact that eval
appends a ';' to the end of the string before evaling it. Is it
really necessary for eval to do this? Is there a way to turn off this
feature?
Ron Mayer
mayer@sono.uucp sun!sono!mayerlwall@jpl-devvax.jpl.nasa.gov (Larry Wall) (06/11/91)
In article <MAYER.91May24142354@porky.sono.uucp> mayer@sono.uucp (Ronald &) writes:
:
: [In a recent email message I asked for a more user-friendly
: interactive interface with access to perl commands kinda like
: a combination of perl, a shell, and a calculator.
: In this message a was asking for a method to determine whether a
: line of input entered by the user contains a syntax error of if it
: is potentially part of a valid multi-line perl statement.]
:
: All responses I recieved told me that the best way they knew of to
: determine this is to '$@ =~ /at EOF/'. While this works fine for
: some programming styles, it fails for others. i.e.
: eval 'for $i (1..10) {' # ($@ =~ /at EOF/) == TRUE
: eval 'for $i (1..10)' # ($@ =~ /at EOF/) == FALSE
:
: The source of my difficulty seems to be related to the fact that eval
: appends a ';' to the end of the string before evaling it. Is it
: really necessary for eval to do this? Is there a way to turn off this
: feature?
It's not necessary--just very convenient. There's no way to turn it
off currently.
It seems to me that it would be more fruitful to diddle the yacc grammer
so that it could fake end_of_input at the right point. Banging on
the parser in weird ways is apt to leave bits of undigested syntax tree
around in memory. There's no easy solution to this.
I'd rather see some indication from the user that he or she thinks input
is done. I think overloading a single newline for this is just asking
for trouble. Yes, the shells do it. The shells do a lot of other things
that are just asking for trouble too. My opinion, of the moment but not
of any moment.
Larry