1 |
On 6/19/07, Steve Long <slong@××××××××××××××××××.uk> wrote: |
2 |
> Kent Fredric wrote: |
3 |
> > If you can, try integrate a name based syntax into the requirement. |
4 |
> > using decorative characters alone may have their uses, but there are |
5 |
> > only so many you can use, and so many combinations you can create |
6 |
> > before all your code starts looking like perl's acme eyedrops. I say |
7 |
> > name based, because this allows some degree of permitting forward |
8 |
> > development & enhancement without majorly breaking an existing system |
9 |
> > :) |
10 |
> > |
11 |
> Wow that all sounds mega: er what does it mean? ;) I mean, can you give |
12 |
> examples of the syntax please? I'm guessing and instead of && but what |
13 |
> about (..) Is that going to be line-based? (LISP brackets are very annoying |
14 |
> imo.) |
15 |
|
16 |
Plot summary: |
17 |
|
18 |
Limitation of symbol oriented commands: |
19 |
!@#$%^&*()-+~`[]:"<>,./?\| |
20 |
|
21 |
By the time your in the want for more than 30 general features, your |
22 |
starting to have nasty syntax like this: |
23 |
(!#$ 1.4.6) |
24 |
|
25 |
By the time you want to get something practical done, you've got big |
26 |
screenfulls of non-human readable (well, not in the normal sense ) |
27 |
syntax which you need to frequently RTFM just to work out what each |
28 |
esoteric combination of symbols does. |
29 |
|
30 |
I'm merely suggesting that we have some room for a syntax+keyword |
31 |
system ( which is both easier to parse, and easier to program, and |
32 |
reduces the volume of 'wtf is that new syntax or somebody making a |
33 |
typo?' for old revisions and makes it obvious to the parser 'no, thats |
34 |
not a syntax error, he merely referred to a module we ain't got yet ' |
35 |
) |
36 |
|
37 |
Maybe the limitations of bash programming are not conducive to that |
38 |
desire tho, but if symbol based programming was all that wonderful |
39 |
we'd probably have more than 255 characters in the ANSI spec ( I for |
40 |
one, don't know of any languages where the actual syntax requires |
41 |
Unicode, at least for any purpose other than internationalization ) |
42 |
|
43 |
|
44 |
Plot Summary Summary: |
45 |
Future Proof, so that its easier to make stuff backwards compatible later. |
46 |
|
47 |
Plot Summary Summary Summary: |
48 |
......yeah. |
49 |
> |
50 |
> > ( im not much of a lisper, but lisp a lot of functionality for the |
51 |
> > cost of very minimal symbol abuse . .im not saying we should use lisp |
52 |
> > syntax, but maybe a page from their book in terms of expandability ) |
53 |
> |
54 |
> Yeah #haskell has nice ideas too.. |
55 |
> |
56 |
> |
57 |
> -- |
58 |
> gentoo-dev@g.o mailing list |
59 |
> |
60 |
> |
61 |
|
62 |
|
63 |
-- |
64 |
Kent |
65 |
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x| |
66 |
print "enNOSPicAMreil kdrtf@×××.com"[(2*x)..(2*x+1)]}' |
67 |
-- |
68 |
gentoo-dev@g.o mailing list |