On 7/20/12, David A. Wheeler <dwhee...@dwheeler.com> 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 <dwhee...@dwheeler.com> 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
