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

From: Vincent St-Amour (stamourv at ccs.neu.edu)
Date: Mon Jul 28 17:03:07 EDT 2014

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

Posted on the users mailing list.