Re: [Readable-discuss] Bug (or feature??): multiline comment acts as SPLIT
> I think comments should nest iff they nest in that language *without* our readers. That is, if #|...|# nests in the underlying language, then it should in our reader. If it doesn't, it shouldn't. Remember, we're trying to maximize backwards compatibility, so we shouldn't change the semantics of stuff we don't *have* to. Ah, so you're implementing something already provided by a language! I was under the impression that these were something new for sweet-expressions. I'm glad to see that they are done right in Scheme, as it is! :-) (Of course, it probably shouldn't come as a surprise. This *is* a Lisp community we're talking about...) To the best of my knowledge, Common Lisp does not have multi-line comments, so I don't think this is going to be an issue for Common Lisp. On Thu, Aug 2, 2012 at 4:54 PM, David A. Wheeler wrote: > Alan Manuel Gloria: > > The comments themselves remove text in the following manner: > > > > #|.. #|...|#...|# nests > > > > #!..!# doesn't nest, as per Guile behavior > > I think that's perfect. As much as possible we should be > backwards-compatible, and this fits the bill. > > > #; x y z removes the x (only c-expressions/n-expressions are removed). > > Sorry, but it gets *really* difficult to make this work at the > > t-expression level - you need something like the current quote > > handling to make it remove t-expressions! And of course another tag > > separate from comment-tag. > > I think that's exactly the right decision. > > The phrase: > #; x y z > *could* be interpreted as "comment (x y z)" or "comment x". > > But as you noted, the implementation challenges would be hideous. Not > only that, but it seems to me that a user would expect that: > > x #; y z > > Would be interpreted as "(x z)". > > So I think the better (as well as easier) interpretation is that #; > comments out the following *neoteric* datum. > > Now, that does raise the question of how to comment out datums that are > indented. But to be honest, ; does a fine job. If indentation is active, > it's trivial to find the matching END line. So it's not clear that we need > any additional mechanisms. > > > Will fix the incorrect handling of multiline comments in the middle of > > lines. They should only act as SPLIT when at the start of line, to > > handle stuff like > > That sounds right, too. > > --- 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] (ab)using SUBLIST
I think it's abuse (putting the let on the first line makes it difficult to see), but I see no reason why it should be forbidden, except in style guidelines. Indeed, there may even be situations where it's the preferred idiom... I do have a question, though: Is "\\" implemented so that it would be possible to do this? let ! \\ var1 $ bar x ! ! var2 $ quux x ! nitz var1 var2 If not, I still think it would be a good idea to extend the implementation to be able to do this; it makes the block a little more compact, and a little more readable. I'd also expect that it wouldn't be too difficult to implement. On Thu, Aug 2, 2012 at 9:27 AM, David A. Wheeler wrote: > Alan Manuel Gloria: > > So I've started coding, and I thought up of some (ab)use of SUBLIST: > > > > define foo(x) $ let > > ! \\ > > ! var1 $ bar x > > ! var2 $ quux x > > ! nitz var1 var2 > > First, just to clarify those who have trouble seeing the horizontal > whitespace, this is the same as this: > > define foo(x) $ let > ! \\ > ! ! var1 $ bar x > ! ! var2 $ quux x > ! nitz var1 var2 > > > I don't think that's an *abuse* at all. I don't think I would format it > that way, but I think that's exactly right and intended. After all, we > *expect* people to do this: > let > ! \\ > ! ! var1 $ bar x > ! ! var2 $ quux x > ! nitz var1 var2 > > So prefixing "define foo(x) $ ..." should do just what you've written. > And "$" is *intended* help counter the endless march of indentation. > > --- 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 > -- 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] Presentation on readable s-expressions
Oh, and I forgot to mention, that I think the presentation looks good. I
look forward to the video! :-)
On Thu, Aug 2, 2012 at 9:38 AM, Alpheus Madsen wrote:
> I don't know why, but I've always been bothered by calling s-exprs "ugly";
> it's something that has bothered me ever since I've discovered
> sweet-expressions. Although I don't yet have much experience in Lispy
> programming, I find the syntax of s-exprs rather beautiful; it has a
> certain simplicity that makes it particularly charming.
>
> This isn't to say I don't think that s-expressions are perfect, by any
> means! Indeed, I always cringe when I see an inequality, like "(< a 1 b 2
> c 3)"--if anything makes the case for sweet-expressions, it's that it will
> become possible to say "{3 <= a < 10}" in a short-circuitry sort of
> way--but somehow, "ugly" isn't the right word to describe them.
>
> Having said that, I can't yet suggest a better word. Maybe "awkward"?
>
> This is just a quibble, and I'm probably not quite right about it,
> either. I'm not even sure it's worthwhile worrying about it, although I
> can understand why the average Lisper might take offence at calling s-exprs
> "ugly"; yet that may be a reason in itself to try to find a better term!
>
>
>
> On Thu, Aug 2, 2012 at 8:47 AM, David A. Wheeler wrote:
>
>> The "develop" branch now includes a short presentation on readable
>> s-expressions:
>>
>> http://sourceforge.net/p/readable/code/ci/a0409c2145573b4752635ba984ac27e719772c58/tree/readable-s-expressions.odp
>>
>> Please comment! I plan to use this, plus a little on-line work to create
>> a video.
>>
>> --- 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
>>
>
>
--
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] Presentation on readable s-expressions
I don't know why, but I've always been bothered by calling s-exprs "ugly";
it's something that has bothered me ever since I've discovered
sweet-expressions. Although I don't yet have much experience in Lispy
programming, I find the syntax of s-exprs rather beautiful; it has a
certain simplicity that makes it particularly charming.
This isn't to say I don't think that s-expressions are perfect, by any
means! Indeed, I always cringe when I see an inequality, like "(< a 1 b 2
c 3)"--if anything makes the case for sweet-expressions, it's that it will
become possible to say "{3 <= a < 10}" in a short-circuitry sort of
way--but somehow, "ugly" isn't the right word to describe them.
Having said that, I can't yet suggest a better word. Maybe "awkward"?
This is just a quibble, and I'm probably not quite right about it, either.
I'm not even sure it's worthwhile worrying about it, although I can
understand why the average Lisper might take offence at calling s-exprs
"ugly"; yet that may be a reason in itself to try to find a better term!
On Thu, Aug 2, 2012 at 8:47 AM, David A. Wheeler wrote:
> The "develop" branch now includes a short presentation on readable
> s-expressions:
>
> http://sourceforge.net/p/readable/code/ci/a0409c2145573b4752635ba984ac27e719772c58/tree/readable-s-expressions.odp
>
> Please comment! I plan to use this, plus a little on-line work to create
> a video.
>
> --- 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
>
--
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] Bug (or feature??): multiline comment acts as SPLIT
As a general rule, I expect "multi-line" comments to be comments that just
disappear when compiled.
Oh, and this will likely make the implementation of comments more
complicated, but would it be possible to make these comments "nested"? It
has always bugged me, where multi-line comments are allowed, that you can't
comment out blocks with multi-line comments in them. For example:
#include iosys.h
/* Let's comment out this function for debugging purposes
int test(int m, int n) {
/* Here is a comment that
spans multiple lines */
return m+n;
} */
void main(void) {
return 0;
}
In attempting to comment out the function, I fail, because the block only
goes to the first */ rather than the second. If a block has several such
sub-blocks, it becomes a great pain to go back and forth, "breaking" and
then "fixing" the blocks, if you have reason to go back and forth between
commenting and uncommenting the outer comment.
To me, this has *always* been broken. I'd like to see it fixed! :-)
Of course, if you had a string like "FORTH has a */ operator." somewhere, I
don't know what would happen in C if you tried to put it in a comment block
(my guess: Bad Things), but such a case is easily handled by escaping
methods of some sort.
On Thu, Aug 2, 2012 at 8:17 AM, David A. Wheeler wrote:
> Alan Manuel Gloria
> > Before, when planning out multiline comments, I thought that:
> >
> > #|comment|# foo bar
> >
> > would be equivalent to:
> >
> > \\ foo bar
> ...
> > However, when I implemented it, I completely forgot to consider the
> > following case:
> >
> > foo #|comment|# bar
> >
> > The current implementation on 0.3.0 yields:
> >
> > foo
> > bar
> >
> > Should it? I think the intent here would be that it would become
> > something like:
> >
> > foo bar
> >
> > then
> >
> > (foo bar)
> >
> > Should I fix this? Is this indeed a bug?
>
> I think it's a bug. It's certainly not what I would have expected.
> Please *do* fix it!
>
> --- 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
>
--
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] a more readable programming model
If I recall correctly, Dylan allows access to the AST, and allows for the
possibility of macros, but because they are so difficult to write, macros
are seldom written in Dylan.
Someone once made the point that Python allows you to parse statements, but
the resulting parse tree is too complicated to manipulate. I can't find
the original blogpost or essay or whatnot, but I *think* I figured out how
to parse "2+2". (I've also tried "print 'hello world!'" and a "for" loop,
but the parser doesn't work for those, and I don't know why...) Here's the
code:
import parser
parser.st2list(parser.expr('2+2')
which produces
[258, [327, [304, [305, [306, [307, [308, [310, [311, [312, [313, [314,
[315, [316, [317, [318, [2, '2'], [14, '+'], [315, [316, [317, [318,
[2, '2', [4, ''], [0, '']]
I have a feeling that a lot of the information there is compiler
broiler-point...but regardless, it's not going to be a picnic to manipulate!
Whereas, with a sweet-expression, '{2 + 2}' compiles to tree '(+ 2 2)',
which is *much* simpler!
On Sat, Jul 28, 2012 at 12:49 AM, Kartik Agaram wrote:
> Yes, I wasn't actually advocating y'all do anything with this idea. It
> just seemed like a good group of people to show the idea to, to get
> your reactions.
>
> > Uh oh, comma for separating function parameters. That's been tried
> before in a Lisp, but that means that ,-lifting is easily missed visually.
>
> I deliberately ignored the syntax for macros. This is an *utterly*
> blue-sky idea, so you could use anything for macros. If the goal is a
> more familiar syntax, perhaps macros should be defined with #define
> and $ for unquote. Or something.
>
> > Okay, but how do you determine which function to apply?
>
> Yes, this came up on the arc forum as well: I have somehow utterly
> ignored higher-order functions.
>
> Perhaps quote would be useful here somehow..
>
> > Lisp has always let you write your own evaluator. That's no problem,
> just code it up, and send your data to it. It'd be a crisis if you tried
> to REPLACE the standard evaluator with something different, of course. But
> all you have to do is send the data to your new evaluator directly (in many
> ways it's actually easier to do this than replace the reader).
>
> I don't understand this. Is 'writing your own evaluator' the same as
> writing an interpreter atop any language?
>
> > But frankly, this is starting to sound like you want ML or Haskell. The
> thing is, if you want ML or Haskell, there are already fine implementations
> of them.
>
> Neither has lisp macros.
>
> "Everything is open to question -- but you'll have to pry macros out
> of my cold dead hands." -- me, http://github.com/akkartik/wart#readme
>
> I'm also not big on type systems.
>
> > Here I completely disagree with you. Being homoiconic is a *necessary*
> property of a Lisp notation. If complex list structures get created
> without *any* possibility of the developer knowing, it becomes impossible
> to control the result.
>
> Yeah I need to think about this more deeply.
>
> It's funny. Ten years ago I didn't understand lisp and I didn't know I
> didn't understand lisp. Five years ago I thought I understood macros
> and how lisp was the only language to have them. This year I suddenly
> find I don't in fact understand these 'obvious' matters.
>
> Anyways, I'll stop hijacking this list now :) This is all utterly
> off-topic.
>
>
> --
> 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
>
--
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] method_missing
I may very well be wrong, but I have the impression that Common Lisp has this ability; I just have no idea how to go about capturing a missing method (or even just a missing function). But in any case, such a thing is language dependent, and thus outside the scope of the project. One reason why I would like to make a Common Lisp shell, is because Common Lisp is famous for not having good Unix tools for accessing files, or making use of the underlying operating system. In my twisted logic, I concluded that the best way to get those features, would be to make the interpreter into a shell. That, and I'd much rather use Common Lisp over Bash Script as the Turing Complete Scripting Language of the shell! :-) One thing that I'll miss, at least until it's implemented, is tab-complete. As CL shells go, to the best of my knowledge, only clisp has tab-completion; and it probably isn't as refined as Bash's tab completion is! On Fri, Jul 27, 2012 at 3:24 PM, Ben Booth wrote: > OK, here's another idea, although it might be outside of the scope of a > lisp-reader: > > Dynamic languages such as perl or ruby have a feature where an attempt to > call an undefined function results in the interpreter calling a catch-all > function, called method_missing in ruby, and AUTOLOAD in perl. This > functionality would be extremely useful for a lisp shell scripting > language, so that if you attempted to execute a function that was > undefined, you could write the catch-all function to instead execute a > shell command using the function's arguments converted to strings, then > return the command's exit code. This would allow seamless mixing of > functions and shell commands. BASH does something similar to this-- you can > define functions that operate like commands. When BASH interprets a > command, it first checks to see if there's a matching function with that > name. If not, it tries to run it as a command. > > Like I said, this might be outside the scope of this project, and would > probably make more sense as a feature of the language instead of the > syntax. But it could conceivably be implemented as part of the reader, if > the reader were capable of keeping track of which symbols were defined and > undefined in any given context, similar to how a hygienic macro expander > works. If a catch-all function has been declared, a call to an undefined > function would be replaced with a call to the catch-all function. > > The benefit of this feature for a lisp shell would be seamless command > execution, without having to prefix the command with "run" or some other > function name. > > OK, enough crazy talk for now :) > > > -- > 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 > > -- 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] LISP as a BASH alternative?
>
> That said, we have a Scheme implementation; it's likely to be
> not-so-difficult to transliterate that into Common Lisp. Would you be
> interested?
>
Yes, I would be. I've tried my hand at writing an alternative reader in
the past, but it's been several months since I've worked on it. One of the
things I've wondered is how to replace the default Common Lisp reader with
my own.
I've also written hash-table pseudocode for bracket notation; it's a lot
nicer than Common Lisp's default hash-table syntax! (I haven't gotten to
the position, yet, where I would feel comfortable writing a "bracketaccess"
macro.)
On Fri, Jul 27, 2012 at 5:49 AM, David A. Wheeler wrote:
> Okay, I have sweet-expressions working as a shell scripting language. I
> did this by modifying "unsweeten" so that a leading ";#" and ";!" are
> generated without the semicolon.
>
> To try it out, just install scsh (Scheme Shell). Here's a simple
> "demo.sscm" file:
>
> =
> ;#!scsh -s
> ;!#
>
> run cat("README")
> =
>
> Process this with:
> ./unsweeten < demo.sscm > demo
> chmod a+x demo
> (This begs to be set in a makefile)
>
> Run doing:
> ./demo
>
> It's not Common Lisp, but it is certainly a Lisp.
>
> --- 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] global infix operators
One of the things that attracts me to this project is the theoretical
simplicity of it. Curly braces are a simple, elegant solution to the infix
issue--it provides a way to unambiguously define infix expressions, without
worrying about issues like precedence, or registering functions, or other
such nonsense. It is my understanding that previous attempts to add infix
to Lisp have severely clashed with macros, because of the complications
that come with precedence.
So the rejection of precedence isn't arbitrary, by any means...
Having said that, the idea of taking an infix list like {a + b * c} and
mapping it to (nfx a + b * c) is ingenious! It allows for the possibility
of including precedence, if it can be found to be compatible with Lisp
macros after all.
While I, for one, want nothing to do with precedence (I think one of the
things that makes s-exprs elegant is the lack of precedence), I think the
"nfx" macro idea is still beautiful: it will allow for the possibility of
converting something {a <= b < c} into an expression that can
short-circuit, yet produce the correct behaviour. If I recall correctly,
Python allows such constructs; in languages that don't, it just seems wrong
to have to type something like
if (5 <= a && a < 5) {do_something();}
but then, that's probably just because I'm a mathematician. :-)
Come to think of it, I don't know how many times I've had to wrap things in
parentheses, because I was either burned by behaviour I didn't expect
(mostly because of some obscure precedence rule), or because I didn't fully
understand the precedence rules (and I didn't want to be bothered with
figuring them out), or because I simply wanted to override precedence.
I've seen code written in *Python*, of all languages, that makes the
complaints against Lisp parentheses moot! (Having said that, I think
writing lists using whitespace instead of parentheses, or any delimiter for
that matter, is also good idea, because making indentation significant
works so well in Python.)
Another thought: I actually kindof like how Haskell allows you to define
operators, or use back-quotes to use an operator as infix (but, oh, how I
can imagine such conventions becoming a nightmare in Lisp!). I have a
little bit of experience trying to learn Haskell, but I haven't tried
Template Haskell, which allows for Haskell macros written in Haskell
syntax. Does anyone have experience with Template Haskell? If so, how
well do macro work with the precedence system?
(It is also my understanding that Dylan is a Lisp with infix notation, but
because precedence causes complications, writing macros in Dylan is rather
rare.)
Perhaps it would be a good idea to collect examples where having precedence
causes a macro to be more difficult to write than it otherwise would be.
Perhaps, if enough examples are given, we could even see how the
complications could be avoided...
On Fri, Jul 27, 2012 at 1:53 PM, David A. Wheeler wrote:
> Ben Booth:
> >
> > I have a (possibly controversial, possibly insanely stupid) feature
> request:
>
> Feel free to propose controversial and insane things! We're tackling
> something that people have claimed "can't be done", so we need
> out-of-the-box ideas.
>
> > So, curly infix is great because it's simple to understand, easy to
> implement, and retains homoiconicity. However, it would be *really* nice to
> be able to define infix operators that don't need to be surrounded by curly
> braces, as in haskell:
>
> I think that won't work at all, for same reasons that version 0.1 didn't
> work out so well.
>
> In version 0.1 of my "readable" approach, infix operators were
> automatically detected. In that case, it used function name patterns and
> an "escape" mechanism.
>
> Having to define the infix operators actually adds more complications; now
> you need to make sure that those operators are defined before you read
> something (whereas, if they are patterns built into the reader, that's not
> a problem). But the REAL nasty is, what happens when there are multiple
> language levels (which there often are)?
>
> In the base language, "*" may be an infix operator, but not in LANG1. In
> LANG2, "*" is an infix operator, but it's often embedded in LANG1. Oh, and
> their precedence levels are different. As well as their associativity.
> And, they're freely intermingled, and there's probably no way to tell the
> difference in the reader.
>
> Eeek.
>
> > (infixl 6 +++)
> > (infixr 7 *** ///)
>
> > And then all instances of +++, ***, and /// symbols would be treated as
> infix operators, no curly braces required.
>
> But that's a *problem*. That means that "+++" has to be treated as an
> infix operator, at THAT level, all the time.
>
> Also, I'm finding that the operators I might USUALLY use as infix (e.g.,
> "and') I sometimes use in prefix form. Having {} denote infix lists gives
> me that flexibility, and it turns out to be highly useful.
>
> > I am aware that what I am suggesting amounts
Re: [Readable-discuss] LISP as a BASH alternative?
This is actually a major reason I'm interested in Sweet-Expressions, myself. I'd like to use some form of Common Lisp as a shell, and it would be kindof awkward to have to use parentheses for everything. On Tue, Jul 24, 2012 at 7:11 PM, David A. Wheeler wrote: > Ben Booth: > > Hi, > >This is my first post to this mailing list. It's great to see that there > >is renewed activity on this project. > > I think so too. Welcome aboard! > > >I've been thinking about what a indentation-sensitive lisp-like language > >might look like for the last several years, although my attempts at > >writing a parser haven't produced any usable results yet. > > I know of a parser that you could try out :-). > > If you haven't yet, give our tutorial a whirl, which explains how to > download and try it out: > http://sourceforge.net/p/readable/wiki/Tutorial/ > > > What i find most interesting about readable S-expressions is the > > possibility of using a lisp-like language's REPL as an alternative to > > BASH and other shell-scripting languages. > > That's definitely a possibility. I don't plan to purse this right now, > but if anyone wants to give it a whirl, it should be an easy project to > implement. > > > ... Anyway, thanks for all the effort! This is a very useful and > interesting > > project that i will be following closely. > > Excellent! If you have ideas/suggestions, please post. Code or > documentation or website help would be appreciated, too. > > I have a TODO list here: > http://sourceforge.net/p/readable/wiki/TODO/ > If you or anyone else sees something you'd be willing to do, please let us > know! > > --- 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 > -- 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] A Random Syntax Thought
I wouldn't say "configurable" in the sense of "set a flag so that this function becomes that", so much as "configurable" in the sense of "trying to get the right syntax for the target Lisp". For example, while Arc, Scheme and Common Lisp are all Lisps, they each have different syntax. In some ways, it seems a shame to try to create a "sweet-expression" system that doesn't allow for the possibility of recognising these different coding traditions. For that matter, if I were to dust off a Symbolics Lisp Machine, and I decided I wanted to use "sweet-expressions" for programming the beast, it wouldn't be reasonable for me to start e-mailing this list, and saying, "But I can't use either of '!', '.' or '~' for my Lisp Machine. These are all reserved symbols! Why don't we use '_' or ':' instead?" (Let's not rule out the possibility of finding an ancient Lisp Machine being found in a Babylonian archaeological dig--in which case, a Cuniform non-whitespace character would be a given! :-) I suppose what I'm trying to say is that the rules ought to be separated from the implementation, so that if some weird system comes along, the "sweet-expression" syntax can use the same principles, when syntax is the issue. On Mon, Jul 23, 2012 at 12:19 PM, Kartik Agaram wrote: > Hmm, are you suggesting making the different characters configurable > so different languages can use say '.' or '!' to mean the same thing? > -- 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] A Random Syntax Thought
As we've been discussing syntax, it has occurred to me that perhaps we're getting a little too bogged-down in the details. This is most obviously seen with the "non-whitespace for whitespace" discussion, but I think it has affected the discussion of syntax, for better or for worse, since the first time David Wheeler started to think about sweet-expressions. And here's my random thought: while it's good to try to fit sweet-expressions into as many Lisp dialects as possible, it would be a very good idea to separate the ideas from the actual syntax. For example, most various Lisp dialects implement s-exprs, but they do so in a dizzying number of sometimes-incompatible ways. (Those that don't, like Dylan, are almost literally an expression of m-exprs, and have certain problems as a result.) Yet, s-exprs have a simple syntax, typically using parentheses and "." to define lists (McCarthy's "LISP 1.5" formally defines a s-expr as the form "(A . B)" where A and B are either a symbol or another s-expr), and having quote and quasi-quote syntax to manipulate s-exprs. If I recall correctly, (I've only read the first couple of pages of "LISP 1.5") McCarthy even uses square brackets instead of parentheses to define s-exprs; and I think Clojure uses different types of brackets interchangeably. (That's one thing I don't like about Clojure--I'd rather that a single bracket type mean one, and only one, thing, for consistency...and for maximum flexibility.) It would be useful if we could do the same with t-exprs: establish basic rules, that could then be encoded in a variety of syntaxes. Once the basic rules have been clearly defined, the syntax to implement them won't matter so much--and the implications of the rules can be explored in greater depth. Furthermore, once these basic rules are defined, syntax will only be an implementation detail, that could potentially change from one syntax to the next. I'm not sure what prompts me to feel that this should be an "urgent" concern...but I think it has something to do with seeing concerns about whether it would be easier to use ".", "!", or "~" for a non-whitespace indent character, based in part whether or not it would conflict with Arc; or using ".", "\", "\\" vs "..." for a GROUP concept, except that "..." may be incompatible with Scheme (I don't know for sure, since I've never studies Scheme, but it seems to be, based on code examples I've seen); for that matter, I even have a desire to create a new Lispy language, and where it would make no sense to use "." for whitespace in Common Lisp or Scheme, it might make a lot of sense in a language whose parser is being put together from the ground up. Also, having said all this, I think we're sort-of headed towards this direction when talking about "GROUP", "SPLICE", etc., concepts; and since we have a goal of having a new spec by July 31, I *certainly* don't think that "Separating Rules from Syntax" should be a goal for this particular spec--indeed, it could probably be written independently of the spec. :-) For that matter, such a spec would probably do well starting out discussing just what goes into a "classical" s-expr. (No matter how popular t-exprs become, I'm going to hazard a guess that it will always be useful to have a simpler "s-expr" concept to build on and to fall back on...) -- 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] Bundle of git changes
> > > > I dislike the name "modern-expressions" > > Can you propose some alternative names? > It was my understanding that "modern-expressions" was the name of the rule that transformed the standard s-expr (function arg1 arg2 arg3) into the sweet-expression form function(arg1 arg2 arg3) It is this naming convention that rubs me the wrong way; which is why I'd call these "functional expressions" instead of "modern expressions". I do not recall *exactly* how functional notation came to be, but I suspect that Leonhard Euler probably did a lot to standardise the notation into what it is today. (Euler seemed to do pretty much *everything*, though.) One problem I see is that one-letter names (like "c-expressions" for curly > infix, "m-expressions" for modern expressions, and "t-expressions" for > sweet expressions) don't really have the same "punch". I would expect that the entire project could still be called "sweet-expressions"; the purpose of the one-letter name is for convenience. Indeed, I wouldn't refer to something as a "t-expression", any more than I would something an "s-expression"--I'd sooner use the abbreviations "t-expr" and "s-expr". Technically, in my mind at least, "t-expr" is short for "tree-expression", which is convenient if you want to emphasise that the data structures we are dealing with are trees. (Technically, s-exprs are "tree-expressions", too, but that shouldn't matter in the naming convention, because one of the goals of the project is to make sure that any "s-expr" is also a valid "t-expr"--so s-exprs *ought* to be valid t-exprs!) Referring to "modern-expressions" as "m-exprs" would be problematic, because this name is already spoken for; we'd have to refer to them as "f-exprs". But then, I wasn't thinking in terms of naming different expressions according to the rules they used; I just expected each of the types to be different rules describing "t-exprs". Come to think of it, to what extent are we working on the problem that McCarthy started with, to produce "m-exprs"? I'm inclined to think that we're *sort-of* working towards that, but not really--after all, our goal is to create a system of s-exprs, just with a different expressional syntax. On Fri, Jul 20, 2012 at 1:24 PM, Kartik Agaram wrote: > > One problem I see is that one-letter names (like "c-expressions" for > curly infix, "m-expressions" for modern expressions, and "t-expressions" > for sweet expressions) don't really have the same "punch". > > > > What names would you propose for all 4 cases, and why? > > It might make sense to think about adoption for the umbrella name for > the project, and just use unambiguous jargon-y names for the three > tiers under it. If c/m/t expressions don't need to pull the weight of > increasing adoption, that might make the problem a little more > tractable. > > > -- > 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 > -- 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: Use "!" as an indenting character and drop "." entirely
I'm still kindof neutral on whether or not there should be a non-whitespace character that acts as a whitespace character. Even so, I'm also inclined to think that, since we're talking about Lisp, there's always a chance that somewhere, someone has written a function or macro that begins with a given character, *especially* if that character is ASCII and isn't considered a special character by Lisp. I the biggest challenge in trying to figure out a good non-whitespace-character to use as whitespace is that historically, ASCII has been the limit of what can be used in a computer language; and historically, what hasn't been whitespace, has been used, reused, and overloaded extensively in all sorts of languages, not just Lispy ones...thus, regardless the character, we would have to be prepared to provide an escape mechanism for it, if we wanted to use it as initial whitespace. Or, at least, regardless the ASCII character set. I'm sure we'd be able to find something in the Unicode Astral Planes that would work nicely...at least, until someone wants to write a program in Cuniform, and we just happened to co-opt one of the most useful characters for starting things in ancient Hittite! :-) On Fri, Jul 20, 2012 at 11:32 AM, David A. Wheeler wrote: > I propose that we drop "."+space/tab as an indentation character, and > instead, declare that a simple "!" is an indentation character JUST LIKE > space or tab. > > This is: > 1. Trivial to implement. unread-char goes away, the code is easier to > separate, etc. > 2. It's trivial to explain. > 3. It is *REALLY* great for highlighting ranges (better than "."), I think > it's far better than "." for this purpose. When dealing with > whitespace-killers like HTML it's okay, perhaps not as nice-looking as "." > but workable. > 4. Preserves the advantages of having a non-whitespace indent character. > > Details below. > > Thoughts? Comments? Like it? Hate it? Kindof neutral? > > --- David A. Wheeler > > > Alan Manuel Gloria said: > > Not if the indentation tracking finds a ".", then fails to see a tab > > or space after it. Then it's forced to have 2 characters overhead, > > which the modern-expr reader must read back to find the symbol or > > number that begins with "." > > I think the *look* of period+space/tab is nice, but the implementation > problems are getting to be rediculous. Leading period is *especially* > problematic in Scheme, since it can indicate a number *or* symbol, and a > "." by itself is the symbol used to quickly create improper lists. It > creates the need for a lot of gyrations, and a dependency on an unread-char > that isn't universally supported. > > But having a non-whitespace character for indent is turning out to be > remarkably useful: > 1. It's great when whitespace is dropped (e.g., HTML email) > 2. It's great for highlighting regions. > > We could use "~", but Arc uses leading "~" for not. In the cases where > you always put the condition after the word "if" this doesn't matter, but > since Arc has *alternating* condition / action syntax, I'd expect Arc text > to sometimes look like this: > if condition1 >action1 >condition2 >action2 >condition3 >action3 > ... > > We could use "!"+space/tab. That's actually a little better than "."; you > really need to hand off handling of "." to the underlying modern-expression > parser (because "." is complicated. I think we could isolate its > complications to the indentation processor if it's not a period, *without* > the lower-level reader needing to know. But it'd still create > complications in its implementation. Compared to the stark simplicity of > "! is an indenting character" it's breathtaking. > > This would obviously be slightly annoying to languages like wart, where > leading "!" has a meaning. But I think those cases are rare, and this only > matters if it's just after indentation... so: > if !myfunction(...) > could retain that meaning if desired. > > --- 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 > -- 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/_
Re: [Readable-discuss] Bundle of git changes
I have an odd suggestion for a naming convention for these things: call them "texprs", with submodules "curly-texprs", "whitespace-texprs", and "function-texprs". (I dislike the name "modern-expressions" because standard functional notation is rather old, which is what makes it seem so natural.) There are several reasons why I want to call these things "t-exprs". First, "t" comes after "s" in the alphabet, so it seems natural to call an augmentation, and potentially a second-generation, of s-exprs "t-exprs". This happens all the time in mathematics: x, y, and z for variables; z, w for complex variables (x and y are often taken by real and imaginary parts, and there's a need to "wrap around" as well); a, b, c for constants; f, g and h for functions; R, S, T for rings; p, q for prime ideals; and so forth. Second, I'd like to create a "cleaned up" version of Common Lisp someday, starting with "t-exprs"; I'd like to call the language "Treehouse" to give it an interesting name, and to emphasise the fact that its basic data structure is trees, made out of lists. (The motivation behind this is the article "The Nature of Lisp", http://www.defmacro.org/ramblings/lisp.html, as well as a desire to find a "hip" name for the language--everyone likes treehouses!) Third, "s-exprs" is short for "symbolic expressions"; "m-exprs" is short for "meta expressions"; when we call these things "sweet-expressions", what's an appropriate abbreviation? Perhaps "sw-exprs" would do, or just "w-exprs", or even "t-exprs" for "sweeT-EXPRessions". I don't know how many times I wish I could have said "t-exprs" instead of "sweet-expressions" in an e-mail. As an observation, since the goal is for these things to be readable, it wouldn't hurt to call them "r-exprs", short for "readable expressions"; this last name would also fit nicely in the alphabet scheme, even though "R" comes before "S". (And yes, that has a lot of tradition in mathematics, as well--usually when you run out of letters.) Having said that, I'm still partial to the term "t-exprs". On Fri, Jul 20, 2012 at 11:13 AM, David A. Wheeler wrote: > Kartik Agaram: > > > > "readable" seems generic. How about 'sweetexpr'? > > The problem is that sweet-expressions are only one of 3 tiers. Some > people will not adopt the whole tier, but if they can accept curly-infix, > that's still an improvement. I very much intend for people to be able to > adopt any one of the 3, to the extent we can. Besides, the name of the > whole project is "readable" anyway. > > I suggest this nomenclature: > * "readable" = the name of this overall project > * "readable-discuss" = the name of this mailing list > * "readable Wiki" = the name of this project's Wiki > * "read" = the name of the Scheme/CL/etc. function we're trying to > replace. R6RS thinks it's called "get-datum" :-). > > --- 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 > -- 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] The "." as indentation whitespace proposal
First of all, I want to make it clear that I'm not completely opposed to
using "." as an option for indentation.
Having said that, I think your examples are flawed; the logic of your
example is difficult to follow. I also don't think you're using COND
correctly--but that could just be me, because I'm an inexperienced Lisper,
but I'm coming from a Common Lisp background.
I've tried to re-write this as a classical s-expr, and I got this:
(cond
((expr1? f) (let ((var (list-of x
({t in '(1 2 3 4)}
(pred? t)
{x in range-of(0 t)})))
(var2 (kitty ('meow) ('meow
(execute
((foo var))
((quux var2)
((expr2? f) (progn (kitty
('niaw)
(expand-upon('niaw)))
(woorf f)))
(#t (error "bobcat: NYAWR")))
Then I've re-written this as a sweet-expression:
cond
exprl?(f) \\ let
\\ var list-of(x
({t in '(1 2 3 4)}
pred?(t)
{x in range-of(0 t)}))
var2
kitty
'meow
'meow
exprl2?(f) \\ progn
kitty
'niaw
expand-upon('niaw)
woorf(f)
#t \\ error("bobcat: NYAWR")
I think my implementation is also flawed--again, the problem centers around
COND--because I don't think my re-write correctly wraps the conditions with
the correct results. From this, I have the following observations and
questions:
-- How do we pair up two lists on a single line? If I understand
correctly, the '\\' SPLICE context creates two lists, where we would expect
one list. Does it also wrap up the two lists in a single parent list?
-- What happens when we have a sublist indent after a line with a '\\'
SPLICE? Does it become a sublist of the last list of the SPLICE?
-- I think using a '\\' is better than a single '\' is better, because it
is more visually appealing.
-- To get to the bottom of the issue of whether it is valuable to admit "."
as whitespace, I think we need real code examples. While coming up with
fake examples can be informative (I hadn't thought about the implications
of "\\" splice and following sublists...), ultimately, they are also
dangerous, because they don't represent actual code, and how it might be
naturally written.
-- I'm still on the fence with this, although one compelling argument *for*
the convention involves my experience with Python: when I'm desperate
enough to replace all the " " indents with "--|" or ". " (or something
just as heavy), it eliminates the possibility of cutting snippets of Python
and pasting it into an REPL. Of course, Python, with its tradition of
including ellipses before every line in its REPL, makes it more difficult
to cutting snippets from the REPL and pasting it into an editor--and
impossible to paste *back* into the REPL.
-- I think this example also shows that using two spaces for indentation,
when whitespace is significant, can also be difficult to read. In using
Python, I tent to prefer three spaces, but when the editor defaults to
four, I don't fight it (and it's probably better too); and there are
certainly times where a LOT of indentation clears things up really quickly!
On Thu, Jul 19, 2012 at 3:03 PM, Alan Manuel Gloria wrote:
> On Fri, Jul 20, 2012 at 12:03 AM, Alpheus Madsen
> wrote:
> >> Certainly using "--|" is very heavy, but the point of using . is that it
> >> is much lighter visually.
> >
> >
> > Just for clarification: I've never used "--|" in a language as
> "official"
> > syntax; I've used it (and variations of it) in Python and PHP when I
> really
> > needed to see the structure.
> >
> > Come to think of it, there is Emacs code out there that can color-code
> the
> > levels; I have never tried using it, though.
>
> My argument still stands, though: sometimes the tool isn't there.
> There's something to stuff that just works with plain text.
>
> "." is the lightest syntax that is still typeable on the standard
> keyboard: the period is the character with the smallest canonical
> graphical representation that is typeable on a majority (all?) of
> keyboards.
>
> So: I'd like to know, if you think:
>
> cond
> expr1?(f)
> let
> \\
> var
> list
Re: [Readable-discuss] The "." as indentation whitespace proposal
> > Certainly using "--|" is very heavy, but the point of using . is that it > is much lighter visually. > Just for clarification: I've never used "--|" in a language as "official" syntax; I've used it (and variations of it) in Python and PHP when I really needed to see the structure. Come to think of it, there is Emacs code out there that can color-code the levels; I have never tried using it, though. On Wed, Jul 18, 2012 at 3:33 PM, Alan Manuel Gloria wrote: > On Thu, Jul 19, 2012 at 2:45 AM, Alpheus Madsen > wrote: > > Third, I'm not sure I like the idea of using "." for indentation. While > it > > helps to clarify the structure, it can also clutter the visual > presentation > > of the source code. I like the fact that word processors allows for > ways to > > toggle visual whitespace (certainly Kate, and probably Vi and Emacs); and > > sometimes I'll do a formal search and replace between " " and "--|" and > > back, when I need a better handle on the structure...but those are > editing > > functions, and I'm not sure if it would be a good idea to have these > things > > formally in the source code. > > You don't always get to use a text editor with that. Consider a long > piece of indentation-sensitive code that you're viewing online on say > github or sourceforge - or just plain FTP for that matter. I think it > would be much better to actually give small amounts of "." in > strategic places to give a better view. > > You don't have to use it all the time - "." as indentation is > optional. Certainly using "--|" is very heavy, but the point of using > . is that it is much lighter visually. It's meant to suggest thin > lines as you would put them on a printout, in order to view the > structure of the code without adding any particular meaning. > > > -- > 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 > -- 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] Arne Babenhauserheide proposal: use "." on own line instead of "group"
>
> Is 'group' really going to be easier to understand than enabling
> whitespace-sensitivity inside parens? I think that's a good test if
> we've decided the latter is too complex.
>
> Also, using backslash for any meaning is butt ugly.
>
I don't completely agree with your sentiments; in part, because adding
significant whitespace is bound to change the language significantly, so
adding a symbol or two here or there isn't a concern for me.
Oddly enough, I kindof like the idea of GROUP; I just don't like the
current syntax.
In my modest attempts to write my own whitespace parser, though, I find
that turning off whitespace in brackets simplifies implementation; it's
also useful for creating long lists without a "continue to next line"
character; and since a goal of the project is to preserve s-expr
compatibility, turning off whitespace significance in brackets is rather
important!
If we were designing a language from scratch, I'd be a little more open to
leaving significant whitespace on in brackets, and breaking s-expr
compatibility. But the project has an even more important goal (and one
that attracts me to this particular project): to prove the isomorphic
nature between s-exprs and sweet-expressions, particularly with
compatibility with macros. This is an important reason why operator
precedence is, in particular, something to avoid as much as possible.
Besides, I really like the simplicity of s-exprs; the way I see it, the
goal of sweet-expressions is to prove that we can have
infix-yet-syntax-free, whitespace-significant s-exprs. (With this goal in
mind, of course, sweet-expressions had better be just as elegant!)
> Arc, if I understand correctly, uses "\" to separate two lists on a line.
>
> Perhaps we're thinking about different Arcs? http://arclanguage.org is
> not whitespace sensitive at all. (It does not use backslash --
> otherwise I wouldn't be using it :)
No, we're thinking about the same Arc; it was my understanding from reading
the list that Arc uses "\" in certain contexts, and certain
sweet-expressions are trying to preserve the idioms.
I may be wrong, though: perhaps the Arc idioms in discussion are of the
form
(list 1 2 3) (list 4 5 6)
which, for sweet-expressions, would be
list 1 2 3 \ list 4 5 6
(I am probably getting even this example wrong).
Also, using backslash for any meaning is butt ugly.
>
I would partially disagree with this; but I'm willing to put up with it in
certain contexts. It's an idiom in several languages, for example,
including Bash and Python, to put a backslash at the end of a line; in
Python, though, I find it ugly enough that I usually try to wrap something
in parentheses (which turns off significant whitespace) than resort to
ending a line with a backslash.
For separating two lists on a single line, however, it isn't that bad of an
idea.
In many languages, using the backslash is a good way to escape characters;
since Common Lisp is one such language, and it's used for escaping
characters in symbols, using the backslash for other things is problematic.
And I *really* like how Haskell uses the backslash for lambda expressions!
I like it so much, I really wish we could use it in Common Lisp!
Perhaps it wouldn't be too much trouble to recognise when something is of
the form
\((x) {x + 5})
and translate it into
(lambda (x) (+ x 5))
as it is, I think that the current form,
lambda((x) {x + 5})
would be rather clunky. At the very least, Paul Graham gave us the
possibility of
fn((x) {x + 5})
> Modulo my reservations about group, this is my favorite idea so far.
> But it also screams to me that we could just use parens. It might help
> the discussion if we always use a complex example that we think
> *requires* group.
Here's an example taken from
"http://sourceforge.net/p/readable/wiki/Examples/
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
I've been trying to keep up with the activity that's been going on this
past month; but since I've been busy doing other things as well, I think I
failed. Even so, I've tried to review everything, and so I'd like to share
some thoughts.
First, I'm not sure what the status of "\" is; or how it currently fits in
with the proposed GROUP, SLICE, etc semantics. (I don't fully understand
those semantics, but I suspect that they'll be cleared up in the 0.3
Spec...if I understand correctly, though, these are the names of how "\"
has been proposed to be used.)
On the one hand, I like using "\" as a way to end a line; using it to
separate two lists seems kindof reasonable. I'm not sure if using it as a
replacement for "group" will fix things.
On the other hand, using "\" in this overloaded way can potentially be
confusing. Since the different contexts are mostly orthogonal to each
other, this isn't likely to be too much of a problem...except that the
biggest clash will be in the fact that "\" is also Common Lisp's Escape
Character. Indeed, it is because of this that I couldn't see how to
comandeer Haskell's use of "\" as lambda. As much as I like it, I'd more
likely use Paul Graham's "fn" instead. (Like "group", I think "lambda" is
an over-handed keyword for an important, simple concept.)
Which gives me an idea that would further overload "\": If it isn't too
complicated, we can define \(...etc...) to be lambda! (I have the sneaky
suspicion that Common Lisp will make this too complicated, though...)
About a week ago, as I was thinking about the GROUP issue, I had the idea
to use an ellipses in the following manner:
let
... x 10
y 12
{x + y}
This would be equivalent to (and compatible with)
let
...
x 10
y 12
{x + y}
That is, the ellipses designates a group; if anything follows the ellipses
on the same line, it's considered a list in and of itself; any sublist
contained in the ellipses would be "appended" to the original ellipses.
This would be simpler to implement than the other idea I proposed, which
was to have a series of ellipses, like so:
let
... x 10
... y 12
{x + y}
The reason this is a concern with me, is that one of the reasons I consider
GROUP to be "heavy-handed" (besides being a long name) was that it
introduced an extra line that I consider unnecessary.
Of course, this semantic would work just as well with GROUP, or ".", or
even "\", or perhaps even something like "::", as it would for ellipses;
I'm just partial to using ellipses myself.
Second, one of the thoughts I've been having lately, is a concern about the
attempt to be compatible with as many Lisps as possible. While I think
this is a useful concern--indeed, it allows sweet-expressions to be tested
in a variety of environments--it can also hamper a good idea, if not used
cautiously. For example, if using "\" in its various contexts is a good
idea, the fact that Common Lisp hampers it by using "\" as an escape
character shouldn't result in its complete rejection. (It may, however, be
one of several valid reasons to eventually reject the character for
something different.)
This concern goes both ways: Arc, if I understand correctly, uses "\" to
separate two lists on a line. If this is a good idea (and I tend to think
it is), then it should be kept; if it becomes clear that it's awkward,
though, the concept should be rejected, with a special exception being made
for Arc for compatibility reasons.
Indeed, since no two Lisp variants are strictly compatible with each other,
trying to come up with a sweet-expression spec that's fully compatible
between every variant may even be impossible!
Third, I'm not sure I like the idea of using "." for indentation. While it
helps to clarify the structure, it can also clutter the visual presentation
of the source code. I like the fact that word processors allows for ways
to toggle visual whitespace (certainly Kate, and probably Vi and Emacs);
and sometimes I'll do a formal search and replace between " " and "--|"
and back, when I need a better handle on the structure...but those are
editing functions, and I'm not sure if it would be a good idea to have
these things formally in the source code.
So, these are some of my thoughts concerning these proposals. I hope they
prove to be useful!
On Sun, Jul 15, 2012 at 7:42 PM, David A. Wheeler wrote:
> Alan Manuel Gloria:
> > Actually, I think I very much prefer the "\".
>
> I think your visual argument is sound. I particularly appreciate that you
> divided up the issue into different use cases, that makes it much easier to
> follow.
>
> BUT. What concerns me is that "\" is already taken by Common Lisp, and I
> recall that some other Lisps have done the same. Per the Common Lisp
> hyperspec spec:
> http://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm
> A "\" followed by space would begin a symbol whose name begins with space,
> by definitio
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
I've been trying to keep up with the activity that's been going on this
past month; but since I've been busy doing other things as well, I think I
failed. Even so, I've tried to review everything, and so I'd like to share
some thoughts.
First, I'm not sure what the status of "\" is; or how it currently fits in
with the proposed GROUP, SLICE, etc semantics. (I don't fully understand
those semantics, but I suspect that they'll be cleared up in the 0.3
Spec...if I understand correctly, though, these are the names of how "\"
has been proposed to be used.)
On the one hand, I like using "\" as a way to end a line; using it to
separate two lists seems kindof reasonable. I'm not sure if using it as a
replacement for "group" will fix things.
On the other hand, using "\" in this overloaded way can potentially be
confusing. Since the different contexts are mostly orthogonal to each
other, this isn't likely to be too much of a problem...except that the
biggest clash will be in the fact that "\" is also Common Lisp's Escape
Character. Indeed, it is because of this that I couldn't see how to
comandeer Haskell's use of "\" as lambda. As much as I like it, I'd more
likely use Paul Graham's "fn" instead. (Like "group", I think "lambda" is
an over-handed keyword for an important, simple concept.)
Which gives me an idea that would further overload "\": If it isn't too
complicated, we can define \(...etc...) to be lambda! (I have the sneaky
suspicion that Common Lisp will make this too complicated, though...)
About a week ago, as I was thinking about the GROUP issue, I had the idea
to use an ellipses in the following manner:
let
... x 10
y 12
{x + y}
This would be equivalent to (and compatible with)
let
...
x 10
y 12
{x + y}
That is, the ellipses designates a group; if anything follows the ellipses
on the same line, it's considered a list in and of itself; any sublist
contained in the ellipses would be "appended" to the original ellipses.
This would be simpler to implement than the other idea I proposed, which
was to have a series of ellipses, like so:
let
... x 10
... y 12
{x + y}
The reason this is a concern with me, is that one of the reasons I consider
GROUP to be "heavy-handed" (besides being a long name) was that it
introduced an extra line that I consider unnecessary.
Of course, this semantic would work just as well with GROUP, or ".", or
even "\", or perhaps even something like "::", as it would for ellipses;
I'm just partial to using ellipses myself.
Second, one of the thoughts I've been having lately, is a concern about the
attempt to be compatible with as many Lisps as possible. While I think
this is a useful concern--indeed, it allows sweet-expressions to be tested
in a variety of environments--it can also hamper a good idea, if not used
cautiously. For example, if using "\" in its various contexts is a good
idea, the fact that Common Lisp hampers it by using "\" as an escape
character shouldn't result in its complete rejection. (It may, however, be
one of several valid reasons to eventually reject the character for
something different.)
This concern goes both ways: Arc, if I understand correctly, uses "\" to
separate two lists on a line. If this is a good idea (and I tend to think
it is), then it should be kept; if it becomes clear that it's awkward,
though, the concept should be rejected, with a special exception being made
for Arc for compatibility reasons.
Indeed, since no two Lisp variants are strictly compatible with each other,
trying to come up with a sweet-expression spec that's fully compatible
between every variant may even be impossible!
Third, I'm not sure I like the idea of using "." for indentation. While it
helps to clarify the structure, it can also clutter the visual presentation
of the source code. I like the fact that word processors allows for ways
to toggle visual whitespace (certainly Kate, and probably Vi and Emacs);
and sometimes I'll do a formal search and replace between " " and "--|"
and back, when I need a better handle on the structure...but those are
editing functions, and I'm not sure if it would be a good idea to have
these things formally in the source code.
So, these are some of my thoughts concerning these proposals. I hope they
prove to be useful!
On Sun, Jul 15, 2012 at 7:42 PM, David A. Wheeler wrote:
> Alan Manuel Gloria:
> > Actually, I think I very much prefer the "\".
>
> I think your visual argument is sound. I particularly appreciate that you
> divided up the issue into different use cases, that makes it much easier to
> follow.
>
> BUT. What concerns me is that "\" is already taken by Common Lisp, and I
> recall that some other Lisps have done the same. Per the Common Lisp
> hyperspec spec:
> http://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm
> A "\" followed by space would begin a symbol whose name begins with space,
> by definition
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
On Wed, May 23, 2012 at 9:54 AM, David A. Wheeler wrote: > Alpheus Madsen > > This is a problem I've thought about myself. I'm not sure if I like > Arne's solution, though, because a period is almost too small, but I would > agree that group is rather clunky too. > > Agree. > > > One thought I've been wanting to experiment with, but haven't had the > time to attempt to implement, is to use a double-indent to indicate groups. > > I think that's even worse. It's very unreadable. It's also ambiguous for > the first indent; does "two spaces" mean an indent of two spaces, or a > double-indent for one-space indenting? > > Perhaps another symbol would make sense, but that list is small. The > obvious one is "\" on a line by itself. > > --- 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] Arne Babenhauserheide proposal: use "." on own line instead of "group"
This is a problem I've thought about myself. I'm not sure if I like Arne's solution, though, because a period is almost too small, but I would agree that group is rather clunky too. One thought I've been wanting to experiment with, but haven't had the time to attempt to implement, is to use a double-indent to indicate groups. For example, let group a b do-stuff would become let a b do-stuff I kindof like this solution, although I haven't experimented enough with it yet to be sure...I suspect it has its own potential pit-falls for readability, though. For one thing, the smaller the indent, the less likely it would be to be readable. I'd suspect that three spaces would be a minimal requirement, perhaps even four, although I understand that for Lispers, two-space indents are sometimes popular. Sincerely, Alphy Madsen. On Mon, May 21, 2012 at 9:56 AM, David A. Wheeler wrote: > Here's an interesting idea from Arne Babenhauserheide. > > It's a fair point. The only reason that I used "group" was because this > made it compatible with a previous proposal. > > Comments? > > --- David A. Wheeler > > > - Start Original Message - > Sent: Mon, 21 May 2012 17:11:20 +0200 > From: Arne Babenhauserheide ( arne_bab at web dot de...) > To: dwhee...@dwheeler.com > Subject: sweet expressions and group (xyzzy) > > > Dear David A. Wheeler, > > > > I read your sweet expressions work and I liked it very much - except > > for the group keyword as replacement of ((. > > > > Reason: I dabbled with expressionless-lisp myself, though only on > > paper, with elisp in mind and limited experience with other lisps > > > > What I love about indentation-sensitive programming is that it is > > possible to reduce the syntax to the bare necessities for > > understanding the code. With the group-keyword you use a pretty heavy > > identifier for (( - its actually heavier than the orgininal syntax. > > > > The alternative I came up with is a . on its own line. It is the > > syntax-element which is already used and which does not normally > > appear in front of lists. > > > > The . as infix creates a cons-cell, and it seems that it (. a) simply > > is a, so it seems nonsensical to me to use (. ( anywhere. > > > > To use the common let syntax as comparision: > > > > With groups it looks like this: > > > > let > > group > > a b > > > > With a dot it changes to: > > > > let > > . > > a b > > > > This makes the syntax much lighter for the reader while still clearly > > marking the double-brackets. > > > > but as with everything, just treat this as an idea. I really like > > your sweet-expressions work! > > > > Best wishes, > > Arne > > > > PS: I normally write in Python and love it, but I also see the power of > lisp (mainly through customizing my emacs), so I wish it were easier to > read. > > > > - End Original Message - > > > -- > 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 > -- 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] sweet-exprs for Common Lisp
I would like to use Common Lisp as a shell prompt, and at some point
I'd like to load up Common Lisp as the operating system for a
computer; thus, I was looking for something that would allow me to
create lists by indentation. As I searched, I stumbled on
"sweet-expressions"...and so far, I like what I see! (Up to this
point, my only concern was to do indentation; at the time, I wasn't
even worried about infix notation).
In my reading, however, I've learned that sweet-expressions aren't yet
available for Common Lisp, except for the infix operator. In the
sweet-expr tutorial, if I remember correctly, you stated that the
reader would probably have to be re-written. I would like to do this,
even though I am new to Lisp.
To do this, though, I have two questions: where can I find an
explanation of what the current reader does, so that I could make sure
it does what it's supposed to do? And when will I find the time to do
this? (I know you don't have an answer to the second question, but if
you could e-mail me the spare minutes you find here and there, it
would be appreciated :-).
In the meantime, I will be working on something in Python and XML;
I'll likely try to use sweet-expressions to at least simplify some of
the XMLish stuff I'm working on.
I also wanted to chide you a little bit: in a certain e-mail
discussion, you stated that prefix notation is unnatural, when
actually, it's perfectly natural: consider f(x, y)!
Having said that, I also think that the spite that the Common Lisp
community seems to have towards things like sweet-expressions is a bit
unfounded, for three reasons:
1. Common Lisp *already* has an infix operator:
(1 . 2)
2. Common Lisp has at least *three* functions written as standard f(x
y) notation:
'(a b c) => (quote (a b c))
`(a ,b c) => (backquote (a (evaluate b) c))
3. In exactly the same way that C uses indentation to indicate
structure, Common Lisp does as well; thus, just as it makes sense to
remove the brackets from C to get Python, it makes sense to remove the
parentheses from Common Lisp.
So long as your goal is to make the results 100% compatible with
s-exprs, I can see no reason why these types of changes shouldn't be
generalized. Or should we insist that quote be used as (' (a b c))
instead, for consistency?
Having said that, I think I'll avoid the wrath of the Common Lisp
community and just call my new language "Treehouse" (because the
fundamental datastructure is trees :-) and rename sweet-expressions as
"tree expressions" or t-exprs for short. (Technically, my ultimate
goal would be to create a "simplified" Common Lisp, with a simple
core, separate standard libraries for things that would bring the
language up to the CLtL standard, and "declared" standard libraries
for things like sockets, files, etc...so I'd be justified in calling
it by a new name--if I ever get around to it! :-).
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
