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