<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 28, 2014, at 4:21 PM, Henry Lenzi <<a href="mailto:henry.lenzi@gmail.com">henry.lenzi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Neil --<br><br>So how do you export hash keys as symbols to a file that can be read<br>in again, not as string?<br><br>Now, I haven't gotten around to reading the whole of Racket Scheme's<br>documentation... Things are looking kind of hard.<br><br>What I'm attempting to do is then read back the symbols defined, such<br>as the one below:<br><br>(define hctz25 "Hydrochlorothiazide 25mg")<br><br><blockquote type="cite">(close-input-port in)<br>(define in (open-input-file "Recipe.txt"))<br>(string->symbol (read-line in))<br></blockquote>'|'hctz25|<br><br>But what I really want is the "hctz25" symbol that evaluates to a<br>string. If I don't use string->symbol, I get the string "hctz25". And<br>why the bars ("|”)? </blockquote><div><br></div><div>As an explanation of the bars:</div><div>If you use read-line, does it return the string <font face="Courier New">"hctz25"</font>, or the string <font face="Courier New">"'hctz25"</font> (with the quote as the first character)?</div><div><font face="Courier New"> > (string->symbol "hctz25")</font></div><div><font face="Courier New"> 'hctz25</font></div><div><font face="Courier New"> > (string->symbol "'hctz25")</font></div><div><font face="Courier New"> '|'hctz25|</font></div><div><br></div><div>I think you’d want to use read for that though, not read-line. </div><div><br></div><div>You might be able to use something a bit like this:</div><div><font face="Courier New">(define hash (make-hash))</font></div><div><font face="Courier New">(match (read in)</font></div><div><font face="Courier New"> [`(define ,sym ,str) (hash-set! hash sym str)])</font></div><div><font face="Courier New">(hash-ref hash 'hctz25)</font></div><div><br></div><div>Or something like this:</div><div><font face="Courier New">(define hash</font></div><div><font face="Courier New"> (for/hash ([def (in-port read in)])</font></div><div><font face="Courier New"> (match-define `(define ,sym ,str) def)</font></div><div><font face="Courier New"> (values sym str)))</font></div><div><font face="Courier New">(hash-ref hash 'hctz25)</font></div><br><blockquote type="cite">I've read<br><br> <a href="http://docs.racket-lang.org/reference/reader.html#%28part._parse-hashtable%29">http://docs.racket-lang.org/reference/reader.html#%28part._parse-hashtable%29</a><br><br>but it didn't help me much.</blockquote><blockquote type="cite"><br>Of course, the ultimate purpose would be to re-evaluate the imported<br>symbol and reconstruct a medical recipe. The purpose of these<br>baby-steps exercises is porting a medical recipe program I've written<br>originally in Forth that allowed me to service 5.000 patients creating<br>a little database of shorthand recipes that then expand into real<br>medical recipes. I got hundreds of patients on renewable recipes for,<br>say, hypertension. Hand writing is no fun. Typing them in Word is no<br>fun. The hospital has is its own software, but it's is a load of<br>baloney, extremely buggy, if you ask me, so I'm rolling my own again,<br>except I want to print directly on the model paper our service uses,<br>so I want graphics like Racket Scheme has (very good capabilities, as<br>far as my needs are concerned).<br><br>With Forth, it's very easy to design DSLs, because there's no syntax<br>and you get a lot of advanced features for free. For instance, there's<br>no need to write a parser for my little language. However, since Forth<br>implementations fall short of dealing with images, graphics (unless<br>you take the royal road to pain and learn to program for the Win32 API<br>and how it works for a particular Forth vendor), I'm looking at Racket<br>Scheme.<br><br>TIA,<br><br>Henry Lenzi<br><br><br><br><br><br><br><br><br>On Mon, Jul 28, 2014 at 4:46 PM, Neil Van Dyke <<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>> wrote:<br><blockquote type="cite">I don't know the current state of the "eval" docs in the manual, but I think<br>they should have a big warning at the very front, intended to scare away<br>newbies.<br><br>Remember that Racket is often used in conjunction with many different<br>Scheme-based and other Lisp-based textbooks and courses. It seems that many<br>CS instructors and textbook authors like to talk about ``EVAL'' (as an<br>abstract operation) when talking about some models of evaluation, and "eval"<br>(as an accessible language binding) to say, gosh, aren't dynamic languages<br>interesting and powerful. So, we can't blame every fourth newbie for trying<br>to use "eval" unnecessarily, in ways that make for bad software engineering.<br><br>Given this reality of confusing instruction, I'm thinking that, as a<br>reactive measure, "#lang paddle" will disable "eval" by default. Attempting<br>to use "eval" will give you an error message, unless you have an assertion<br>form like<br>"(i-have-read-the-foo-document-and-understand-that-eval-is-usually-the-wrong-thing-but-honest-i-know-what-i-am-doing)".<br><br>Cheers,<br>Neil V.<br><br>Vincent St-Amour wrote at 07/28/2014 02:21 PM:<br><br><blockquote type="cite">Maybe this should be linked to from the `eval' docs?<br><br><br><a href="http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html">http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html</a><br><br>Vincent<br><br><br>At Sun, 27 Jul 2014 16:16:52 -0400,<br>Neil Van Dyke wrote:<br><blockquote type="cite"><br>Maybe there should be a periodic public service announcement about not<br>using "eval". This time I will communicate in FAQ format:<br><br>Q: How do I use eval?<br>A: Don't use eval.<br><br>Q: But don't so many academic books feature eval prominently, so doesn't<br>that mean I should use try to eval?<br>A: Those books use eval for pedagogic reasons, or because the author is<br>enamored of some theoretical appeal of eval, or because the author wants<br>to watch the world burn. Don't use eval.<br><br>Q: But, but, but, I am just starting to learn, and eval seems to do what<br>I need.<br>A: Eval is almost certainly not what you want. Learn how to use the<br>other basics effectively. Don't use eval.<br><br>Q: I now am very comfortable with the language, I am aware that I should<br>avoid eval in almost all cases, and I can tell you why eval is actually<br>the right thing in this highly unusual case.<br>A: Cool, that's why eval is there.<br><br>Neil V.<br><br></blockquote></blockquote><br>____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a><br></blockquote>____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a><br></blockquote></div><br></body></html>