Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1523
| From | news@iecc.com (News Subsystem) |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: parsability |
| Date | 2015-02-09 14:37 +1100 |
| Organization | Compilers Central |
| Message-ID | <15-02-021@comp.compilers> (permalink) |
| References | <10-11-017@comp.compilers> <15-02-009@comp.compilers> <15-02-011@comp.compilers> <15-02-017@comp.compilers> <15-02-019@comp.compilers> |
From: "Hans-Peter Diettrich" <DrDiettrich1@netscape.net> Sent: Monday, February 09, 2015 6:49 AM > Robin Vowels schrieb: > >> A number of special characters have traditionally acquired multiple uses. >> The asterisk, parentheses, apostrophe, colon, period, feature heavily >> on account of the limited number of characters available in equipment >> of the era (48-character set, 60 character set, etc.) and continue to do so >> for historical reasons. > > IMO the real and persistent limit is the keyboard, with a limited number > of keys. Present keyboards for the PC have keys for 33 special characters (in addition to upper and lower-case and digits). That's twice as many in use in languages. > Increasing the number of keys is not a solution, because then > it may be more time consuming to find an special key, instead of reusing > a character or typing more characters. No need to increase the number of keys. Recall old typewriters? Some had provision for three shifts (lower-case, upper-case, and special characters). The same could be done with computer keyboards (well, it's sort of done with the normal, caps, and CTRL keys). A proper third shift key with corresponding glyphs inscribed on the keys could extend the range of special characters. After all, there is provision for 256 characters encoded in a byte, and we use only half of them. >Why didn't APL succeed in the long run? Because it was write once throw-away language. Programs were largely unintelligible to all except the writer. This email probably contains viruses and malware despite what avast! Antivirus protection says. [It was perfectly possible to write readable APL programs, but almost nobody did. -John]
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Choosing a parser for Mathematica input fateman@gmail.com - 2015-02-05 08:08 -0800
parsability (was: Choosing a parser for Mathematica input) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-06 00:05 +0000
Re: parsability and human factors "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2015-02-07 12:45 +0000
Re: parsability and human factors glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-08 10:32 +0000
Re: parsability and human factors "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2015-02-10 12:44 +0000
Re: parsability "Robin Vowels" <robin51@dodo.com.au> - 2015-02-09 00:48 +1100
Re: parsability Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2015-02-08 20:49 +0100
Re: parsability news@iecc.com (News Subsystem) - 2015-02-09 14:37 +1100
Re: Choosing a parser for Mathematica input Robert Jacobson <rljacobson@gmail.com> - 2015-02-06 19:04 -0800
csiph-web