On Sun, Sep 2, 2012 at 6:24 AM, Beni Cherniavsky-Paskin
<c...@users.sf.net> wrote:
> On Sat, Sep 1, 2012 at 8:58 AM, Alan Manuel Gloria <almkg...@gmail.com>
> wrote:
>>
>> (unit-type-rules
>> (<ScoutDrone> (unit-class <drone>) ...)
>>
>> (<BasicInfantry> (unit-class <infantry>) ...)
>>
>> unit-declarations
>> ...)
>>
> Arguably, it's not the most convenient s-expr structure:
>
> 1. Why doesn't unit-declarations start a separate list?
> It's reasonable to allow mutiple exprs at top level, with an implicit
> list after it.
> 2. If you have a lot of this and are concerned with writing convenience, the
> standard approach is:
> (def-unit-type <ScoutDrone>
> (unit-class <drone>) ...)
> (def-unit-type <BasicInfantry>
> (unit-class <infantry>) ...)
> (declare-unit ...)
> ...
>
> I'm sure you had reasons to choose your structure.
> The reason I'm bringing this up is just a reminder that whenever t-exprs
> don't look pretty enough,
> there is a temptation to have a a non-trivial transforms from t-exprs to
> s-exprs.
Because a top-level def-unit-type macro needs to put the information
in some collection somewhere, but which collection is not so certain.
My plan was to somehow make use of the Guile module system, so that
something like
(unit-type-rules ruleset-name
(unit-type
unit-type-property
...)
...)
becomes something like:
(define-module (ruleset ruleset-name unit-types)
:export (unit-types))
(define unit-types
(table ; this is an assoc-table data structure I'll be making in the backend
'unit-type
(table
unit-property-key unit-property-value ...)
'unit-type-2
(table
unit-property-key unit-property-value ...)))
Basically, my plan is that all the unit types get collected into a
single overarching data structure that is declared once in the macro
expansion.
Having separate top-level unit-type declarations requires some more
magic though....
Hmm. How about something like this:
(unit-types-file ruleset-name)
(unit-type <ScoutDrone>
...)
(unit-type <BasicInfantry>
...)
which then transforms into Guile:
(define-modules (rulesets ruleset-name unit-types)
:export (unit-types))
(define unit-types (table))
(set! unit-types
(extend-table unit-types
'<ScoutDrone>
(table ...)))
(set! unit-types
(extend-table unit-types
'<BasicInfantry>
(table ...)
...))
Hmm. Maybe this is a bit more acceptable to me...
>
>>
>> Now, the t-expressions form certainly looks quite cute:
>>
>> unit-type-rules
>> <ScoutDrone>
>> unit-class <drone>
>> ...
>> <BasicInfantry>
>> unit-class <infantry>
>> ...
>> unit-declarations
>> ...
>>
> IIUC, unit-type-rules ... unit-declarations ... are on same logical level so
> should have same indent.
> So starting with \\ would be more appropriate.
Uhm, unit-type-rules introduces a set of unit-declarations ...
So it's more like
unit-type-rules
unit-declarations
...
The <ScoutDrone>/<BasicInfantry> bits are just examples of a concrete
unit-declaration
>
>>
>> Except for two issues: I can't put empty lines between declarations,
>
>
> Did you try empty-comment lines?
> My experience with Python is vertical whitespace is *more* important once
> you traded block delimiters for newlines and indentation.
> I'm somewhat sceptical that empty-comment lines are a good substitute, but I
> haven't tried using t-exprs in anything big, so curious what's your take.
I have used empty-comment lines, but they're slightly unsatisfying to
me. They're *acceptable* but somewhat lacking in the invisibility
department. Hmm.
>
>> and I better make sure that my unit types <ScoutDrone> etc. start on
>> the same indent level, even if they are several dozen lines apart.
>>
> Not a problem IMHO. You better make sure that's true in any language/syntax
> :)
> At least this example doesn't demonstrate it - just use consistent indent
> levels (e.g. 2 spaces, 4 spaces).
> But it is important that unmatched dedents give an error.
Yes. But having them start at 0 indent is much easier to mention in a
guide or manual or tutorial.
>
>>
>> A similar issue comes up with the R6RS library form:
>>
>> (library (foo bar)
>>
>> ...
>>
>>
>>
>> ); end library
>>
>> ---
>>
>> So let me propose the indent everything symbol WHERE: "<-"
>>
>> library (foo bar) <-
>>
>> ...
>> --------
>>
>> unit-type-rules <-
>>
>> <ScoutDrone>
>> ...
>>
>>
>> unit-declarations
>> ...
>>
>> ----
>>
>> What do you think?
>>
> -1.
> It's yet another operator complicating the indentation<->structure mapping.
> Like $ only different. [Hmm, this gives me an idea to separate $ from the
> t-expr layer. I'll start a separate thread.]
> And it can't be terminated, which makes it very very bad in interactive use,
> and loses the ability to concatenate several files into one.
>
>> Another alternative:
>>
>> library (foo bar) \{
>>
>> export
>> foo
>> bar
>>
>> define foo(x)
>> several-long-code-pieces
>> ...
>>
>> define bar(y)
>> several-long-code-pieces
>> ...
>>
>> \}
>>
> Much better!
>
> But I'd drop the complexity of allowing it at the end of the line yet
> interacting with what came before.
> All you really need is a paren that doesn't disable indentation processing:
>
> \(
> library
> foo bar
>
> export
> foo
> bar
> ...
>
> \)
>
> There is no infix reordering here, so round parens are more appropriate than
> curlies.
> Is there a reason you proposed \{ \} ?
> [aside from the obvious C++ "namespace foo { ... }" parallel]
Well, all-in-all *just* the obvious C++/Haskell "bla bla where { }" parallel.
Sincerely,
AmkG
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
