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 <n...@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
