Re: Suggested enhancement
David Cuny wrote (I received this via private mail - I think it
probably meant to go to the list)...
A::>Jeff Zeitlin suggested being able to pass a sequence of Euphoria code to
::>Euphoria.
A::>Sounds like a good suggestion. The biggest problem I can think of would be
::>when an error occured, how would you know *where* it occured?
Well, the ex.err dump would show that it happened on an EXECUTE
statement/function, and would dump the variables. One of the
dumped variables would be the executed code - so you would at
least be able to pin it down by that much. If it wasn't passed
as a variable, there wouldn't be a lot of code to desk check;
it's unlikely in the extreme that one would write more than
about a line of code this way - and I can't think of any real
reason why someone would want to do so, rather than just
writing it directly into the program. Wait, yes I can, but
there's still not going to be much code.
In the case where it happens in a large chunk of code in a
variable, I think it might depend on how it is actually
implemented; if I were doing this, I would most likely make it
a "back door" to the parser and interpreter routines - much
like JPSoftware did when they added the %@EXEC[] function to
4DOS. There would be a small performance hit for EXECUTEd
code, but... Anyway, I see no reason why the ex.err report
couldn't at least print the offending statement "in EXECUTE
parameter" - for example
program.ex:41
attempt to divide by 0 in "? 1/0" in EXECUTE parameter
Global & Local Variables
...etc.
A::>If Robert doesn't want to put this together, one of the list members would
::>certainly be able to write this. Obviously, there would be a performance hit
::>taken if it were coded in Euphoria, but it is doable.
Certainly it is - but you'd have to write both the parser _and_
the interpreter, and if you wanted access to Euphoria's
debugging facilities, you'd have to write the debugger and
trace facilities as well. We'd be talking _major_ performance
hit; it might be acceptable if the language you're parsing
isn't Euphoria and isn't easily translatable into Euphoria -
but I doubt that many people would find it so. One of the
major benefits of Euphoria, IMO, is that it is _fast_ and
_compact_ - enough so to impress the Borland that wrote the
original Turbo Pascal. I don't think that my EXECUTE proposal
would slow it down into the realm of most language
interpreters; one would gain the flexibility of a LISP
interpreter without having to sacrifice the simplicity or a
significant portion of the speed of Euphoria.
A::>Euphoria itself certainly has an interesting parser, and is lazy when it
::>comes to parsing lines. For example, I can have the line:
A::> puts( {}, 1 }
A::>and Euphoria parses it happily, only paying attention to the number of
::>arguments (and whether any arguments require parameters), and not attempting
::>any further validation until the line is actually run.
Interesting - I would have expected that the built-ins, at
least, would have at least as strong type-checking as the
user-written routines. OTOH, that might have made it
unacceptably difficult to permit overriding of those routines
with user code.
A::>Also, the 'end' keyword is not part of the language. For example, if you try
::>to run the following code:
A::> end
A::>you don't get an "unmatched end" error, you get an "unknown command". I get
::>the feeling that each of the structure have their own parsing routines, that
::>scan the input until they find a matching "end" clause.
Possibly - it's certainly how I would think to do it...
A::>The biggest problem in coding a Euphoria parser in Euphoria is the lack of
::>forward declarations.
I'm not sure I perceive why forward declarations would be
necessary - would you be willing to elucidate?
=========================================================================
Jeff Zeitlin jeff.zeitlin at execnet.com
---
~ OLXWin 1.00b ~ ..... Help!, The TD has fallen and it can't get up!
|
Not Categorized, Please Help
|
|
