On 2/11/13, Arne Babenhauserheide <arne_...@web.de> wrote:
>> So: can you be more clear about how your indentation-based syntax
>> interacts with the n-expression stack?
>
> That was a part I wasn’t perfectly sure about when I wrote - and which I
> could not fix before sending, because I wrote late at night and knew that I
> would not have time to improve it the next few days.
>
> Conceptually:
>
> - neoteric at the beginning of a line is hard to do right
> (it would always be a double bracket).
> - neoteric within a line, or in a line which starts with .
> would just be the corresponding s-expression.
> - curly-infix would just be the s-expression - except if
> the whole line is curly-infix. I don’t like that exception…
> maybe the line with only curly infix should just be prefixed
> with a ..
>
> define : fibup maxnum count n-1 n-2
> if {maxnum = count}
> . {n-1 + n-2}
> fibup maxnum {count + 1} {n-1 + n-2} n-1
You know what I suggest? Drop the
single-item-on-a-line-is-single-item-list rule. Include the
"n-expression datum on a line by itself is just that item - if you
want to code a function call to a 0-arity function, explicitly put ()
around or after" from sweet. None of your examples rely on the
single-item-list behavior and must explicitly turn it off anyway, so I
think you should optimize the presentation for the more common usage.
Your main contributions seem to be the extended "." behavior (. a =>
a, . a b -> a b) and the ":" syntax. I don't see any use, even in
your examples, of the single-item-on-a-line-is-single-item-list
behavior.
>
>
>
> The : is just a shortcut for starting a new line at the indentation of the
> :. So
>
> define : fibfast n
> if {n < 2}
> . n
> fibup n 2 1 0
>
> could be written as
>
> define
> fibfast n
> if {n < 2}
> . n
> fibup n 2 1 0
That's fine and all, but suppose I'm defining a method for Guile GOOPS?
define-method : hack (x <cat>)
! do-hack-on-cat x
Oops, except hack only works on cats anyway, so I'll just optimize
things (because profiling shows that method calls in GOOPS take up all
my time, LOL) and turn hack into an ordinary function:
define : hack x
! do-hack-on-cat x
Oh, no!! Now I have to adjust the indentation of everything inside
it! Luckily hack x just contains do-hack-on-cat, so all I need to do
is adjust that single line.
define : hack (x <cat>)
! do-hack-on-cat x
--
The advantage of the current approach is that column positions are
only significant for the first non-whitespace non-! character on a
line.
: breaks that. It now makes :'s column position significant. This
has some drabacks
1. As seen above, changing text before the ":" marker will
potentially affect the interpretation of every non-blank line after
that. This is in contrast to \\ and $, which are completely
localized. Sure, it's rare to change define-method (or
define-whatever) to define, but suppose I had misspelled defin-method
and started continuously coding several lines? What if I misspelled
one of my own non-standard macros (so that the IDE won't highlight it,
since it doesn't recognize the the correctly spelled keyword anyway,
meaning a very high chance of me missing any misspelling)?
2. The implementation now needs to keep track of column positions all
the time, because we are never sure that we won't encounter it
suddenly. This is significant because it means a complete
reimplementation of n-expressions, one that does indeed keep track of
column positions. This means we also need to completely reimplement
string parsing (currently we depend on the underlying Lisp's
implementation), symbol parsing, and number parsing.
3. You need to explicitly specify how double-width CJK characters are
handled when found before a ":" (ban them in code? But what about
strings and #| |# comments?). Do we treat them as single character
columns (easy implementation, but potentially confusing, and possibly
limiting international code) or do we treat them as double character
columns (need to consider encoding, and implementations need to keep a
list of all such double-width characters)?
":" seems to put a lot of pressure on implementations, using your
current explanation. Perhaps we can change ":" to be more local (i.e.
it won't require keeping track of column position, and won't cause
cascading affects when text before it changes)?
--
In conclusion: I think the extended "." is OK, ":" not so much (needs
more explaining/thinking). I object to the
single-entity-is-list-of-one-item rule.
Sincerely,
AmkG
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
