Re: [Readable-discuss] SUBLIST == ENLIST?
Alan Manuel Gloria:
> ENLIST needs more work to flesh out. But anyway, that is how I
> envisioned ENLIST to work. Which is higher priority depends. But I
> think not{ENLIST eq? SUBLIST}
Okay, reasonable enough.
> Anyway, I've got my hands full on SPLIT and its effects, as well as
> planning the reorganization/refactoring of modern.scm and sugar.scm
> and sweet.scm, and add source location information at least on Guile
> (and preferably also on Racket), so I'm really gonna have to pass
> ENLIST to one of you guys to consider.
...
> 2. ENLIST-inline: this is when my brain BSOD'ed.
:-).
Okay.
--- David A. Wheeler
--
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
Re: [Readable-discuss] SUBLIST == ENLIST?
On 7/20/12, David A. Wheeler wrote:
>> Of course, the lack of true currying means that a slight variant like:
> . foo(bar(nitz quux(meow)))
> ...
>
> True, the operator is less helpful in this case. You could do this:
>
> .foo $$ bar nitz quux(meow)
>
Actually, the intent of SUBLIST is that the above can be written as:
foo $$ bar nitz $$ quux meow
First, consider the first $$:
EXPR1 = (foo)
EXPR2 = bar nitz $$ quux meow
Now EXPR2 needs to have its own $$ processed:
subEXPR1 = (bar nitz)
subEXPR2 = (quux meow)
append1(subEXPR1 subEXPR2) =
append(subEXPR1 list(subEXPR2)) =
append( '(bar nitz) list('(quux meow)) =
(bar nitz (quux meow))
EXPR2 = (bar nitz (quux meow))
append1(EXPR1 EXPR2) =
append(EXPR1 list(EXPR2)) =
append('(foo) list('(bar nitz (quux meow =
'(foo (bar nitz (quux meow)))
.. which is the desired s-expression.
--
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
Re: [Readable-discuss] SUBLIST == ENLIST?
So, basically: ENLIST does not treat its RHS as a new line expression, unlike QUOTE et al., SPLIT, or GROUP, i.e. it won't somehow recurse into readblock-internal. ENLIST treats its RHS specially, and if the next line is indented, also treats that specially. If ENLIST treated its RHS as an expression, then it will be no better than SPLIT, and might as well be dropped. Anyway, I've got my hands full on SPLIT and its effects, as well as planning the reorganization/refactoring of modern.scm and sugar.scm and sweet.scm, and add source location information at least on Guile (and preferably also on Racket), so I'm really gonna have to pass ENLIST to one of you guys to consider. Basically, remember that: 1. GROUP is how group actually works in SRFI-49. 2. ENLIST is how you imagined group was *supposed* to work when you first saw SRFI-49's sentence "The GROUP symbol is used to allow lists whose first element is also a list.", and then saw it used in let examples of the SRFI-49 document. In short: ENLIST is simple to talk about informally but once you start thinking of it, I suspect ENLIST is going to be larger/more complex than what you simply assume. My first stab at ENLIST is: 1. ENLIST-at-the-start: Force all elements of the rest of the line to be a list, and make that list the first element of a higher-level list; this ends at newline. If the next line is indented more than the current line, then get additional sub-expressions at that indentation level and append those additional sub-expressions to the higher-level list. Applying the ENLIST-at-the-start rule: ~ foo bar . nitz quux . meow fish "Force all elements of the rest of the line to be a list" ;#~ means we are processing ENLIST #~ (foo bar) . nitz quux . meow fish "...make that list the first element of a higher-level list..." #~ ((foo bar) ... ; to be continued... . nitz quux . meow fish "...get additional sub-expressions at that indentation level and append those additional sub-expressions to the higher-level list" #~ ((foo bar) ... . (nitz quux) . (meow fish) ) ; okay, found end here... Final result: ((foo bar) (nitz quux) (meow fish)) 2. ENLIST-inline: this is when my brain BSOD'ed. 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
Re: [Readable-discuss] SUBLIST == ENLIST?
On 7/20/12, David A. Wheeler wrote:
> Alan Manuel Gloria:
>> >> I once had to code this expression:
>> >>
>> >> force(car(force(unwrap-box(s
>> >>
>> >> And it's ugly.
>> >>
>> >> I could use I-expressions:
>> >>
>> >> force
>> >> . car
>> >> . . force
>> >> . . . unwrap-box s
>> >>
>> >> But that wastes precious vertical space.
>> >>
>> >> So I propose the SUBLIST semantic.
>
> I'm wondering - can we consider SUBLIST == ENLIST?
>
> You can call this a new variant if you want, which is why I'm starting a new
> thread. But I *think* they could be defined as being the same operator.
>
> Semantics could be, where $$ is the SUBLIST==ENLIST separator, that given:
> EXPR1 $$ EXPR2
> It maps to:
> (EXPR1 EXPR2)
> I.E., it becomes cons(EXPR1 EXPR2).
Shouldn't that be append1 instead of cons, with EXPR1 as a list even
if it's just one element?
define append1(lyst elem)
append(lyst list(elem))
given:
f $$ nitz quux
EXPR1 = (f) ; force list interpretation, even if single element
EXPR2 = (nitz quux)
cons(EXPR1 EXPR2) = ((f) nitz quux)
append1(EXPR1 EXPR2) = (f (nitz quux))
>
> where either EXPR1 and EXPR2 can be empty, and EXPR2 can span lines. The
> beginning of EXPR1 is the end of this line's indentation, the previous $$,
> or previous \\, whichever comes first. EXPR2 is processed as if it were
> beginning a line, and can have child lines.
Hmm
$$ var value
\\
EXPR1 = () ; enforce list interpretation
EXPR2 = (var value)
append1(EXPR1 EXPR2) =
append(EXPR1 list(EXPR2)) =
append( () ((var value))) =
((var value))
Is that your intent?
Also:
let
. $$
. expr()
on the $$ line:
EXPR1 = ()
EXPR2 = ()
append1(EXPR1 EXPR2)
>
> I'm not sure if I'm changing your original intent for the ENLIST operator;
> if I am, please enlighten me!
>
The point of ENLIST was to reduce the number of lines in the bane of
indentation-based syntax, let:
let
. ~ var value()
. . var2 value2()
. expr
compare the following which has one more line:
let
. \\
. . var value()
. . var2 value2()
. expr
Now, focus on the subtlety here:
let
. ~ var value()
. . var2 value2()
. expr()
If we use SUBLIST as you described:
let
. $$ var value()
. . var2 value2()
. expr
This gets parsed, using your rules, to:
(let
( (var (value)
(var2 (value2
expr)
Notice how var2 is nested incorrectly within var's definition!
Our goal for ENLIST is that:
let
. ~ var value()
. . var2 value2()
. expr
gets parsed to:
(let
( (var (value))
(var2 (value2)))
expr)
In addition ENLIST had an imagined (but not fully specced out) rule
when found inline:
; use fixed-width font for viewing
let ~ var value()
. . var2 value() ; has higher indent
. expr ; followed by lower, indent
ENLIST needs more work to flesh out. But anyway, that is how I
envisioned ENLIST to work. Which is higher priority depends. But I
think not{ENLIST eq? SUBLIST}
On 7/20/12, David A. Wheeler wrote:
> I asked:
>> > What would be the best symbol, if implemented? $, $$, ~, something
>> > else?
>
> Kartik Agaram replied:
>> It looks a lot like haskell's $.
>
> I don't think that's accidental :-).
Yes.
--
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
Re: [Readable-discuss] SUBLIST == ENLIST?
I asked: > > What would be the best symbol, if implemented? $, $$, ~, something else? Kartik Agaram replied: > It looks a lot like haskell's $. I don't think that's accidental :-). Amusingly, our spec notation also uses $ currently ($1, $2, etc.). But we could disambiguate or change. --- David A. Wheeler -- 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
Re: [Readable-discuss] SUBLIST == ENLIST?
I said: > Semantics could be, where $$ is the SUBLIST==ENLIST separator, that given: > EXPR1 $$ EXPR2 > It maps to: > (EXPR1 EXPR2) > I.E., it becomes cons(EXPR1 EXPR2). > > where either EXPR1 and EXPR2 can be empty, and EXPR2 can span lines. The > beginning of EXPR1 is the end of this line's indentation, the previous $$, or > previous \\, whichever comes first. EXPR2 is processed as if it were > beginning a line, and can have child lines. Well, sort of. It's not always cons(EXPR1 EXPR2) because EXPR1 can be empty. So I think the semantic I have in mind is: if empty-expression?(EXPR1) . list(EXPR2) . cons(EXPR1 EXPR2) Note that this can create improper lists, I don't know if that is okay or not. --- David A. Wheeler -- 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
