John Cowan:
> Alternatively (and most Schemely / Common Lisply in my view): If you
> have a value, return it; if you don't have a value, return zero values.
Fair point.
One of my goals (not necessarily shared by everyone) is to have a notation and
implementation that is easily ported to any Li
On Tue, Jan 22, 2013 at 11:56 AM, John Cowan wrote:
> Alan Manuel Gloria scripsit:
>
>> We could also use one of the later techniques I eventually settled on:
>> have readers return a one-item list to mean "got a datum, here it is!"
>> or an empty list to mean "didn't get a datum". It complicates
Is the sweet-expression BNF done?
I've posted an updated "sweet.g" file in the "develop" branch that looks pretty
good to me. It contains an executable BNF, as well as various support
definitions. ANTLR gives it a clean bill of health in LL(1) mode, which I
think is valuable because it gives
Alan Manuel Gloria scripsit:
> But to receive it, you'd have to use something like:
>
> call-with-values
> ! lambda ()
> ! ! i-expr port whatever
> ! lambda args $ cond
> ! ! null?(args) $ do-whatever-with-no-value
> ! ! else $ do-whatever-with $ car args
Well, (let-values args) ...) does the jo
David A. Wheeler scripsit:
> * But should the *name* "restart list" continue? Is "superlist" better?
> Or something else?
Given that a restart is a specialized kind of continuation in Common Lisp
and some Schemes, and that "restart list" suggests "list of restarts", I
think it is bad. "Superl
John Cowan:
> Given that a restart is a specialized kind of continuation in Common Lisp
> and some Schemes, and that "restart list" suggests "list of restarts", I
> think it is bad. "Superlist" also suggests some sort of datatype,
> but I have nothing better to propose at the moment.
Good point a
Here are the key BNF definitions. These change FF/VT processing based on John
Cowan's recent comment.
Now uncommented FF/VT have to be on their own line, and they terminate any
current t-expression.
Again: Are we done? Any improvements or recommended changes?
--- David A. Wheeler
=== Sweet-e
John Cowan:
> Given that a restart is a specialized kind of continuation in Common Lisp
> and some Schemes, and that "restart list" suggests "list of restarts", I
> think it is bad. "Superlist" also suggests some sort of datatype,
> but I have nothing better to propose at the moment.
Here are som
On 1/23/13, David A. Wheeler wrote:
> John Cowan:
>> Given that a restart is a specialized kind of continuation in Common Lisp
>> and some Schemes, and that "restart list" suggests "list of restarts", I
>> think it is bad. "Superlist" also suggests some sort of datatype,
>> but I have nothing bet
On 1/23/13, David A. Wheeler wrote:
> Here are the key BNF definitions. These change FF/VT processing based on
> John Cowan's recent comment.
> Now uncommented FF/VT have to be on their own line, and they terminate any
> current t-expression.
>
> Again: Are we done? Any improvements or recommend
Alan Manuel Gloria:
> I assume scomment here is an "in-line" comment like #; or #| ... |#
Yes, you're right. "scomment" is short for "special comment".
The file "sweet.g" in the "develop" branch has the details; here's an extract:
BLOCK_COMMENT : '#|' // This is #| ... #|
(options {greed
Just to clarify, here are some examples of SPLIT/SUBLIST that might help
clarify things.
a \\ b
==>
a
b
a
\\
b
==>
a
b
foo
! c \\ d
==>
(foo c d)
foo
! c
! \\
! d
==>
(foo c d)
--- David A. Wheeler
--
Master Visu
> Just to clarify, here are some examples of SPLIT/SUBLIST
Sigh, I meant GROUP_SPLICE, aka \\. I was concentrating on the mapping and
screwed up the heading :-(.
--- David A. Wheeler
--
Master Visual Studio, ShareP
Alan Manuel Gloria:
> By my understanding the caller of head assumes that the port has just
> finished eating a newline. However the above case does not seem to do
> so. I guess ANTLR can transform it somehow, but the Scheme code we
> derive might need to put the checker here.
Perhaps the issue
On 1/23/13, David A. Wheeler wrote:
>> However there's no error signalled explicitly at this stage, and
>> although ANTLR might handle this correctly, I'm not so certain that a
>> naive Scheme translation would.
>
> ANTLR does indeed handle this correctly; since no production would match
> this, i
15 matches
Mail list logo
