[racket] Use of map and eval to evaluate symbol in namespace

I would just like to add that this is only something very embrionary.
There are a myriad ways to validate the user syntax when he/she
provides input.

We're just not there yet! ;-)

Cheers,
-- Henry

On Mon, Aug 4, 2014 at 12:52 AM, Henry Lenzi <henry.lenzi at gmail.com> wrote:
> Hello Neil -
>
> First of all, I am not attempting tricks. I am doing the best I can,
> the way I know how to (I will take the "clever" part as a compliment,
> however). I have a few rational requirements, which I have explained.
> Foremost among them is code simplicity. I saw no need so far for
> parsers or macrology - I have justified this on the basis of the DSL.
> As I had not been clear WRT the DSL before, I might have induced
> people to make an option for macros. Also, I see a need for a part of
> the program source-code to be easily customizable by users (such as,
> for example, a Swedish user being able to add his/her own definitions
> in simple module files, instead of tinkering with hash tables).
>
> What I'm sensing is that you seem to be concerned about bugs with
> Racket Scheme's EVAL. Is that it?
> I do not understand what the problem with EVAL is. Would you please
> state clearly what the problems are? I am a reasonably sophisticated
> reader. You can even point to papers. I might not read them now, but I
> even have books on stuff like denotational semantics (what I don't
> have is much time, sadly).
>
> Are you concered about using imperative style just on principle or
> have you detected a specific issue?
>
> Doesn't the fact that definitions are provided by modules reduce
> potential bugs? As I understand it, if I type, e.g., "hctz30" instead
> of "hctz25" the run-time environment will bork, as that would not be a
> symbol in the read table. Correct?
>
> Doesn't the DSL's rigid syntax reduce potential for bugs? Do you
> suggest a formal parser? If so, can you explain the case why a formal
> grammar would be a necessity? This is not a grammar/DSL that requires
> recursion (in the Chomskyan sense). I don't see the point. Perhaps I'm
> wrong. I would feel grateful if you cared to expand on that issue (if
> that is an issue).
>
> If there are too many bugs, can you cite one, two or maybe three that
> would be of concern?
>
> TIA,
> Henry Lenzi
> PS: I hope you realize that writing prescriptions by hand is a sure
> way to get even more "bugs"...
>
>
> On Mon, Aug 4, 2014 at 12:18 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:
>> I can see how someone might want to do tricks like this, to use the REPL as
>> user interface, for tinkering, and that could be very interesting or clever.
>>
>> However, just to be clear to students and professionals who might stumble
>> upon this thread... If I were actually doing this in production for
>> pharmaceutical prescriptions/labeling/instructions, then I would be
>> concerned about both program correctness and reducing potential for operator
>> error to cause failures.  If we were starting with those as key requirements
>> for production use, then I think some of this technical discussion might be
>> irrelevant to that, since the software might be implemented in a very
>> different way.
>>
>> Neil V.
>>