My toy lisp now supports a homoiconic infix. It divides up the range
of valid symbol characters between operators and regular symbols.
Operators can be called in either infix or prefix. You can create your
own operators. Precedence is by whitespace rather than operator,
enabling things like:
(*
http://sourceforge.net/p/readable/wiki/Precedence/
Lol.
Was this conversation really as recent as the wiki pages suggest? I
don't recall any threads about precedence recently -- especially with
Alan expleting :)
--
Well, you never *have* to use curly-infix. If you want to use prefix for
some expression, you can always do so.
Yeah.
I totally appreciate why operators require spaces around them, and I
am still[1] anti-precedence. Just thinking aloud about how different
language mechanisms can interact in
git://github.com/AmkG/letterfall.git
Sweet!
I tried the following:
$ git clone git://github.com/AmkG/letterfall.git
$ ./autoeverything 1
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe
It's not a style I would usually use for variables. But that's a style thing;
nothing in curly-infix *requires* these kinds of variable names.
Of course.
Though, now that you mention it, it occurs to me that there's a more
general criticism of infix. Things like this are confusing:
(Ack, meant to include the list.)
That's a choice I made deliberately. It would be possible to use commas, but
then you HAVE to use them everywhere.
Yeah. I was just thinking aloud. I am totally fine keeping variable
names short :)
On Sat, Aug 25, 2012 at 7:24 PM, David A. Wheeler
Actually, there was a short one before, but I've greatly expanded it to this:
That is quite comprehensive, thanks.
It might still be hard for newcomers to read because of the forward
references. Hmm. One idea might be to move the explanation for (. e)
after introducing sweetexprs; that might
1. I see tutorial.md mentions it requires guile. Perhaps README should
say so as well? Or we could centralize the info somehow..
2. On my debian-based system configure fails:
configure: error: guile-config required but not found
I'm not sure where to find guile-config (debian seems to not
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
My immediate reaction is positive, in spite of potential conflict with
wart. It evokes a diff format.
I can't think of any situation where not x will be at the left edge,
so perhaps wart's rule could be: After a newline skip any immediate
bangs.
readable seems generic. How about 'sweetexpr'?
The problem is that sweet-expressions are only one of 3 tiers.
There's lots of precedent for a broad category to have the same name
as a sub-category. Like 'cat'. We don't have to be perfectly
consistent in choosing names, only in using them.
I'm
f-expressions sounds like f*n-expressions, which is not the association I'm
looking for :-).
Also, fexprs are a real thing in lisp's history.
--
Live Security Virtual Conference
Exclusive live event will cover all the
There have been dozens of Lisp-based programming languages that started with
that premise, starting with McCarthy's M-expressions.
But I think my proposal hasn't been tried before: a single consistent
set of primitives that map 1-1 to various lisp dialects.
You wouldn't be able to translate a
How do we express the usage of [such macros] using the Unified Syntax for
Indented Lisp?
I'm hoping that if the unified syntax takes hold then people will tend
to just define their own macros differently.
There's the obvious workarounds, of course, like defining my-and-let*
that massages
It looks at the port... and sees a space!! Oh noes!! Someone has
just indented the first line! Okay, let's count the first line's
indent... two spaces. Let's pretend that this is the 'left edge'..
let's go to the next line... oh noes! It's got one space for indent -
it's managed to go
First read(): Reads foo, bar, and it consumes the indentation of eggs so
that it can determine that another is at the same level. It returns (foo
bar).
Ah yes, this bug actually took me *forever* to understand in wart :)
This also helps me understand the other discussions here about
define-syntax list-of
syntax-rules (is in)
; base case
\
. list-of x
. \ list x
; handle (var in x) clause
\
. list-of x
. var in expr
. clauses \ ...
. \ concatenate
. . map
. . lambda (var)
. . list-of x
.
1. I'm making heavy weather of the difference between SPLIT and SPLICE at
http://sourceforge.net/p/readable/wiki/Current
2. I think I can come to terms with GROUP (as long as it doesn't have to be
on a line by itself), but I don't like SPLICE. The example given is in arc:
if
cond1() \ expr1()
ii) An indentation-sensitive lisp like wart requires mentally
inserting parens to make sure we aren't accidentally wrapping
something we didn't mean to.
People indent even when it's *not* significant, so this turns out to be a
non-problem. The indentation ends up working with, not
Alan, would you really prefer SPLIT/SPLICE to just combining clauses with
the previous line when writing (
http://article.gmane.org/gmane.lisp.readable-lisp/367)?
. list-of x
. var in expr
. clauses \ ...
vs
list-of (var in expr) clauses ...
David Wheeler
b) Should we really have to insert a backslash in empty lines?
The use case is when you .. you copy-paste a file's contents into
the REPL.
a) In practice top-level forms tend to be separated by lines anyway in
files.
b) A smart repl could notice when a line is at the same indent as the
Well, all the examples I make are as how I would write them
Ah, thanks for the clarification!
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has
\
. list-of x
. . list x
===
(
(list-of x
list x))
Would:
\
. list-of x
. list x
be correct?
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat
. is just whitespace.
Ah, of course :/ I'm having trouble holding that in my head.
Getting rid of periods, I'm still having trouble understanding why the
second line isn't wrapped in parens in:
\
a
b c
Shouldn't this be ((a (b c)))?
SPLIT *between* symbols is one of those things that is not needed in many
cases, but in those few cases where you want it, you REALLY want it.
Absolutely. But if it's an uncommon use case then I'm less concerned
about what y'all choose.
Unfortunately, Alan's response suggests I'd end up
http://sourceforge.net/p/readable/wiki/Solution
many Lisps already do this, and this provides a simple escape mechanism..
It doesn't work on racket or sbcl, just guile. Any others?
--
Live Security Virtual Conference
I split up the sweet-expression description so that there are 2 main rules,
followed by a list of refinements.
Appended below is my stab at the sweet expressions section.
I've separated out the tutorial from the spec. I would like for
tutorial forms of the problem and solution to go right on
Now that I've started playing with the text myself, my value to this
group will start to drop for giving feedback as an outsider :)
Too late! You're no longer an outsider. :-).
:) Thanks.
Lately I've been thinking a lot about about insiders and outsiders.
'Outsider' has a slightly negative
Should we change all /bin/env to /usr/bin/env? What platform are you using?
This was on a laptop running linux (http://www.linuxmint.com/download_lmde.php)
I've only ever seen /usr/bin/env. The wikipedia article makes no
reference to /bin/env except to say OpenServer and Unicos use it. What
Why not just myfunction(:option1 f(a), :option2 g(b), :option3 h(c))?
Or is there an issue with commas?
Yes, comma means unquote. In addition, comma-whitespace is used in
indentation processing to mean that the inner expression of the
unquote is also processed using indentation processing.
Ok, you've persuaded me not to mess with commas :)
--
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.
We could have leading-SPLIT always be a comment marker, even when indentation
is disabled. But I think there's no need; once indentation processing is
disabled, you can indent however you please, and there's no need for a
special symbol.
My ':' wasn't intended to help reduce parens. It
https://sourceforge.net/p/readable/wiki/Solution/
A leading quote, comma, backquote, or comma-at, followed by space or tab, is
a list with that operator and the following expression.
Of course, if you think that's a bad idea, then let's discuss! This is
straight from SRFI-49..
It's not
(Send this just to David by accident; resending to all)
The spec is (currently) at:
https://sourceforge.net/p/readable/wiki/Solution/
I think you're looking at the wrong file. The version02.html file is
obsolete; that's mainly useful if you want to see historically where we came
from.
I just found out about this list (thanks Alan!) and am going to go
read through the archives. In the meanwhile I wanted to share the
whitespace-sensitive lisp I've been working on. You can read about the
design choices I made at:
http://github.com/akkartik/wart#readme
I'd love feedback and
BTW I haven't ever considered adding syntax at the start of a line.
The only place I've seen this idea before is vimscript
(http://vimdoc.sourceforge.net/htmldoc/repeat.html#line-continuation).
Is a backslash at the start of each line really less alien to
non-lispers than a few extra parens?
Also, has there been discussion of the haskell approach?
a) Explicitly mark certain ops as infix. That would eliminate a lot of
curlies, and also allow any op to be infix.
b) Allow any op to be temporarily infix by enclosing it in backticks
or something like that. Maybe curlies?
matrix1
37 matches
Mail list logo
