Thread: eReader options
View Single Post
  #121   Report Post  
Posted to alt.home.repair
Don Y[_3_] Don Y[_3_] is offline
external usenet poster
 
Posts: 2,879
Default eReader options

On 1/16/2016 10:32 PM, rbowman wrote:
On 01/16/2016 08:33 PM, Don Y wrote:
But, I *do* keep references like the TeX books, various language manuals,
The Unicode Standard, CRC, Graphics algorithms, Knuth, Stevens, Comer, etc.
Things that I'll want to pick up and thumb to find a particular reference
or take off to a quiet corner to refresh my memory.


Even some of those could use some pruning. I've got a good collection of Perl
books but the question is if I'm ever going to use Perl again. Then there is
the J++ book, if you want to talk about dead and gone.


The only ones I could even *consider* would be the language manuals;
many of them are for old/obsolete languages (Mumps, SNOBOL, etc.).

OTOH, they've come in handy, in the past! Especially when consulting
papers written years ago.

E.g., there is a widely cloned letter-to-sound algorithm that was
originally written in SNOBOL. *EVERY* implementation that I have
come across -- typ in C -- adopts the strategies that are typically
used *there* instead of as they were originally written.

SNOBOL uses a "reluctant" wildcard matching algorithm -- it tries
to match to the smallest string possible and only ATTEMPTS to increases
the characters matched if this hesitant approach fails.

Consider how you'd approach "*?" for varying target strings:
"" "A" "AA" "AAA" etc.

Now, imagine a more complex grammar where you can define your own
wildcards and build up sentences using those:
# ::= 'A' | 'E' | 'I' | 'O' | 'U'
$ ::= "LY" | "ED" | "ING" | "ENCE"
etc.

Then, "productions" that combine those in arbitrary ways to form
replacement rules. With a "greedy" match, you get different results
than if you adopt a "reluctant" matching strategy -- one wildcard
can gobble up a character that should have been handled by the *next*
wildcard in the production/grammar.

Should "#+$D" (plus meaning at least one -- but possibly more -- of the
preceding symbol) match "IED"? With a greedy matching strategy, the
'I' and 'E' get swallowed by the "#+" leaving nothing for the '$'.
In a reluctant strategy, the "#+" only tries to gobble up the 'E'
if the pattern can't be matched with *just* the 'I' being matched.

I've also been rummaging through older languages with an eye towards
language features that would be suitable for a *user's* scripting
language (i.e., something a non-technical person could use to
say: "When I come home, at night, turn on the kitchen lights
as soon as I open the door.")

Imagine doing that in many of the modern languages -- littered
with lots of bizarre punctuation and idioms that make a *programmer's*
life easier -- but do nothing for a NON-programmer!