Re: Including sjson (formerly (ice-9 json)) and fash.scm in guile proper?

[Christopher Allan Webber]

Mark H Weaver writes:

> Hi Chris,
>
> Christopher Allan Webber  writes:
>> So a while ago, David Thompson submitted (ice-9 json) to Guile proper.
>> A few changes were requested, so it hadn't made it in.  In the meanwhile
>> I began using it for a number of projects.  I also added some
>> modifications and extensions: #nil became 'null for the representation
>> of null values,
>
> Most of the modifications you've made are good, but I'm very
> uncomfortable with the use of #nil in this API.  #nil is a terrible hack
> which may not even be adequate for its intended use case.  Its existence
> in any data structure is likely to cause misbehavior in other Scheme
> code that is exposed to it, because it violates a longstanding fact in
> Scheme that there is only one value that is treated as "false".  It
> would also make it difficult or impossible to port this library, and
> thus anything that depends on this library, to other Scheme systems.  We
> should not promote its use by incorporating it into new APIs.
>
> What do you think?

Oh!  No you got it backwards, the library *was* using #nil initially,
and I modified it to use 'null now instead. :)

So I think you'd be probably pretty happy!

> Otherwise, I'm generally in favor of incorporating this library into
> Guile, after we make sure that it is robust against malicious inputs.

Okay, cool!  The other thing is to add more specific error messages, as
discussed.

What examples of malicious inputs should we test against?

Re: ffi helper

[Matt Wette]

> On Apr 17, 2017, at 7:26 PM, Matt Wette  wrote:
> 
> 
>> On Mar 21, 2017, at 3:40 PM, Matt Wette  wrote:
>>> On Mar 19, 2017, at 10:23 AM, Matt Wette  wrote:
 On Mar 13, 2017, at 5:53 PM, Matt Wette  wrote:
> On Mar 8, 2017, at 6:06 PM, Matt Wette  wrote:
> I’m now working on a FFI helper based on the nyacc C99 parser.   

Still grinding away.  I can generate wrappers for function pointers passed to C 
routines: see cairo_destroy_func_t below.  I don’t know if the converter should 
be called “wrap” or something else as, wrt the pointer wrappers, we are adding 
a “C” wrapper instead of a “scheme” wrapper.

