<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thanks, Vincent. But a recipe is more than those simple definitions. Actually, it would be something like:</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> MEDICATION DOSE UNITS ----------------- QUANTITY FORM INSTRUCTIONS FOR TAKING MEDICATION </blockquote><div> </div>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.<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote> <div> </div><div>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'.</div> <div> </div><div><div> (define meds (hash 'hctz "Hydrochlorothiazide"</div><div> 'cough-drops "Cough Drops"))</div></div><div> </div><div><div> (define (abbreviation->full-name abbreviation)</div> <div> (dict-ref meds abbreviation))</div></div><div> </div><div>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.</div> <div> </div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Jul 29, 2014 at 10:54 PM, Henry Lenzi <<a href="mailto:henry.lenzi@gmail.com" target="_blank">henry.lenzi@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div class="HOEnZb"><div class="h5"> On Mon, Jul 28, 2014 at 6:03 PM, Vincent St-Amour <<a href="mailto:stamourv@ccs.neu.edu">stamourv@ccs.neu.edu</a>> 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 >> >> <a href="http://docs.racket-lang.org/reference/reader.html#%28part._parse-hashtable%29" target="_blank">http://docs.racket-lang.org/reference/reader.html#%28part._parse-hashtable%29</a> >> >> 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 <<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>> 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? >> >> >> >> >> >> <a href="http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html" target="_blank">http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html</a> >> >> >> >> 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: >> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> ____________________ >> Racket Users list: >> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> ____________________ Racket Users list: <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> </div></div></blockquote></div> </div>