On Tue, Jul 10, 2012 at 6:32 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> Alan Manuel Gloria:
>> As I mentioned before, I'm here mostly because (1) I want to write a
>> program in Guile, and (2) I got spoiled on Haskell's indentation
>> syntax. So what I really want to do is get the 0.3 specs frozen some
>> time soon (i.e current spec discussion should terminate before some
>> set date) so that we can all then focus on writing readers that
>> implement the 0.3 spec.
>
> I think that's entirely reasonable. There's no point in writing code without
> users!
>
> And no matter what we *think* is a good idea, I think that only actual use
> will *really* answer the question, "does this work well?".
>
>> So:
>>
>> Can/should we set a 0.3 spec freeze target date?
>
> Yes.
>
> Since you're the first user... what target date would you like?
>
How's the end of July (July 31) sound? What I really need are the
specs I can code to, not necessarily a complete reader - I can help
implement a complete reader, but I really want a stable spec I can
code to and implement.
By "complete", I also include having proper source location
information - Guile supports tagging cons cells with source location,
and keeps track of source location automatically in all I/O ports.
xref. the source code I've posted on the actual mailinglist, which
contains hooks for taking the source location from the I/O port and
putting it into arbitrary elements - there's a cond-expand which
detects guile, and if in guile will take source info from I/O ports
and put source info into pairs. In theory we can extend these for
other scheme implementations.
After all, debugging is much harder without proper source information T.T
>
>> I'm OK with having some specs not fixed at 0.3, I'll just code around
>> the unsettled parts
>
> I think that's perfect. We need a user who's willing to try on something
> that might change, and since you're willing to be that user, I can't imagine
> a better situation.
>
>
>> (having some resolution on
>> GROUP/SPLICE/SPLIT/END/whatever would be really convenient though -
>> I'm already designing a macro that builds parsers and is dependent on
>> the SPLICE-inline rule, so I really want to have *some* character
>> serve as SPLICE-inline).
>
> The big question here is GROUP/SPLICE/SPLIT/ENLIST. We're still discussing
> issues with both notation and semantics.
>
> First, let's have a backup plan. If we can't resolve anything else by the
> target date, let's use the existing I-expressions format and GROUP marker
> semantics. We already have a spec and code for that. We could change the
> GROUP marker trivially (in both code and spec) by the deadline, e.g., to "~".
> Changing the marker only takes seconds. This gives us a useful starting
> point, and it will also make it easy to find the code that might need
> changing if the syntax/semantics change (just grep for [ \t]*GROUP). You can
> always switch to lists of modern-expressions, too, so in many cases you don't
> need GROUP.
>
> A lot will depend on the target date - how soon do you want it? It'll take a
> little time to work out spec, code, and tests if there's a change.
>
Well, here's an example of code that I've started to write, but which
really really needs SPLICE.
The code below assumes: \ = GROUP = SPLICE, .-at-indent = whitespace.
define-syntax doing
syntax-rules (let)
\
. doing
. let var \ value
. body
. \ ...
..\ let ((var value))
. doing
. body
. \ ...
\
. doing
. x
..\ x
\
. doing
. x
. body
. \ ...
..\ begin
. x
. doing
. body
. \ ...
; inspired by Haskell, of course!
doing
let x \ compute-x(foo bar)
let y \ compute-y(foo bar)
{x + y}
So, currently what's more important for me is the SPLICE-inline rule
and SPLICE character.
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
