Re: [Readable-discuss] Proposal: SUBLIST (not a GROUP replacement)
I should note that QUOTE+SPACE is basically "$" but specialized to the traditional abbreviations: quote $ f(a) => ' f(a) => 'f(a) => (quote (f a)) --- 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] Proposal: SUBLIST (not a GROUP replacement)
Alan Manuel Gloria: > So I designed my parser-combinators library's interface. Here are some > basics: (I'm assuming this is an example of SUBLIST, not a proposed change to the "readable" material. Let me know if my assumption is wrong!) ... > Here's a simple example for parsing the keyword "for": > > define for-parser > ! parser > ! try > ! seq > ! char=? #\f > ! char=? #\o > ! char=? #\r > ! not-followed-by (charp? alphanum-char?) > > Now, the parser - try - seq block is a bit long. At the same time, it > is impractical to disable indentation for the seq block, which would > appreciate not having to use parens. > > But if SUBLIST exists: > > define for-parser > ! parser $ try $ seq > ! char=? #\f > ! char=? #\o > ! char=? #\r > ! not-followed-by (charp? alphanum-char?) > > Indeed, this seems like a nice rule to have for cases where you want > to suddenly splice a function call or macro around a construct that is > best expressed in indentation-form. It's easy to convince me it *could* be useful. Clearly function composition as a general capability is valuable. And I guess it can be argued that this is, in a very loose sense, a dual of SPLIT (SPLIT turns one line into many, SUBLIST turns multiple lines into one). I'm just trying to make sure that the new rule is so useful that it's worth adding. This *is* a reasonable example. Applying "not" to a long sequence is another example. What the heck, let's put it in. It's a little unfortunate that we're stealing "$", but it would only be active during indentation process, so it could still be used as an infix operator. --- 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] Proposal: SUBLIST (not a GROUP replacement)
So I designed my parser-combinators library's interface. Here are some basics: parser - a macro to defer evaluation of parsers. Used when you want to make forward references to parsers that will be defined later in the file. try - a function that accepts a parser and gives it the ability to fail without consuming input, i.e. allow delimited backtracking/lookahead. Basically the same as the try combinator on Haskell's Parsec. seq - a macro that supports binding of parser produced values, to construct a higher-order parser that makes a computation based on sub-parsed values. Like the Haskell's do when used in Parsec. The syntax of seq is similar to the syntax of the doing macro I've been tossing around on the list for some time now. Here's a simple example for parsing the keyword "for": define for-parser ! parser ! try ! seq ! char=? #\f ! char=? #\o ! char=? #\r ! not-followed-by (charp? alphanum-char?) Now, the parser - try - seq block is a bit long. At the same time, it is impractical to disable indentation for the seq block, which would appreciate not having to use parens. But if SUBLIST exists: define for-parser ! parser $ try $ seq ! char=? #\f ! char=? #\o ! char=? #\r ! not-followed-by (charp? alphanum-char?) Indeed, this seems like a nice rule to have for cases where you want to suddenly splice a function call or macro around a construct that is best expressed in indentation-form. 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] Proposal: SUBLIST (not a GROUP replacement)
On 7/19/12, David A. Wheeler wrote:
> Alan Manuel Gloria:
>
>> Just when it's less than 2 weeks to spec freeze
>
> :-).
>
>> 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.
>
> Hmm. Function composition isn't unknown, of course, but I'm skeptical about
> how often this kind of construct occurs. Every new rule has a mental cost;
> we need to make sure the cases are so common (or so egregious) that the
> construct is worth it. Otherwise, people will reject it as being "too
> complicated" to learn. The wrapped example you show above is actually how
> many other languages *would* show it.
>
> I also worry about using up one-character symbols; if we do anything like
> this, perhaps a multi-char symbol would do? We could also pick a few
> symbols to "reserve" for cases like this; again, it's not so bad if we
> reserve multi-character symbols.
Well, we could define an o-function that does composition:
define o
case-lambda
(f) f
(f g)
lambda parms
f apply(g parms)
(f g . rest)
{{f o g} o apply(o rest)}
Then: {force o car o force o unwrap-box}(s)
(or use <*> or <.> or something less egregious than o, now that I look
at it, o looks ugly, eh?)
Of course, the lack of true currying means that a slight variant like:
foo(bar(nitz quux(meow)))
Can't use a compose chain like o above.
foo $ bar nitz $ quux meow
--
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] Proposal: SUBLIST (not a GROUP replacement)
Alan Manuel Gloria: > Just when it's less than 2 weeks to spec freeze :-). > 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. Hmm. Function composition isn't unknown, of course, but I'm skeptical about how often this kind of construct occurs. Every new rule has a mental cost; we need to make sure the cases are so common (or so egregious) that the construct is worth it. Otherwise, people will reject it as being "too complicated" to learn. The wrapped example you show above is actually how many other languages *would* show it. I also worry about using up one-character symbols; if we do anything like this, perhaps a multi-char symbol would do? We could also pick a few symbols to "reserve" for cases like this; again, it's not so bad if we reserve multi-character symbols. --- 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] Proposal: SUBLIST (not a GROUP replacement)
Why $? 1. Haskell uses it for a highly similar meaning 2. Think of $ as a tiny open parenthesis (, a vertical line, and a tiny close parenthesis ): (| |) So $ is an implied promise to open a list, which will automatically get closed somewhere down the road (the vertical line). 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
[Readable-discuss] Proposal: SUBLIST (not a GROUP replacement)
Just when it's less than 2 weeks to spec freeze
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.
Informally:
1. If the SUBLIST symbol "$" is found in the middle of a line, then
it is an implied "promise" to insert a "(" at that point with a ")"
automagically inserted at the end of the block (i.e. before the next
line with the same or lesser indent than this one). So:
force $ car $ force $ unwrap-box s
is equivalent to:
(force ( car ( force ( unwrap-box s
The only time that the promise will not get used is if there is only a
single term after the $: thus:
foo $ bar
is:
(foo bar) ; no ( ) automagically inserted around bar
FORMAL Spec:
(i-expr lvl) -> head hspace+ SUBLIST hspace+ (i-expr lvl)
(append $1 (list $5))
1. SUBLIST considers the rest of the line as a new expression at the
same indentation level as the current line. This new expression is
then used as the last member of the list being built.
--
This syntax reduces the need for foo:bar syntax in Arc, BTW. : is
more compact as it needs no space, and it can be used in higher-order
functions, but $ is at the reader level, and does not require magic
when used in head position (unlike Arc, where officially foo:bar means
(compose foo bar) but (foo:bar nitz) really means (foo (bar nitz)) to
make macros composable).
--
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
