'(scheme . info)

I am trying (without success) to compile Scheme programs using the
gambit compiler. I searched the web, and noticed that I am not the
only one who failed. The manual does not help much, since it gives
examples for Mac OS-X, and for Linux, but none for Windows. Here is
what I did:
gsc -link test.scm
This generates two files:

Hi,
I need to implement a kind of template processor in which simple
constructs like this:
(define-activity
:name activity-name
:subactivities subactivity-list)
get translated into a bunch of replacement s-expressions.
I have a simple define-syntax macro definition that seems to work on forms
when they appear in the same Scheme code as the define-syntax form or are

Back in 2003 there was a flurry of Scheme implementations adopting/
integrating with the GMP libraries. Does anyone know what the current
state of play is on that topic?
david

[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]

[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]

This announces the availability for discussion of
Scheme Request for Implementation 97
"SRFI Libraries"
by David Van Horn.
Its draft and an archive of the ongoing discussion is available at
[link]
You can join the discussion of the draft by sending an email message
with a "subscribe" subject line to

Just a couple questions about scheme, thanks for all your help in
advance.
Say for example, you have a file with one line of text in it.
How would you go about doing the following:
Take the file name as a command line argument
Retrieve the first and only line of the file
Place the line into a list with each word as separate elements

Guys,
LispNYC is an official Google Summer of Code 2008 mentoring
organization and is now accepting proposals for anything involving
Lisp-based technology:
[link]
This is an exciting year as we already have non-Google funding offers
for projects. Check out the ideas, toss in your own and feel free to

When I do 'M-x run-scheme' in emacs, it doesn't autoindent
correctly with mit-scheme. If I do 'C-u M-x run-scheme' with guile or
mzscheme, autoindent works perfectly. Any ideas?

[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]

Many people ran into trouble while trying to use Eager Comprehensions
(SRFI-42) on Bigloo; there are two issues: (1) Bigloo does not accept
identifiers containing the colon character, that it reserves for the
optional type declaration; (2) The :list generator suffers from name
capture, and produces wrong results when running in :parallel. I

First, get the attendeees from the ticket value or "t"
(define (attendees t)
(+ 120 (* 15 (/ (- 5 t) .1))))
(define (revenue t)
(* t (attendees t)))
(define (cost t)
(+ 180 (* .04 (attendees t))))
(define (profit t)
(- (revenue t) (cost t)))

