Kartik Agaram:
> While we're throwing out wild and whacky ideas, here's one I've been
> mulling for a few days.
>
> You know how the lisp evaluator reads a list, evals all the elements,
> passes the cdr as arguments to the car? Forget all that.
Lisp has always let you write your own evaluator. T
Ben Booth:
> I agree that curly infix is definitely simpler to understand and implement.
> I guess I'm just thinking about the use case of sweet-expressions lisp for a
> shell scripting language. I would rather be able to type this:
> $ cat file1 file2 file3 > outputfile
> than this:
> $ {(cat
While we're throwing out wild and whacky ideas, here's one I've been
mulling for a few days.
You know how the lisp evaluator reads a list, evals all the elements,
passes the cdr as arguments to the car? Forget all that. New rules:
a) Adjacent expressions = function application.
factorial 5 =>
> I agree that curly infix is definitely simpler to understand and implement.
> I guess I'm just thinking about the use case of sweet-expressions lisp for a
> shell scripting language. I would rather be able to type this:
>
>> $ cat file1 file2 file3 > outputfile
Ah, this motivation makes a lot of
On Fri, Jul 27, 2012 at 4:53 PM, Kartik Agaram wrote:
> > {{{+ 1 l} {- 1 l} {* 2 l} {/ 2 l} {= 0 r}}
> >x = 5 * 3 - 2 + 1
> >y = x * 3 + 2}
>
> Wouldn't this always be strictly more verbose than just inserting
> parentheses? If the goal is readable notation it doesn't seem much of
> a win
> {{{+ 1 l} {- 1 l} {* 2 l} {/ 2 l} {= 0 r}}
>x = 5 * 3 - 2 + 1
>y = x * 3 + 2}
Wouldn't this always be strictly more verbose than just inserting
parentheses? If the goal is readable notation it doesn't seem much of
a win.
It seems to me that we need to engage in these contortions because
Ben Booth:
> Here's a quick example of how this could be implemented. I'm going to
call this "extended curly infix" notation:
{{{+ 1 l} {- 1 l} {* 2 l} {/ 2 l} {= 0 r}} x = 5 * 3 - 2 + 1 y =
x * 3 + 2}
So the syntax is a bit like (let ...), each operator gets associativity
and precedence values
> The "sweet-run" program processes the rest of the file through "unsweeten"
> and runs it. Here's an example of using it, in this case to use scsh:
+1!
--
Live Security Virtual Conference
Exclusive live event will cove
Or alternatively, you could omit the precedence and associativity, and have
the precedence be determined by the order that the operators are given, and
default to left associativity:
{{+ - * / =}
x = 5 * 3 - 2 + 1
y = x * 3 + 2}
Ben
On Fri, Jul 27, 2012 at 3:38 PM, Ben Booth wrote:
> Her
Here's a quick example of how this could be implemented. I'm going to call
this "extended curly infix" notation:
{{{+ 1 l} {- 1 l} {* 2 l} {/ 2 l} {= 0 r}}
x = 5 * 3 - 2 + 1
y = x * 3 + 2}
So the syntax is a bit like (let ...), each operator gets associativity and
precedence values that rem
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. Th
Hi David:
On Fri, Jul 27, 2012 at 1:53 PM, David A. Wheeler wrote:
> 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 patte
Alan Manuel Gloria:
> buNDlE BunDEl
Awesome, pushed.
And we have a new kind of error: If you use "!" indents, and later
split a line, this won't work:
!hello( ...
!
!)
Because the "!" on the middle and last line are *NOT* indent chars.
I'm really striving to m
Your wish is my command. If you want to use sweet-expressions to write
scripts, I have a new toy in the git repository, "sweet-run". I'd like to know
if it's worth keeping.
The "sweet-run" program processes the rest of the file through "unsweeten" and
runs it. Here's an example of using it,
>
> 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 o
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
suc
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
On Fri, Jul 27, 2012 at 10:11 AM, Alan Manuel Gloria wrote:
> But in Lisp, how should we act if
> only some submodule (and not the entire program) is reloaded, and the
> newly loaded changes the precedence of some notation that another
> submodule (which wasn't reloaded) uses. Do we suddenly chan
buNDlE BunDEl
On Thu, Jul 26, 2012 at 5:59 AM, Alan Manuel Gloria wrote:
> bundle bundle
2012-07-28-almkglor.bundle
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the wa
Do note that while the Haskell spec requires that the compiler
essentially read in every module into a single memory text blob and
*then* compile it, in practice Haskell implementations use separate
compilation. What that sometimes means *in practice* is that if an
infix notation's precedence and
I have a (possibly controversial, possibly insanely stupid) feature
request:
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
On 7/26/12, David A. Wheeler wrote:
>> But now you can't use my-subst. You *could* replace it with
>> unsweeten.in and sweeten_header.in, and add to
>> AC_CONFIG_FILES([Makefile src/unsweeten src/sweeten_header]) or some
>> such - GUILE_PROGS automatically includes @GUILE@ in an AC_SUBST. And
>>
On Fri, Jul 27, 2012 at 11:43 AM, David A. Wheeler
wrote:
> I'd like to wrap up and have a release by around July 31.
>
> We're mostly ready. We have a package that installs using autoconf, with
> lots of useful stuff (sweet, unsweet, sweet-guile, neoteric-guile,
> curly-infix.cl). It's passin
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:
=
Alpheus Madsen:
> 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.
If you want to write *scripts* using a Lisp-like language, scsh might be us
25 matches
Mail list logo
