On Sun, 2006-09-10 at 10:19 -0700, Charles D Hixson wrote:
> skaller wrote:
> To me this looks like a minor bit of polish. Nice, but not
> significant.
Looks, and not intellectual content, sell, or at least
help with initial contact. And minor issues of visual appearance
really do matter to the practice of programming.
> Before you add it make SURE it won't interfere with
> something else you might want to do later. If you're sure, and it's
> easy, then go for it.
I'm not sure, that's the problem.
At present, you basically need
<semi-colon> <keyword> ...
to start a statement. There are some other cases, but hope
for a token filter to recognize this. In fact, one might
consider: Felix has a LOT of keywords, and there is even
a facility to introduce new ones:
#keyword newkey
and one might consider
#unkeyword goto
as a feature to resolve accidental clashes, or a tool for
teachers to help students learn structured programming,
even:
#rekey class kategorie
for our German users .. ok, the Germans can cope,
but what about people speaking Mandarin, Arabic,
or Hindi? Grammar and word ordering is bad enough
without a host of unfamiliar keywords getting in the
way of comprehension.
So various tools may allow certain identifiers to be
considered keywords only in some context.
Removing semi-colons removes redundancy that would otherwise
make structure detection easy: including error detection.
Python, for example, has:
def x():
...
but note the indent is preceded by a colon, which helps distinguish
it from
def x(
): ..
which is also allowed. Whilst I like layout visually, it has
enough problems not to mandate <newline> as separator: there
was a big revolution in my early years, eliminating this wart
from languages like FORTRAN which relied on it.
So the problem is: I do *not* really understand the consequence.
Eliminating the need for semi-colons in most places will
cause some minor breakages at present: no biggie I think.
But going back would be a disaster: the change is irrevocable.
Ocaml doesn't need semicolons .. and it is hard to get
used to:
open List
open Map
let f x =
x := y
;
a := b
but:
open List
open Map
;;
x := y
;;
a := b
This basically destroys 'cut and paste' transformations
unless one is careful to write the separators on a separate
line (and even then it fails, since top level Ocaml allows ;;
instead of ; and unfortunately recognizes it as a separate
token in inner contexts .. ;(
We're mixing metaphors: in English:
* full-stop is a terminator
* Capitalisation is an initiator
* semi-colon and comma are separators
But we also want 'visual cut and paste' to work.
Separators destroy this. They're bad. Python allows:
(a,b,c,)
for a tuple, which is extremely useful for large tables:
(
a,
b,
c,
)
This is also why I write matches:
match x with
| a => c
| b => u
...
even with one line form:
match x with | True => x | False => y
because it is easier to manipulate the layout.
Also as noted using keywords as initiators means they
can't initiate optional subclauses:
fun f()="" require y
won't work: the inner 'require' here is currently attached to the
fun .. to support that an also allow:
x = 1
require z
would require parsing beyond LALR1, so this has to be changed
already to
fun ()="" require y;
we require z;
or something.
However this doesn't mean there aren't solutions. For exaample:
x = 1
f ()
WOOPS! That means
x = 1 f ()
now: newline isn't a separator. Ouch .. it looks like one.
But we can do
x = 1
call f ()
fun k()=""
set x = 2; y = j;
a = b
Hmmm... the thing is at the moment Felix is *specifically* designed
to support cut and paste: any statement of sequence of statements
can be inserted, deleted, or moved in one mouse operation
without any extra typing required .. except for the pre-processor
getting in the way, and except for C++ style // comments,
both of which depend on layout for hysterical reasons :)
Such a fixed standard provides assurances, but removes
some stylistic freedom. Another example: we all know
infix operators:
x * (y + z)
are cute, but they're also BAD syntactically: reverse
polish is much better:
z y z + *
because it guarantees cut and paste of ANY sequence.
Felix provides cut-and-paste guarantee at the statement
level but not the expression level. Hmm.. isn't that
inconsistent?? I mean you CAN write forward polish
in point-free form right now:
mul$ x add$ pair$ y z
(assuming pair: x-> y -> x * y)
Removing semi-colons still ALLOWS you to use semi-colons,
it just becomes a style issue.
Even if I can enforce my stylistic preferences,
I may still have to work with your code.
Something like:
#style terminator
#style layout
#style separator
#style initiator
may be useful -- it allows enforcement or relaxation of a style
and it *communicates* that visually, so that
#style layout
x = 1
y = 2
is now a bit more acceptable .. ok I don't like newlines
and indentation but there is a directive announcing the authors
preference. Yes, this could work, the lexer would fiddle it
so the parser sees the simplest form, #style would have
to be restricted to easily recognizable lexical contexts.
Some care is needed:
#bracket "[{" "]" myop
is allowed .. so one just can't count brackets without
taking this --- and Unicode --- into account.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