First of all, thank you guys for your great help in my first post in
this group (the question related to libraries).
Now, another question:
I'm playing a little with macros, and I'm building a macro that builds
a function using the list data type. Here it is:
(define-macro m2
(lambda ()
(list 'define 'm2

Please come join us for our first social meeting of LispSTL on Friday
March 28, 2008
from 7pm till 10pm. At Kayak's Cafe, 276 North Skinker Blvd.
Open to the Public, so all are welcome.
[link]

This SHOULDN'T matter, but the following questions stems from running
Scheme under Windows XP.
(define (rep-loop)
(display "repl>")
(write (eval (read)))
(rep-loop))
1 ]=> (rep-loop)
repl>(+ 4 5)
When I run this, or any kind of variation, I an error message that is
something like the following.

The basic representational element for PLT Scheme Schemelab is a homogeneous, n-dimensional array - or ndarray. This post will discuss the initial design for ndarrays and discuss some of the operations on them.

Internally, an ndarray is represented by a structure with the following elements:

• ordering - (symbols 'row 'column), specifies the order in which dimensions are stored ('row for row major and 'column for column major). Generally, this isn't that useful except for (eventually) interfacing with foreign code (C uses row major and FORTRAN uses column major). Also, the transpose operation converts from one to the other (although that is more a side effect that its real functionality). [read only]
  
• shape - (listof natural-number/c), specifies the shape of the array. The length of the shape list is the number of dimensions for the array and each element is the cardinality of the corresponding dimension. This may be set to reshape the array.
• ndim - natural-number/c, the number of dimensions for the array. This is equal to (length shape). [read only]
• size - natural-number/c, the total number of elements in the array. [read only]
• disp - natural-number/c, the displacement (in elements) of this subarray is the data vector. This will be zero for any ndarray that owns its own data. [read only]
• strides - (listof natural-number/c), a list of the number of elements to skip to move to the next element in the corresponding dimension. [read only]
• offset - natural-number/c, the offset (in elements) for each addressed element. This will be zero for any ndarray that owns its own data. [read only]
• data - typed-vector?, the typed vector containing the data for the array. [A typed vector encapsulates an SRFI 4 vector (for u8, u16, u32, u64, s8, s16, s32, s64, f32, or f64 arrays), a complex vector (for c64 or c128 arrays), or a Scheme vector (for Scheme object arrays).] [read only]
• base - (or/c array? false/c), the base array for this (sub)array or #f if the array owns its own data (i.e. it is a base array). Note that the referenced array may itself base a non-#f base entry. [read only]

Note that I may not need both the displacement (disp) and offset fields. But, the general idea for array iteration is to add the displacement once when the iterator is initialized and to add the offset for each element. It might be possible to collapse those into one offset without loss of generality.

The most general array constructor is make-array, which has the following contract:


(->* ((listof natural-number/c))
(#:vtype (or/c vtype? symbol?)
#:ordering (symbols 'row 'column)
#:fill any/c)
array?)


The required argument is the shape of the array. The optional keyword arguments are #:vtype, which specifies the type of the array (default object), #:ordering, which defaults to 'row, and #:fill. If #fill is not specified, the array elements are not initialized.

Example:

(define a1 (make-array '(3 2) #:vtype f32 #:fill 0.0))

Creates an array whose shape is '(3 2) (i.e. three rows and two columns) and whose elements are 32-bit floating-point numbers that are initially 0.0.

A fully qualified reference for the array returns the corresponding (scalar) element. For example, (array-ref a1 '(1 1) returns the value of the element at '(1 1).

A partially qualified reference for the array returns a reference to the corresponding subarray. For example, (array-ref a1 '(: 1) ) returns the subarray of shape '(3) that corresponds to the second column of a1. [Note that this is a reference to the second column of a1 and not a copy of it. Array referencing never copies anything.] Likewise, (array-ref a1 '(1 :)) [or equivalently, (array-ref a1 '(1))] returns a reference to the second row of a1.

Array mutation also allows partially qualified references. In that case, the value specified must be broadcastable (described in a future post) to the shape of the reference. For example, (array-set! a1 '(: 1) 1.0) sets the elements of the second column of a1 to 1,0 (yes, the scalar 1.0 is broadcastable to shape '(3)). Likewise, (array-set! a1 '(1) '(4.0 8.0)) sets the elements of the second row of a1 to 4.0 and 8.0.

A complete set of array manipulation functions will be provided. This will include: build-array, array-map, array-map!, array-for-each (i.e., similar to what SRFI 43 provides for vectors).

I haven't though about the semantics for things like array-fold and array-unfold. They may be well-defined someplace - I really haven't looked. If anyone knows where or has any ideas, please let me know.

Note that it is not my intention to define functions like add, subtract, multiply, divide, ... (as numpy does for Python). Rather, we will rely on the array mapping functions to extend scalar operations to arrays.

My PLT Scheme project for this year is to create a Schemelab collection to provide better analysis capabilities in PLT Scheme. It will be something of a mini-Matlab with capabilities similar to what numpy, scipy, and matplotlib provide in Python. I plan on making a new numeric collection to provide homogeneous, n-dimensional arrays (and, as a subset, matrices) as the primary underlying representation. Next, the science collection will be updated to use the new numeric package. Finally, a new plot collection will be developed to provide better visualization functionality. [After these are done I'll also update the simulation and inference collections to use the new Schemelab packages.]

I've already started work on the numeric collection. The basic representational element is a homogeneous, n-dimensional array (ndarray). An ndarray's type and shape are specified when it is created. The type may be any of the element types allowed for SRFI 4 vector types (u8, u16, u32, u64, s8, s16, s32, s64, f32, or f64), a complex type (c64 or c128), or may hold any Scheme object (object). The shape is a list of natural numbers where the length of the shape is the number of dimensions for the ndarray and each element is the cardinality of the corresponding dimension. References to array elements will support array slicing (in any dimension) for both array accessing (array-ref) and mutation (array-set!). Slicing operations create new views of the referenced array as opposed to copying portions of the array. I will start posting entries on different aspects of the numeric collection in the next few days.

The updates to the science collection to support (or to make use of internally) the new numeric collection should be relatively straightforward. The main issue will be to retain compatibility with the existing data types (i.e. vectors). Most of the really numerically complex code (e.g. special functions and random number distributions) will not be affected since they don't generally provide vector or array operations. The main changes will be to the statistics and histogram modules, which will be modified to work with ndarrays as well as vectors. Finally, some of the modules (e.g. histograms and ordinary differential equations) will benefit from being reimplemented using ndarrays internally.

I've also prototyped some code for the new plot package that provides much more functionality than the current PLoT package. The initial capability will be very much patterned after the functionality provided by Matlab (or more precisely, matplotlib for Python, which is also based on Matlab). It provides precise control over the elements of a graph (or multiple subgraphs). It also provides interactive graphics functionality for more dynamic analysis capabilities.

Note that all of these new (or updated) collections require PLT Scheme Version 4 (currently 3.99) and are not compatible with earlier versions. As such, I am not releasing them to PLaneT until either PLT Scheme Version 4 is officially released or there is a separate PLaneT repository for PLT Scheme Version 4 code. I will be putting the code on the Schematics web site at some point.

Ever since the Scheme R6RS roadblock, I've been looking to branch out into other Lisps outside the Scheme ecosystem. The good news is that there's no shortage of nascent Lisps and Lisp-wannabes, with many interesting new undertakings being launched month upon month.

There's one in particular, called Clojure (pronounced closure), that was unveiled recently and effortlessly stands out from the bunch. There's much to like about Clojure, but first and foremost, it follows a principle I'm very fond of: code talks, bullshit walks.

That is to say, it's not difficult to imagine any number of interesting directions to take Lisp into, nor is it generally all that much effort to implement proof-of-concepts of such ideas (it's Lisp, after all); but to actually create a full integrated, practical and performant system, that's another matter entirely.

The difference between toy and tool is more than quantitative, and the leap from an SICP metacircular interpreter to something deserving of the hallowed title "Lisp system" is non-trivial, requiring not just deep mastery of the fundamentals but also the discipline and opportunity to take care of all the "boring" stuff so as to ship it. As I know all too well from plenty of practice, this last so-called 20% is where most efforts ultimately wither out to oblivion.

Thus it's a pleasant surprise to discover that while Clojure has no shortage of goodies, it's also remarkably mature and usable right here and now. The author, Rich Hickey, says that he has worked on it for two years, and I think it's admirable that he kept tight-lipped about it for the duration; as a first alpha release, Clojure as it is currently available simply rocks. No Marimba phenomenon, here.

As for the goodies, how does a concurrent, functional Lisp1 with software transactional memory sound like? To me, it sounds like the future. (And that's just the tagline, there's much more.)

I've thought for a while now that if you took a purely functional subset of Scheme (pre-R6RS), sprinkled it with the best of Haskell (without the whole mandatory bondage and discipline, thanks) and built it all on top of an Erlang-like runtime, that might form a pretty compelling basis for a serious attempt at a new practical Lisp dialect. Clojure is perhaps not quite the particular mix that I had in mind, but it's very much in the ballpark.

Indeed Clojure embodies the kind of Lisp I'm interested in, that is, a pragmatic go-getter system actively drawing on the best new computer science research and pushing Lisp ever further out on the frontier of the future, instead of complacently sitting around arguing about how many lambdas can dance on a parenthesis while wondering why the competition is drawing nearer.

Considering how new Clojure is, there is a commendable amount of documentation already available, and the user community is growing in leaps and bounds, drawing both Common Lispers and Schemers as well as a good number of people entirely new to Lisp. The momentum that Clojure has going is tangible.

On the flip side, and these are really pretty serious omissions but may perhaps be intractable on the JVM at present, Clojure lacks tail recursion optimization and continuations. Also, while the concurrency features are impressive, I'm as of yet unsure how well-suited Clojure's JVM-based threading might be to a massively parallel programming style such as what I've been using with the lightweight processes in Gambit and Erlang, both of which will run millions processes without flinching. The author explains that these use cases are kind of supported but perhaps not really Clojure's sweet spot.

Now, given these JVM-imposed constraints, I should admit that I put off looking into Clojure for several months just given that it's based on the JVM; not only have I not recently had any reason to use the JVM, but my antipathy to Java is long-standing and well-documented.

However, in his LispNYC talk, Rich Hickey makes compelling points about why he based Clojure on the JVM, and I can't help but agree with many of them. Similarly, Neal Ford in his superb recent JRuby-related interview on JavaWorld makes a case that the actual positive legacy of Java will be the JVM as an established and widespread high-performance platform and infrastructure for enabling polyglot programming with the already more than 200 languages (including JRuby, Rhino, Jaskell and Jython) that you can run on it. I can buy that argument, too.

So, I'm coming to the unwelcome conclusion that my distaste for Java the language may have blinded me to the potential of the JVM as a platform for hosting other more powerful programming languages. I haven't much followed the JVM's evolution for years now, but intend to keep a closer eye on it in the future - especially the ongoing work around JSR 292 that aims to make the JVM suck less for hosting dynamic languages.

In any case, I'll be taking Clojure out for a spin. It's definitely a singularly unique new Lisp well worth looking at and learning from. I highly recommend Rich Hickey's two-hour LispNYC presentation which I can only describe as delightfully competent. (Also, in case STM is an unfamiliar concept, Simon Peyton-Jones's brief introduction at OSCON last year should be able to fill in the gaps some.)

Only after receiving many emails from readers, I noticed that I have
not posted the Linux version of the Bigloo/GUI tutorial. This may
explain why the stalin version of the tutorial is much in demand,
compared with the Bigloo version. BTW, the Linux tutorial, libraries,
and GUI examples are ready for download at

[link]
[link]
[link]
[link]
[link]
[link]
[link]
[link]