[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comment on SRFI-110 and Comparison to Genyris xyzzy

This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.


Re: http://srfi.schemers.org/srfi-110/srfi-110.html#genyris

I have made some syntactic decisions which I regard as restricting programmers to write in a better style. For example not allowing lists to wrap encourages more smaller functions.  That's OK for source code, however when loading data files one should not restrict the structure. One difficulty with a syntax that defaults to lists is that something special needs to be done for atoms.

Example (a b c (d e f) xx) is problematic since xx is subordinate but is not a list. So in Genyris I was forced to add a leading 'continuation' character ~. Which gives me:
> quote
:   a b c
:      d e f
:      ~xx
(a b c (d e f) xx) # PairSource

There is another (obvious) way to wrap lists in Genyris just place
a = at the end of the line.  example:
> list 1 2 3 4 5 =
:    6 7 8
(1 2 3 4 5 6 7 8) # Pair

In practice I don't often use line continuation in code.

One thing to remember is that indentation may force you to re-arrange  functions to suit the constraints of indentation. For example I had a function 'tag' which took two arguments, an _expression_ and a class. e.g.
   tag (+ 2 3) Inches

But when the _expression_ begins to get complex it made more sense to re-order the function to give tag <class> <_expression_> simply so the _expression_ could grow on the subordinate indents. example:
class Person ()
   def .new()
      tag .self
            define age 25
            def .getAge() age
            def .setAge(val) (set ^age val)

So if you use indented syntax expect the language itself to change!