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

>
> Thanks, Vincent. But a recipe is more than those simple definitions.
> Actually, it would be something like:


> MEDICATION DOSE UNITS ----------------- QUANTITY FORM
>      INSTRUCTIONS FOR TAKING MEDICATION


The module idea would still work. You can define your definitions in one
file, provide them, and then require them in another file. The definitions
can be as complex as you like.

In my previous Forth version, this was extremely easy to achieve, as
> Forth is syntax-less, and "code is data, and data is code". So the
> recipe turned out to be a mini language written in Forth itself.


There doesn't seem to be any need for "code as data, data as code" here.
Instead of mapping abbreviations to full names with identifiers and values,
why not use keys and values with a hash-table? It removes the need for
'eval'.

  (define meds (hash 'hctz "Hydrochlorothiazide"
                              'cough-drops "Cough Drops"))

  (define (abbreviation->full-name abbreviation)
    (dict-ref meds abbreviation))

If the mapping is constant, you can store it in another module, provide,
and require it, like Vincent explains. If your mapping is updated over
time, you can save it to a file as Roman explains. Saving it to a file
doesn't require text parsing. With print, read, and serialize, all the hard
work is already taken care of.




On Tue, Jul 29, 2014 at 10:54 PM, Henry Lenzi <henry.lenzi at gmail.com> wrote:

> Thanks, Vincent. But a recipe is more than those simple definitions.
> Actually, it would be something like:
>
>
> MEDICATION DOSE UNITS ----------------- QUANTITY FORM
>
>      INSTRUCTIONS FOR TAKING MEDICATION
>
> In my previous Forth version, this was extremely easy to achieve, as
> Forth is syntax-less, and "code is data, and data is code". So the
> recipe turned out to be a mini language written in Forth itself.
>
> These seems to be harder in Scheme... Some here seem to shun code/data
>  ("don't use eval") in favor of what would amount ultimately to
> string-based methods, as far as I understand it.
>
> - Henry
>
>
>
>
>
> On Mon, Jul 28, 2014 at 6:03 PM, Vincent St-Amour <stamourv at ccs.neu.edu>
> wrote:
> > Henry,
> >
> > It looks like modules may be what you're looking for.
> >
> > You could have a file that defines a substance and exports it
> >
> >     ;; a.rkt
> >     #lang racket
> >     (provide hctz25)
> >     (define hctz25 "Hydrochlorothiazide 25mg")
> >
> > and then a recipe file that imports the previous file
> >
> >     #lang racket
> >     (require "a.rkt")
> >     hctz25
> >
> > The module system is the preferred way to share definitions across
> > multiple files in Racket.
> >
> > Would that solve your problem?
> >
> > Vincent
> >
> >
> > At Mon, 28 Jul 2014 17:21:40 -0300,
> > Henry Lenzi wrote:
> >>
> >> Hi Neil --
> >>
> >> So how do you export hash keys as symbols to a file that can be read
> >> in again, not as string?
> >>
> >> Now, I haven't gotten around to reading the whole of Racket Scheme's
> >> documentation... Things are looking kind of hard.
> >>
> >> What I'm attempting to do is then read back the symbols defined, such
> >> as the one below:
> >>
> >> (define hctz25 "Hydrochlorothiazide 25mg")
> >>
> >> > (close-input-port in)
> >> > (define in (open-input-file "Recipe.txt"))
> >> > (string->symbol (read-line in))
> >> '|'hctz25|
> >>
> >> But what I really want is the "hctz25" symbol that evaluates to a
> >> string. If I don't use string->symbol, I get the string "hctz25". And
> >> why the bars ("|")? I've read
> >>
> >>
> http://docs.racket-lang.org/reference/reader.html#%28part._parse-hashtable%29
> >>
> >> but it didn't help me much.
> >>
> >> Of course, the ultimate purpose would be to re-evaluate the imported
> >> symbol and reconstruct a medical recipe. The purpose of these
> >> baby-steps exercises is porting a medical recipe program I've written
> >> originally in Forth that allowed me to service 5.000 patients creating
> >> a little database of shorthand recipes that then expand into real
> >> medical recipes. I got hundreds of patients on renewable recipes for,
> >> say, hypertension. Hand writing is no fun. Typing them in Word is no
> >> fun. The hospital has is its own software, but it's is a load of
> >> baloney, extremely buggy, if you ask me, so I'm rolling my own again,
> >> except I want to print directly on the model paper our service uses,
> >> so I want graphics like Racket Scheme has (very good capabilities, as
> >> far as my needs are concerned).
> >>
> >> With Forth, it's very easy to design DSLs, because there's no syntax
> >> and you get a lot of advanced features for free. For instance, there's
> >> no need to write a parser for my little language. However, since Forth
> >> implementations fall short of dealing with images, graphics (unless
> >> you take the royal road to pain and learn to program for the Win32 API
> >> and how it works for a particular Forth vendor), I'm looking at Racket
> >> Scheme.
> >>
> >> TIA,
> >>
> >> Henry Lenzi
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Jul 28, 2014 at 4:46 PM, Neil Van Dyke <neil at neilvandyke.org>
> wrote:
> >> > I don't know the current state of the "eval" docs in the manual, but
> I think
> >> > they should have a big warning at the very front, intended to scare
> away
> >> > newbies.
> >> >
> >> > Remember that Racket is often used in conjunction with many different
> >> > Scheme-based and other Lisp-based textbooks and courses. It seems
> that many
> >> > CS instructors and textbook authors like to talk about ``EVAL'' (as an
> >> > abstract operation) when talking about some models of evaluation, and
> "eval"
> >> > (as an accessible language binding) to say, gosh, aren't dynamic
> languages
> >> > interesting and powerful. So, we can't blame every fourth newbie for
> trying
> >> > to use "eval" unnecessarily, in ways that make for bad software
> engineering.
> >> >
> >> > Given this reality of confusing instruction, I'm thinking that, as a
> >> > reactive measure, "#lang paddle" will disable "eval" by default.
> Attempting
> >> > to use "eval" will give you an error message, unless you have an
> assertion
> >> > form like
> >> >
> "(i-have-read-the-foo-document-and-understand-that-eval-is-usually-the-wrong-thing-but-honest-i-know-what-i-am-doing)".
> >> >
> >> > Cheers,
> >> > Neil V.
> >> >
> >> > Vincent St-Amour wrote at 07/28/2014 02:21 PM:
> >> >
> >> >> Maybe this should be linked to from the `eval' docs?
> >> >>
> >> >>
> >> >>
> http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html
> >> >>
> >> >> Vincent
> >> >>
> >> >>
> >> >> At Sun, 27 Jul 2014 16:16:52 -0400,
> >> >> Neil Van Dyke wrote:
> >> >>>
> >> >>> Maybe there should be a periodic public service announcement about
> not
> >> >>> using "eval".  This time I will communicate in FAQ format:
> >> >>>
> >> >>> Q: How do I use eval?
> >> >>> A: Don't use eval.
> >> >>>
> >> >>> Q: But don't so many academic books feature eval prominently, so
> doesn't
> >> >>> that mean I should use try to eval?
> >> >>> A: Those books use eval for pedagogic reasons, or because the
> author is
> >> >>> enamored of some theoretical appeal of eval, or because the author
> wants
> >> >>> to watch the world burn.  Don't use eval.
> >> >>>
> >> >>> Q: But, but, but, I am just starting to learn, and eval seems to do
> what
> >> >>> I need.
> >> >>> A: Eval is almost certainly not what you want.  Learn how to use the
> >> >>> other basics effectively.  Don't use eval.
> >> >>>
> >> >>> Q: I now am very comfortable with the language, I am aware that I
> should
> >> >>> avoid eval in almost all cases, and I can tell you why eval is
> actually
> >> >>> the right thing in this highly unusual case.
> >> >>> A: Cool, that's why eval is there.
> >> >>>
> >> >>> Neil V.
> >> >>>
> >> >
> >> > ____________________
> >> >  Racket Users list:
> >> >  http://lists.racket-lang.org/users
> >> ____________________
> >>   Racket Users list:
> >>   http://lists.racket-lang.org/users
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140730/7330b980/attachment-0001.html>