Re: [PATCH] ice-9: Add JSON module.

2015-09-21 Thread Ludovic Courtès
David Thompson  skribis:

> JSON is an commonly encountered format when writing web applications,
> much like XML, and I think it would be a good idea if the core Guile
> distribution had an SXML equivalent for JSON.  This patch introduces
> such an interface in the (ice-9 json) module.

There’s also guile-json, bindings to a C library, but I think it’s
better to have a pure Scheme implementation, and to have it in Guile
core.

I wonder if we should introduce it in 2.0.  What do people think?

> +(define (json-error port)
> +  (throw 'json-error port))

This won’t print correctly, unless there’s an exception printer
installed in boot-9.scm (see ‘getaddrinfo-error’ for instance.)  Could
you add one?

Also, I think we need more details about the error: parse error, what
kind, etc.

Would it work to use the parser from (language ecmascript parse),
possibly restricting it?  Or do you think it’s more viable to have a
separate parser because there are too many differences?

Is there a standard test suite that we could test it against, somehow?

Otherwise LGTM.

Thanks, and sorry for the delay!

Ludo’.




Re: New logo and website design proposal

2015-09-21 Thread Ludovic Courtès
Hello!

Luis Felipe López Acevedo  skribis:

> As part of the Guile project I imagine, I'd like to propose these
> visual modifications for the logo and the website.
>
> Logo
> https://multimedialib.files.wordpress.com/2015/09/guile-logo-proposal-2015-06-16.png

I like it!

> Website mockup (some rough sketches here)
> https://multimedialib.files.wordpress.com/2015/09/website-mockup-2015-09-15.png
>
> My intention with this proposal is, hopefully, to modernize the image
> of the project a bit and make it more attractive to potential users.

This is amazing!  I really like the web site mockup.  The drawings are
just awesome.

Christopher Allan Webber  skribis:

> First of all, I think this looks *amazing*!  Will it keep these kind of
> nice black and white drawings, or will the final result have a more
> refined look?  Either way, I like the childrens' book type
> illustrations.  (My request would be that if they do become colored, the
> two children-programmers whose bodies are somewhat visible have
> different skin tones for diversity reasons.  I think they look gender
> ambiguous enough because of the suits.)  Honestly I think the rough
> black and white versions look very nice as-is though, and I am not sure
> how to color them without a kind of watercolor look.  Very "Where the
> Wild Things Are" meets robots.  A good combination!

I would leave them as is; I think it’s fine without colors.

> Second, a friend of mine pointed out a couple of things:
>
>  - The "Guile is an extension language platform" section gives the
>impression maybe overly that it's an extension language far and above
>being an independent language.  Guile is certainly optimized for
>this, especially for legacy reasons, but more and more Guile
>applications seem to be written entirely within Guile itself.

+1

>  Maybe the text could be something like:
>
>  "Guile contains a neat and highly optimized virtual machine.

Or rather “… an efficient compiler and virtual machine.”

>  It can be used out of the box to write programs in Scheme, or
>  can easily be integrated with C and C++ programs.
>
>  Guile is the GNU Ubiquitous Intelligent Language for Extensions,
>  and the official extension language of the GNU project."

+1

>  - It may be nice to show code examples.  Lisp is often interpreted as
>being hard to read; I have found that a nice theme and
>rainbow-parentheses has reduced that fear for some users.  Here's
>some examples of screenshots I have taken of my own emacs with
>various lisps... none of them are perfect, and this isn't scheme
>code, but to get the general idea:
>
>  http://dustycloud.org/tmp/emacs_lisp_setup.png
>^- Probably could do without the highlighting?
>
>  http://dustycloud.org/tmp/emacs-rainbow-all-the-things.png
>^- Probably could do without the rainbow-delimeters?
>
>  http://dustycloud.org/tmp/emacs_wombat.png
>^- Something different, but also a nice theme
>
>I'm not 100% confident on this; showing "real code" might actually
>clutter things or make things more intimidating.  The present
>design I think is fairly intimidation-free.

Maybe these could go under “Getting Started”?

I like what racket-lang.org does with the cycling code examples.  An
option would be to still their idea (and code? ;-)).

Other comments:

  • In the “Extend applications” part, I would remove Lua, move ECMA to
the back on the drawing, and add Scheme to the front; we might even
replace ECMA with C.  In general, we don’t want to emphasize
multiple-language support, so I would also remove it from the
heading.

  • The “Applications” part is a good idea.  Unfortunately, we cannot
(yet!) have LilyPond there (its port to Guile 2.0 is incomplete) and
TeXmacs (not sure what the status is.)

Perhaps Guile-Charting, Guile-Present, or Guile-OpenGL would make
for a nice picture, or maybe Guile-SSH for a black terminal-like
geeky image?

  • I noticed with the Guix web site that “Help” is a bit confusing
since it’s about getting help and not about helping out
(contributing).

  • I think we can remove “Blog”, but a news section would be welcome,
possibly with a preview on the main page as you did for Guix?

Thanks a lot!

Ludo’.




Re: [PATCH] ice-9: Add JSON module.

2015-09-21 Thread Matt Wette

> On Sep 21, 2015, at 1:08 PM, Ludovic Courtès  wrote:
> 
> David Thompson  skribis:
> 
>> JSON is an commonly encountered format when writing web applications,
>> much like XML, and I think it would be a good idea if the core Guile
>> distribution had an SXML equivalent for JSON.  This patch introduces
>> such an interface in the (ice-9 json) module.
> 
> There’s also guile-json, bindings to a C library, but I think it’s
> better to have a pure Scheme implementation, and to have it in Guile
> core.
> 
> I wonder if we should introduce it in 2.0.  What do people think?


I would be happy to have this in the core; I have used it.  A few comments:

1. There is a minor typo in the source: should be "denominator.”
2. The comments say integers are converted to exact and floating point to 
inexact, but the code will convert 1.0 to exact.

> Would it work to use the parser from (language ecmascript parse),
> possibly restricting it?  Or do you think it’s more viable to have a
> separate parser because there are too many differences?

I vote for separate parser, the json.scm file is lightweight.  json.scm.go is < 
17k.



Re: [PATCH] ice-9: Add JSON module.

2015-09-21 Thread Mark H Weaver
Hi David,

Sorry for the long delay.

David Thompson  writes:

> JSON is an commonly encountered format when writing web applications,
> much like XML, and I think it would be a good idea if the core Guile
> distribution had an SXML equivalent for JSON.  This patch introduces
> such an interface in the (ice-9 json) module.

Excellent!  This will be a most welcome addition :)