I am deciding how to handle enums.  I will likely have wrapper to map symbols 
to integers and vice versa, but I will have to handle anonymous enums as well 
(e.g." enum { ABC = 1 };”). 

Matt

(use-modules (ffi-help))

(define-ffi-helper (cairo cairo)
  #:pkg-config "cairo"
  #:include "cairo-svg.h"
  #:library "libcairo"
  #:filter (lambda (path) (string=? "cairo" (substring path 0 5)))
  )

==[GENERATES]==>[filter samples]==>

;;
;; auto-generated by ffi-help.scm
;;

(define-module (cairo cairo)
  #:use-module (ffi-help)
  #:use-module ((system foreign) #:prefix ffi:)
  #:use-module ((bytestructures guile) #:prefix bs:)
  )
(define bs:struct bs:bs:struct)

(define lib-link (dynamic-link "libcairo"))
(define (lib-func name) (dynamic-func name lib-link))

;; typedef struct _cairo_surface cairo_surface_t;
(define-std-pointer-wrapper cairo_surface_t*)

;; cairo_matrix_t
(define cairo_matrix_t
  (bs:struct
(list `(xx ,bs:double)
  `(yx ,bs:double)
  `(xy ,bs:double)
  `(yy ,bs:double)
  `(x0 ,bs:double)
  `(y0 ,bs:double
(export cairo_matrix_t)


;; typedef void  (*cairo_destroy_func_t)(void  *data);
(define (wrap-cairo_destroy_func_t proc) ;; => pointer
 (ffi:procedure->pointer ffi:void proc (list '*))
 )
(export wrap-cairo_destroy_func_t)

;; cairo_t *cairo_create(cairo_surface_t *target);
(define cairo_create
  (let ((f (ffi:pointer->procedure
 '*
 (lib-func "cairo_create")
 (list '*
(lambda (target)
  (let ((~target ((unwrap-cairo_surface_t* target
(identity (f ~target))
(export cairo_create)

;; typedef struct _cairo_region cairo_region_t;
(define-std-pointer-wrapper cairo_region_t*)

;; cairo_bool_t cairo_region_contains_point(const cairo_region_t *region, int 
;; x, int y);
(define cairo_region_contains_point
  (let ((f (ffi:pointer->procedure
 ffi:int
 (lib-func "cairo_region_contains_point")
 (list '* ffi:int ffi:int
(lambda (region x y)
  (let ((~region ((unwrap-cairo_region_t* region
(f ~region x y)
(export cairo_region_contains_point)

;; --- last line ---

Re: GNU Guile 2.2.2 released

[Matt Wette]

> On Apr 21, 2017, at 7:41 AM, Andy Wingo  wrote:
> 
> We sheepishly announce GNU Guile release 2.2.2, a quick bug-fix to the
> recent 2.2.1 release.

The FreeBSD section in README is not quite correct IMO.   Here are suggested 
changes:
 
 FreeBSD 11.0:
-  For a build supporting threads, please `pkg install' the following
+  Please `pkg install' the following:
 - pkgconf : provides pkg-config
+- texinfo : provides makeinfo
 - gmake : /usr/bin/make does not work
-- boehm-gc-threaded : needed for threaded support
 
-  Configure as:
+  If you want a Guile with threads, then install boehm-gc-threaded and
+  configure as:
 
 ./configure --with-bdw-gc=bdw-gc-threaded
 

Re: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Panicz Maciej Godek  writes:

> 2017-05-13 3:52 GMT+02:00 Mark H Weaver :
>
>> Hi Arne,
>>
>> Arne Babenhauserheide  writes:
>> > A few weeks ago I asked in IRC whether wisp[1] could be included with
>> > Guile in modules/language/wisp to allow every guile users to run wisp
>> > code from any Guile installation via
>> >
>> >
>> > $ guile --language=wisp []
>> >
>> >
>> > Essentially this is about making wisp as language part of the
>> > "batteries" of Guile.
>>
>> About 4.5 years ago, I went out on a limb and added SRFI-105 (curly
>> infix expressions) to core Guile.  Even now, I'm of the opinion that
>> judicious use of curly infix could be beneficial for readability, but as
>> far as I can tell, there's been essentially no uptake.  If I'm wrong
>> about that, please let me know.

I’m using curly infix in cond-expressions, both with wisp and with
regular Scheme:

(cond
  ({a < 5}
   (something)
   (more))
  ({a > 7}
   (something-else)))

cond
  : {a < 5}
something
more
  : {a > 7}
something-else


>> Although (a subset of) SRFI-105 seems like a clear win to me, I cannot
>> say the same of either Wisp or SRFI-110 (Sweet expressions).
>>
> "The idea of introducing Algol-like syntax into Lisp keeps popping up and
> has seldom failed to create enormous controversy between those who find the
> universal use of S-expressions a technical advantage
…

This is a nice read, but does not apply to Wisp itself, since Wisp just
infers the parentheses from indentation but otherwise does not change
anything.

It does apply to some degree to SRFI-105, but not fully.
A rationale is provided here:
https://web.archive.org/web/20160505180131/http://srfi.schemers.org/srfi-105/srfi-105.html#rationale_changereader

(being able to use infix for pattern matching)

That said: I like is as infix very much and would love to see it
included — e.g. in (ice-9 is).

On the other hand, a SRFI for is would make it easier to build
cross-system scheme with it.

> and (is x < y <= z) is more concise than (and (< x y) (<= y z)).

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Wisp as shipped language in Guile?

[Panicz Maciej Godek]

2017-05-13 3:52 GMT+02:00 Mark H Weaver :

> Hi Arne,
>
> Arne Babenhauserheide  writes:
> > A few weeks ago I asked in IRC whether wisp[1] could be included with
> > Guile in modules/language/wisp to allow every guile users to run wisp
> > code from any Guile installation via
> >
> >
> > $ guile --language=wisp []
> >
> >
> > Essentially this is about making wisp as language part of the
> > "batteries" of Guile.
>
> About 4.5 years ago, I went out on a limb and added SRFI-105 (curly
> infix expressions) to core Guile.  Even now, I'm of the opinion that
> judicious use of curly infix could be beneficial for readability, but as
> far as I can tell, there's been essentially no uptake.  If I'm wrong
> about that, please let me know.
>
> Although (a subset of) SRFI-105 seems like a clear win to me, I cannot
> say the same of either Wisp or SRFI-110 (Sweet expressions).
>
>
"The idea of introducing Algol-like syntax into Lisp keeps popping up and
has seldom failed to create enormous controversy between those who find the
universal use of S-expressions a technical advantage (and don’t mind the
admitted relative clumsiness of S-expressions for numerical expressions)
and those who are certain that algebraic syntax is more concise, more
convenient, or even more natural (whatever that may mean, considering that
all these notations are artificial).

We conjecture that Algol-style syntax has not really caught on in the Lisp
community as a whole for two reasons. First, there are not enough special
symbols to go around. When your domain of discourse is limited to numbers
or characters, there are only so many operations of interest, and it is not
difficult to assign one special character to each and be done with it. But
Lisp has a much richer domain of discourse, and a Lisp programmer often
approaches an application as yet another exercise in language design; the
style typically involves designing new data structures and new functions to
operate on them—perhaps dozens or hundreds—and it’s just too hard to invent
that many distinct symbols (though the APL community certainly has tried).
Ultimately one must always fall back on a general function-call notation;
it’s just that Lisp programmers don’t wait until they fail.

Second, and perhaps more important, Algol-style syntax makes programs look
less like the data structures used to represent them. In a culture where
the ability to manipulate representations of programs is a central
paradigm, a notation that distances the appearance of a program from the
appearance of its representation as data is not likely to be warmly
received (and this was, and is, one of the principal objections to the
inclusion of loop in Common Lisp).

On the other hand, precisely because Lisp makes it easy to play with
program representations, it is always easy for the novice to experiment
with alternative notations.  Therefore we expect future generations of Lisp
programmers to continue to reinvent Algol-style syntax for Lisp, over and
over and over again, and we are equally confident that they will continue,
after an initial period
of infatuation, to reject it. (Perhaps this process should be regarded as a
rite of passage for Lisp hackers.)"

Guy L. Steele, Jr. and Richard P. Gabriel, "The Evolution of Lisp"

My personal opinion is that adding new ways for expressing the same thing
that can already be expressed in the language is a bad thing, because it
only increases the entropy of your code base.

When it comes to readability, I don't think that we need to make the reader
syntax more complex. What we need is an editor with a good typesetting
feature, so that various programmers could use the formatting of their
liking (say, making their code look more like Haskell or more like Julia or
some other mathematical idols like Mathematica) without making any invasive
changes to the code base.

When it comes to curly infix, I don't think that it really is an advantage
for arithmetic expressions. But I do agree that infix expressions are
actually clarifying in the case of asymmetrical binary relations: x < y is
a bit more obvious than (< x y). However, this can be achieved using
regular Scheme syntax, say, with the following macros:

(define-syntax infix (syntax-rules ()
  ((_ x related-to? y)
   (related-to? x y))
  ((_ x related-to? y . likewise)
   (and (infix x related-to? y)
(infix y . likewise)

(define-syntax is (syntax-rules (_)
  ((is _ related-to? right . likewise)
   (lambda (_)
 (infix _ related-to? right . likewise)))

  ((is left related-to? _ . likewise)
   (lambda (_)
 (infix left related-to? _ . likewise)))

  ((is x related-to? y . likewise)
   (infix x related-to? y . likewise))

  ((is x) ;; thanks to Arne's earlier suggestions
   (lambda (y)
 (equal? x y)))

  ((is left relation) ;; same as "(is left relation _)"
   (lambda (right)
 (relation left right)

Perhaps the "is" macro allows more than it should, and "infix"