ANNOUNCE: Mailing list for SRFI-110, sweet-expressions, now open

[John Cowan]

Sweet-expressions are a new proposal for whitespace-controlled infix
syntax for Scheme and other Lisps. Unlike existing proposals right
back to the beginning of Lisp, sweet-expressions are fully homoiconic,
so they need no updating to work well with arbitrary syntax extensions.
There is a simple escape back to S-expressions: just put things in parens.
There is a formal definition of sweet-expressions in BNF, as well as
working Scheme code that can be dropped in as a replacement for `read`.

Here's a simple procedure definition written as a sweet-expression.

define represent-as-infix?(x)
and
pair? x
is-infix-operator? car(x)
list? x
{length(x) <= 6}

An empty line at the end terminates the sweet-expression. The notation
f(x), with no whitespace before the "(", means (f x). Note the use of
braces to delimit an infix expression.

Here's another example, using the special lexical syntax $, which
indicates that its right-hand side is the last element of the list begun
by its left-hand side. It is named by analogy with the $ operator in
Haskell: a $ b $ c $ d means (a (b (c d)).

define extract(c i) $ cond
vector?(c) $ vector-ref c i
string?(c) $ string-ref c i
pair?(c) $ list-ref c i
else $ error "Not a collection"

If you are interested, send a blank email with the subject line
"subscribe" to <srfi-110...@srfi.schemers.org>. I'll be there.
(Note to David and Alan: the link to the source is broken.)

--
John Cowan co...@ccil.org http://www.ccil.org/~cowan
Most languages are dramatically underdescribed, and at least one is
dramatically overdescribed. Still other languages are simultaneously
overdescribed and underdescribed. Welsh pertains to the third category.
--Alan King

[Alex Shinn]

[Replying to chibi-scheme.]

I'm currently working on the infrastructure to support

alternate languages in chibi.  The initial version of

(chibi parse) has been checked in, and I have a prototype

Go implementation using it.  JS and Bash will likely be

next (and much easier).  These are completely separate

now and I haven't decided how closely to integrate them

into the core (e.g. should chibi automatically detect the

language from extensions?).

Reader variations like this would be one aspect of the

language setting, so it is likely that you'd be able to write

a user-level sweet expressions extension that others could

use.  A more interesting reader extension to me would be

a literate programming mode, where flush-left text not

beginning with a paren is implicitly commented.  This could

replace the ;;> prefix currently used.

Personally, I've never been interested in efforts to reduce

parens and am unlikely to bundle this in the core.  For those

curious, though, I do consider parens a distraction (and

brackets much more so), and in my personal Emacs env

have them dimmed to be almost invisible:

(defface paren-face

  '((((class color) (background dark))

     (:foreground "grey20"))

    (((class color) (background light))

     (:foreground "grey80")))

  "Face used to dim parentheses."

  :group 'basic-faces)

(font-lock-add-keywords 'scheme-mode nil '(("(\\|)" . 'paren-face)))

The resulting code looks like what you'd get with srfi-110

but with no artificial restrictions.

The brace extension also conflicts with chibi's record

literals.

-- 

Alex

--
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chibi-scheme...@googlegroups.com.
To post to this group, send email to chibi-...@googlegroups.com.
Visit this group at http://groups.google.com/group/chibi-scheme?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Benjohn Barnes]

On 9 Mar 2013, at 03:52, Alex Shinn wrote:
> I'm currently working on the infrastructure to support
> alternate languages in chibi. The initial version of
> (chibi parse) has been checked in, and I have a prototype
> Go implementation using it. JS and Bash will likely be
> next (and much easier).

This sounds exciting and very impressive. :-) The choice of Go sounds a little like deciding you fancy a spot of hill rambling and starting out with Everest (or perhaps that would be c++)?! Bash also sounds like an odd choice? I'd love to hear the thinking behind this, though it might just be "because it's there".

Are you thinking about implementing Lua, at all?

Thanks,
Benjohn

--
ben...@fysh.org - Twitter @benjohnbarnes - Skype (sometimes) benjohnbarnes - Mobile +44 (0) 7968 851 636

[John Cowan]

Benjohn Barnes scripsit:

> The choice of Go sounds a little like deciding you fancy a spot of hill
> rambling and starting out with Everest (or perhaps that would be c++)?!

Well, go has goroutines, and in Scheme we already know how to do those, ugye?

> Bash also sounds like an odd choice? I'd love to hear the thinking
> behind this, though it might just be "because it's there".

Just think how fast hairy bash scripts will run on the Chibi engine!

> Are you thinking about implementing Lua, at all?

Alex has said he doesn't much care about it; JavaScript is probably the
Right Thing in the target area. He's not going to do Elisp either,
since Guile is doing so. But that's not to say they can't be provided
by somebody else -- just a SMOP.

(Today Scheme, tomorrow -- Cobol.)

--
John Cowan co...@ccil.org http://www.ccil.org/~cowan

Statistics don't help a great deal in making important decisions.
Most people have more than the average number of feet, but I'm not about
to start a company selling shoes in threes. --Ross Gardler

[Alex Shinn]

On Tue, Mar 12, 2013 at 12:00 PM, John Cowan <co...@mercury.ccil.org> wrote:

Benjohn Barnes scripsit:

> The choice of Go sounds a little like deciding you fancy a spot of hill
> rambling and starting out with Everest (or perhaps that would be c++)?!

Well, go has goroutines, and in Scheme we already know how to do those, ugye?

Yes, goroutines and channels map well to how chibi (and most

Schemes) handle concurrency.

The other reasons are: 1) my company uses Go so I wanted to

play with it, 2) Go is C-like but relatively easy to parse (notably

type annotations are context-free), 3) Go's structs map well to

Scheme records, unlike JS/Perl/Python/etc. where classes are

basically heavy handed hash-tables.

> Bash also sounds like an odd choice? I'd love to hear the thinking
> behind this, though it might just be "because it's there".

Just think how fast hairy bash scripts will run on the Chibi engine!

It's one piece of my unpublished SCSH replacement.

I also want to be able to statically analyze bash scripts

beyond -n, to be able to determine what files, commands

and env vars are used.

> Are you thinking about implementing Lua, at all?

Alex has said he doesn't much care about it; JavaScript is probably the
Right Thing in the target area.  He's not going to do Elisp either,
since Guile is doing so.  But that's not to say they can't be provided
by somebody else -- just a SMOP.

Right, I don't want Emacs rewritten in Scheme, I want

something new and better, and so don't care at all about

Elisp.

I'll provide a roadmap in the near future.  It may appear

from the outside that what I'm working on is arbitrary, but

there is method to my madness :)

-- 

Alex

[Bakul Shah]

On Mar 11, 2013, at 8:35 PM, Alex Shinn <alex...@gmail.com> wrote:
>
> Yes, goroutines and channels map well to how chibi (and most
> Schemes) handle concurrency.

Can chibi make use of multiple cores? Channels + true concurrency in Scheme would be very nice indeed!

[Alex Shinn]

You can run multiple chibi VMs on separate cores.  The

plan is to add a convenience for doing this from the

Scheme-side (like Erlang processes and JS web workers).

Although I think it's important for a systems language like

Go to have finer grained control of multiple cores sharing

memory, it seems a bad idea for high-level languages.

Most of the time, once you're in a situation where performance

matters and the task can be divided, you really want to be

able to divide it among machines, not just cores.

-- 

Alex

[Daniel Leslie]

Video Games being the most obvious exception. ;)

-Dan