Please see below for comments.

> With (ice-9 json), this expression:
>
> (@ (name . "Eva Luator")
>(age . 24)
>(schemer . #t)
>(hobbies "hacking" "cycling" "surfing"))
>
> serializes to this JSON (except not pretty-printed):
>
> {
>   "name": "Eva Luator",
>   "age": 24,
>   "schemer": true,
>   "hobbies": [
> "hacking",
> "cycling",
> "surfing"
>   ]
> }
>
> Thanks to Mark Weaver and Chris Webber for helping come to a consensus
> on a good syntax for JSON objects.
>
> From 2d4d8607aedaede98f413a84f135d8798d506233 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Sat, 15 Aug 2015 14:09:23 -0400
> Subject: [PATCH] ice-9: Add JSON module.
>
> * module/ice-9/json.scm: New file.
> * module/Makefile.am (ICE_9_SOURCES): Add it.
> * test-suite/tests/json.test: New file.
> * test-suite/Makefile.am (SCM_TESTS): Add it.
> * doc/ref/guile.texi ("Guile Modules"): Add "JSON" section.
> * doc/ref/json.texi: New file.
> * doc/ref/Makefile.am (guile_TEXINFOS): Add it.

The Makefile.am files need 2015 added to their copyright dates.

> ---
>  doc/ref/Makefile.am|   3 +-
>  doc/ref/guile.texi |   2 +
>  doc/ref/json.texi  |  62 +++
>  module/Makefile.am |   3 +-
>  module/ice-9/json.scm  | 395 
> +
>  test-suite/Makefile.am |   1 +
>  test-suite/tests/json.test | 149 +
>  7 files changed, 613 insertions(+), 2 deletions(-)
>  create mode 100644 doc/ref/json.texi
>  create mode 100644 module/ice-9/json.scm
>  create mode 100644 test-suite/tests/json.test
>
> diff --git a/doc/ref/Makefile.am b/doc/ref/Makefile.am
> index 31c26a7..5dfc019 100644
> --- a/doc/ref/Makefile.am
> +++ b/doc/ref/Makefile.am
> @@ -95,7 +95,8 @@ guile_TEXINFOS = preface.texi   \
>goops.texi \
>goops-tutorial.texi\
>guile-invoke.texi  \
> -  effective-version.texi
> +  effective-version.texi \
> +  json.texi
>  
>  ETAGS_ARGS = $(info_TEXINFOS) $(guile_TEXINFOS)
>  
> diff --git a/doc/ref/guile.texi b/doc/ref/guile.texi
> index db815eb..468d3a5 100644
> --- a/doc/ref/guile.texi
> +++ b/doc/ref/guile.texi
> @@ -375,6 +375,7 @@ available through both Scheme and C interfaces.
>  * Statprof::An easy-to-use statistical profiler.
>  * SXML::Parsing, transforming, and serializing XML.
>  * Texinfo Processing::  Munging documents written in Texinfo.
> +* JSON::Parsing and serializing JSON.
>  @end menu
>  
>  @include slib.texi
> @@ -397,6 +398,7 @@ available through both Scheme and C interfaces.
>  @include statprof.texi
>  @include sxml.texi
>  @include texinfo.texi
> +@include json.texi
>  
>  @include goops.texi
>  
> diff --git a/doc/ref/json.texi b/doc/ref/json.texi
> new file mode 100644
> index 000..43dba4d
> --- /dev/null
> +++ b/doc/ref/json.texi
> @@ -0,0 +1,62 @@
> +@c -*-texinfo-*-
> +@c This is part of the GNU Guile Reference Manual.
> +@c Copyright (C) 2015  Free Software Foundation, Inc.
> +@c See the file guile.texi for copying conditions.
> +@c
> +
> +@node JSON
> +@section JSON
> +
> +@cindex json
> +@cindex (ice-9 json)
> +
> +The @code{(ice-9 json)} module provides procedures for parsing and
> +serializing JSON, the JavaScript Object Notation data interchange
> +format.  For example, the JSON document:
> +
> +@example
> +@verbatim
> +{
> +  "name": "Eva Luator",
> +  "age": 24,
> +  "schemer": true,
> +  "hobbies": [
> +"hacking",
> +"cycling",
> +"surfing"
> +  ]
> +}
> +@end verbatim
> +@end example
> +
> +may be represented with the following s-expression:
> +
> +@example
> +@verbatim
> +(@ (name . "Eva Luator")
> +   (age . 24)
> +   (schemer . #t)
> +   (hobbies "hacking" "cycling" "surfing"))
> +@end verbatim
> +@end example

Looks good!

> +Strings, real numbers, @code{#t}, @code{#f}, @code{#nil}, lists, and

As we discussed on #guile, I would prefer to avoid the use of #nil.
Support for #nil is a hack that we're compelled to support for the sake
of integration with elisp which conflates boolean false with the empty
list, but we should avoid introducing more uses of it.

Was it decided that the symbol 'null' would be a good choice?  If so,
that sounds good to me.

> +association lists may be serialized as JSON.  Association lists
> +serialize to objects, and regular lists serialize to arrays.  To
> +distinguish regular lists from a

Re: [PATCH] ice-9: Add JSON module.

2015-09-21 Thread Mark H Weaver
Matt Wette  writes:

> On Sep 21, 2015, at 1:08 PM, Ludovic Courtès  wrote:
>
> 
> David Thompson  skribis:
> 
> JSON is an commonly encountered format when writing web
> applications,
> much like XML, and I think it would be a good idea if the core
> Guile
> distribution had an SXML equivalent for JSON. This patch
> introduces
> such an interface in the (ice-9 json) module.
> 
>
> There’s also guile-json, bindings to a C library, but I think it’s
> better to have a pure Scheme implementation, and to have it in
> Guile
> core.
> 
> I wonder if we should introduce it in 2.0. What do people think?
> 
>
> I would be happy to have this in the core; I have used it.

Agreed.

> 1. There is a minor typo in the source: should be "denominator.”

Indeed, good catch!

> 2. The comments say integers are converted to exact and floating point
> to inexact, but the code will convert 1.0 to exact.

In Scheme terminology, 1.0 is an integer.

> Would it work to use the parser from (language ecmascript parse),
> possibly restricting it? Or do you think it’s more viable to have
> a
> separate parser because there are too many differences?
> 
>
> I vote for separate parser, the json.scm file is lightweight.
> json.scm.go is < 17k.

Agreed.  The simplicity also allows confidence that it can safely handle
potentially malicious JSON data.

  Mark