Why aren't you using Bigloo?
alex...@gmail.com
of Bigloo comes out. However, it's clear that the number of people
using Bigloo is quite small, even by Scheme standards. Going straight
to the source, I wanted to ask: why aren't YOU using it?
Here, I'll help taking this survey easier: Mark all that applies
[ ] Big "Loo" ?!
[ ] I don't even use Scheme
[ ] I'm suspicious of Boehm's GC
[ ] I'm suspicious of anything written by a single person
[ ] 30-bit integers and similarly short vectors aren't enough
[ ] I want a modern GUI library
[ ] Other: ____
Gabriel Ebner
> [ ] Big "Loo" ?!
> [ ] I don't even use Scheme
> [ ] I'm suspicious of Boehm's GC
> [ ] I'm suspicious of anything written by a single person
> [ ] 30-bit integers and similarly short vectors aren't enough
> [X] I want a modern GUI library
> [ ] Other: ____
Gabriel.
Ulrich Hobelmann
> [X] Big "Loo" ?!
> [ ] I don't even use Scheme
> [ ] I'm suspicious of anything written by a single person
> [ ] 30-bit integers and similarly short vectors aren't enough
> [ ] I want a modern GUI library
--
If you have to ask what jazz is, you'll never know.
Louis Armstrong
BR
drc...@gmail.com
what type of architecture I wanted my preferred scheme platform to
have- There seem to be three main factors that I think are most
critical in terms of scheme implementation architecture:
1. Is it fast?
2. Is it hosted in another language whose libraries are easily
leveraged?
3. Is it easy to use?
When looking at schemes from this lens, I would argue the landscape
falls into three camps- First, there are the fast compiled schemes
(chicken, gambit, bigloo, plt, etc.), the fast java/etc hosted schemes
(kawa, larceny, etc.) and the easy to use java/etc hosted schemes
(sisc, psyche, etc.)- This may not be how other people divide up
schemes, but it is how I like to think of them.
Once I knew what my priorities were and chose my "camps"- The next step
was easy: Type each name into google and pick the implementation in the
given "camp" with the greatest hits.
In the fast, compiled schemes noone can touch plt/dr/mzscheme for hits
in Google. I am aware that other compiled schemes can often outperform
plt, but the larger plt community is muchmuch more important to me than
minor performance differences. That's how I picked my scheme of choice.
Bigloo sounds great, but it would need to either have significant
qualitative or order-of-magnitude performance advantages to counter the
limitations of a much smaller user base to me, personally.
-Conrad
alex...@gmail.com
Speed. I think Bigloo is in a class of its own here (at least among
free Schemes). There are other things, but speed is the biggest
difference.
ronaldo
> There seem to be three main factors that I think are most
> critical in terms of scheme implementation architecture:
>
> 1. Is it fast?
> 2. Is it hosted in another language whose libraries are easily
> leveraged?
> 3. Is it easy to use?
>
I am a long time scheme programmer on MS platforms.
I use a completely different set of evaluation rules:
0. Is it a compiler?
1. Is it written in C?
2. Does it compile on my system?
3. Do I understand the source code?
4. Is there a proper system interface?
Speed is less of a concern to me.
I currently use rhizome/pi together with free Borland C tools.
Rhizome/pi
compiles on many platforms, is well documented and completely R5RS.
You do have to know your Petzold to do win32 programming with rhizome.
Ulrich Hobelmann
> I am a long time scheme programmer on MS platforms.
> I use a completely different set of evaluation rules:
> 0. Is it a compiler?
Isn't that totally unimportant (to which degree it is interpreted,
JITed, or "fully" compiled), as long as it meets your speed requirements?
> 1. Is it written in C?
Why would you care what language it's written *in*, as opposed to what
languages its output can link to?
> I currently use rhizome/pi together with free Borland C tools.
> Rhizome/pi
> compiles on many platforms, is well documented and completely R5RS.
> You do have to know your Petzold to do win32 programming with rhizome.
Funny, I've never even heard of that Scheme. Hey, it's a big big world :)
Förster vom Silberwald
BR wrote:
> Other. What does Bigloo give you that the other scheme's don't?
For me: 1. I can give some rudimentary type tags (e.g. a::vector,
b::MyClassComplex), 2. Pattern matching in a functional style, 3.
a.outs on my MacOSX, on my Ubuntu Linux and on our Sun workstations, 4.
Including external C functions is straightforward (at least for basic
types and structures) etc.
I do not use programming languages based on a broad community (hey
would you like to have dinner with a Common Lisp user?). Clean was the
great exception: there the basement of the community vanishes and
reaches zero.
Btw: I got a very cool advice recently: Bigloo becomes better when
debugging provided you were using the "-g4" option when compiling (you
get some stack trace).
Schneewittchen
Btw: Bigloo its shortcomming on integers can somehow being circumvented
by external C-types. But I concur: it is a trap.
ronaldo
>JITed, or "fully" compiled), as long as it meets your speed requirements?
NO! Distributing alle these nifty little programs to your
friends and relations, who don't know zilch about computers,
requires building executables with the simplest installation
procedure there is: copy and then click to run.
This means either a .exe or a .jar file.
>Why would you care what language it's written *in*, as opposed to what
>languages its output can link to?
Obviously, to see how it works! I know C better than
other languages. Moreover, the output language (C, Java)
is usually the same as the implementation language
(C, Java, Scheme). (Note that a C compiled Scheme dll
may also link to Visual Basic, Delphi etc.. MzScheme may
even be used as a COM server - see the PLT site.)
>Funny, I've never even heard of that Scheme. Hey, it's a big big world :)
Bigger than just the USA, that's for sure!
Search Google for english scheme pages in Japan -
you'll also find Small Scheme, KSM-Scheme and
Sorta-Scheme.
Why Japan? Remember the Fifth Generation Project?
BTW Rhizome/pi is in the scheme faq at schemers.org.
It has been since I had it put there some 5 years ago.
You'll want to read the faq every now and then!
Addendum 1
Rhizome/pi is in the same "camp" as Bigloo, Chicken and
Gambit but it is not as "bloated" (common lisp-ish?).
You see, I like small programs.
The latest release of rhizome/pi is embeddable.
Addendum 2
In the interpreter "camp" my evaluation criteria have led
me to UMB Scheme, which implements the interpreter
from SICP. The C source code is very clear.
You can modify this R4RS Scheme to suit any target platform.
Ludovic Courtès
"Förster vom Silberwald" <chain...@hotmail.com> writes:
> For me: 1. I can give some rudimentary type tags (e.g. a::vector,
> b::MyClassComplex)
Personally, this is something I do not like. I find these type tags
very non-Schemey and inelegant, both syntactically and conceptually.
Compilation techniques, namely type inference, /can/ theoretically make
such tagging useless.
Additionally, Bigloo seems to be quite poor in terms of SRFI implemented
(or at least, available "out of the box").
Thanks,
Ludovic.
alex...@gmail.com
> Hello,
>
> "Förster vom Silberwald" <chain...@hotmail.com> writes:
>
> > For me: 1. I can give some rudimentary type tags (e.g. a::vector,
> > b::MyClassComplex)
>
> Personally, this is something I do not like. I find these type tags
> very non-Schemey and inelegant, both syntactically and conceptually.
That's what I had thought. But, actually, things like b::my-type are
just symbols, amenable to decomposition and composition by low-level
macros, etc. Maybe the author should be more market-savvy here. Lispers
want programmable, syntaxless languages, and that's what Bigloo
provides, but it's not immediately clear to the reader.
> Compilation techniques, namely type inference, /can/ theoretically make
> such tagging useless.
Unfortunately, no. I believe all decent Schemes already do as much of
it as they can. Specifying the types lets the compiler produce better
code in those little pesky bottlenecks.
But then, if you don't want to squeeze out the extra performance, don't
specify the types. Problem solved.
Jens Axel Søgaard
> Ludovic Courtès wrote:
>>Compilation techniques, namely type inference, /can/ theoretically make
>>such tagging useless.
>
> Unfortunately, no. I believe all decent Schemes already do as much of
> it as they can.
If they did, they'd probably all be as slow as Stalin ;-)
--
Jens Axel Søgaard
Förster vom Silberwald
Ludovic Courtès wrote:
> Personally, this is something I do not like. I find these type tags
> very non-Schemey and inelegant, both syntactically and conceptually.
> Compilation techniques, namely type inference, /can/ theoretically make
> such tagging useless.
Hi: For me its more likle an issue of documenting my code. I am always
pleased with the following:
(define (a::vector ...))
instead of:
(define (a ...))
Surely:
(define (a-vector ...))
Why the first definition shouldn't count as not being Scheme like
escapes my imagination. Although, Bigloo often wants to trick you into
the believing that giving type tags are sound. It is not, some programs
will easily go through compilations stages but will fail on runtime due
to some type mismatches.
> Additionally, Bigloo seems to be quite poor in terms of SRFI implemented
> (or at least, available "out of the box").
This is true. However, I sometimes have the feeling that a lot of
people do not thouroughly study the Bigloo manual. Bigloo is really
quite an extension to some standard. People will miss out a lot if they
do not study the manual for some appetizers to go.
That said: I must honestly confess I know Bigloo a bit and it serves me
well on all my projects. It is simply a pragmatic stance of mine. There
is a point in ones own life where a programmer is pleased with what he
has at his disposal. I am in academia and may use what I want (at least
up this date).
If I had some more motivation I would reach out for evaluating (in
depth) some more languages and environments. However, I am poor at
that; I am the guy who knows exactly 4 or 5 commands in Emacs and makes
a life with Emacs by means of a "mouth". Yes I know I will miss out a
lot.
Schneewittchen
Förster vom Silberwald
ronaldo wrote:
> I am a long time scheme programmer on MS platforms.
> I use a completely different set of evaluation rules:
> 0. Is it a compiler?
> 1. Is it written in C?
> 2. Does it compile on my system?
> 3. Do I understand the source code?
> 4. Is there a proper system interface?
> Speed is less of a concern to me.
> I currently use rhizome/pi together with free Borland C tools.
> Rhizome/pi
> compiles on many platforms, is well documented and completely R5RS.
> You do have to know your Petzold to do win32 programming with rhizome.
If you like you can contribute to Bigloo. As I have seen on the Bigloo
mailing list there are some issues with Bigloo on Windows. Some have
expressed their wishes that Bigloo should have been better integrated
into Windows. Personally I do not have access to Windows and cannot
comment on it but for the discussions what I have wittnessed on the
mailing list.
Okay, Bigloo is not completely R5RS. But I think a versed Scheme
programmer like you can easily cope with such a tiny shortcomming.
Bigloo (at least its core) will then run on: Windows, Mac OSX, Unix
like systems and some other flavors due to its C inheritance. Okay, PLT
Scheme is also good in this respect and some other Scheme
implementations.
Schneewittchen
Förster vom Silberwald
Förster vom Silberwald wrote:
> Okay, Bigloo is not completely R5RS. But I think a versed Scheme
> programmer like you can easily cope with such a tiny shortcomming.
One has to add: Bigloo its manual does not in any case hide what is has
to offer and not. I think Bigloo its manual always makes it clear what
actually belongs to R5RS and what might be seen as an extension.
The latter is my big criticism concerning the Dr.Scheme manual (at
least the one I pinched with my Mac OSX download): for me it has been
never clear what is native Dr.Scheme or PLT, etc. and what is native
R5RS or some extension: It is sometimes hidden in between the text.
Bigloo has a different strategy:
==
string-compare3 string1 string2 bigloo procedure
string-append string ... library procedure
vector? obj procedure
==
The manual has always a column entry (actually it comes out better in
the manual).
Schneewittchen
Ulrich Hobelmann
>> Isn't that totally unimportant (to which degree it is interpreted,
>> JITed, or "fully" compiled), as long as it meets your speed requirements?
>
> NO! Distributing alle these nifty little programs to your
> friends and relations, who don't know zilch about computers,
> requires building executables with the simplest installation
> procedure there is: copy and then click to run.
> This means either a .exe or a .jar file.
True. On the Mac it's easier, just create a bundle directory (which all
applications are) and stick your runtime and your data into it. Maybe
you could bundle both code and data into one .exe file as well (by
transforming the data into a huuge C char array :D).
> Why Japan? Remember the Fifth Generation Project?
The Prolog-in-hardware thing?
> Addendum 1
> Rhizome/pi is in the same "camp" as Bigloo, Chicken and
> Gambit but it is not as "bloated" (common lisp-ish?).
> You see, I like small programs.
> The latest release of rhizome/pi is embeddable.
Cool.
--
We're not some magical new civilization, full of wisdom and technology.
We're wading through the same mud and chaos as we were 2000 years ago.
alex...@gmail.com
I've never heard of Rhizome/pi scheme before. How is it compared to C++
in speed?
You see, there are two types of Lisp users: those who would, given a
binary choice, use Fortran, and those who would use Basic. Their
demands regarding the acceptable speed are also different.
ronaldo
>The Prolog-in-hardware thing?
Among others. A while back, for anything Lisp you would go to the USA,
to France for Prolog. With the project Japan has joined the list of
countries seriously involved in symbolic programming. Is it a wonder
these three are at the heart of W3C?
ronaldo
>binary choice, use Fortran, and those who would use Basic.
in Fortran or Basic doesn't really matter.
>I've never heard of Rhizome/pi scheme before. How is it compared to C++ in speed?
runtime lib that contains the code for bignums, gc, eval etc.. The C
code produced is of necessity slower than handwritten C code - there
are checks to be done and protocols to be followed - but there is a
very big speed improvement in development time.
I do not really know how rhizome compares to other scheme2c compilers.
Ulrich Hobelmann
Hm, I don't have a very high opinion of the W3C. ;)
So far my impression was that the USA are Lisp, France is Caml, Japan
was Prolog, and the UK is Haskell. Germany is some Scheme, but mostly
just Java and XML. We sold our innovation to running after
pseudo-innovators (among which I include the W3C). No matter how many
fools follow them, touting bad, bloated, sloooooow reinventions of
Lisp's wheels just isn't cool.
ronaldo
I'm pretty confident that M. Serrano can, and will, take care of it
himself.
James Graves
>>Why would you care what language it's written *in*, as opposed to what
>>languages its output can link to?
>
>Obviously, to see how it works! I know C better than
>other languages. Moreover, the output language (C, Java)
>is usually the same as the implementation language
>(C, Java, Scheme). (Note that a C compiled Scheme dll
>may also link to Visual Basic, Delphi etc.. MzScheme may
>even be used as a COM server - see the PLT site.)
A possible point of interest: the Scheme 48 virtual machine is written
in Pre-Scheme. Actually, almost everything in Scheme 48 is written in Scheme.
There is (of course) some C code for the Unix or Win32 interfaces.
BTW, Scheme 48 is in the "interpreted" camp.
James Graves
Christoph Breitkopf
It never felt like Scheme to me. Dunno why exactly. Might be:
No proper tail-recursion, no repl, strange (to me)
module declarations and separate compilation (I know, it's a feature).
More like C with Scheme syntax than Scheme.
Regards,
Chris
alex...@gmail.com
> alex...@gmail.com writes:
> > On the Bigloo mailing list, we jump with joy every time a new version
> > of Bigloo comes out. However, it's clear that the number of people
> > using Bigloo is quite small, even by Scheme standards. Going straight
> > to the source, I wanted to ask: why aren't YOU using it?
> >
> > Here, I'll help taking this survey easier: Mark all that applies
> >
> > [ ] Big "Loo" ?!
> > [ ] I don't even use Scheme
> > [ ] I'm suspicious of Boehm's GC
> > [ ] I'm suspicious of anything written by a single person
> > [ ] 30-bit integers and similarly short vectors aren't enough
> > [ ] I want a modern GUI library
> > [X] Other: ____
>
> It never felt like Scheme to me. Dunno why exactly. Might be:
> No proper tail-recursion,
I'll let R5RS language lawyers field this one. I don't believe there
are any issues within the same compilation unit, at least.
> no repl,
Have you tried typing `bigloo' at the command prompt?
Again, I think Manuel failed to market Bigloo well. I do believe the
web site used to say that Bigloo is (only) a batch compiler.
> strange (to me) module declarations
As I understand, macros can not expand [into|within] module
declarations. If I'm right, this feels like a non-Lispy limitation.
However, two points about module declarations:
1. They can be the bare minimum: the name of the module, imported
modules, and exported values:
(module my-module (export fun1 fun2 var1 var2) (import mod1 mod2))
2. Modules need not correspond to compilation units, so you can stick
everything into one module, if that is your preference.
> and separate compilation (I know, it's a feature).
I probably don't understand the issue here. What prevents you from
putting everything in one file?
> More like C with Scheme syntax than Scheme.
Not quite. Closures, syntactic abstraction, exceptions, garbage
collection and fine control over safety (compiler switches) are all in
Bigloo, but not in C.
Christoph Breitkopf
> Again, I think Manuel failed to market Bigloo well. I do believe the
> web site used to say that Bigloo is (only) a batch compiler.
It still says so in the manual.
> > strange (to me) module declarations
>
> I probably don't understand the issue here. What prevents you from
> putting everything in one file?
I don't want to. I prefer multiple files.
> > More like C with Scheme syntax than Scheme.
>
> Not quite. Closures, syntactic abstraction, exceptions, garbage
> collection and fine control over safety (compiler switches) are all in
> Bigloo, but not in C.
Well, like I said a lot of my reservations about bigloo are on
a gut-level feeling. I'm sure if I was forced to use it for a
real project it would work out well.
I started to use bigloo once for performance reasons. Stopped
when I noticed it has no native threads (At least, that's what the
manual says). Single processor performance is nice, but not
sufficient these days.
Regards,
Chris
BR
> I am a long time scheme programmer on MS platforms.
> I use a completely different set of evaluation rules:
> 0. Is it a compiler?
> 1. Is it written in C?
> 2. Does it compile on my system?
> 3. Do I understand the source code?
> 4. Is there a proper system interface?
> Speed is less of a concern to me.
>
> I currently use rhizome/pi together with free Borland C tools.
> Rhizome/pi
> compiles on many platforms, is well documented and completely R5RS.
> You do have to know your Petzold to do win32 programming with rhizome.
That reminds me. Is there any scheme that integrates with VS 2005?
alex...@gmail.com
> I don't want to. I prefer multiple files.
Multiple files, one module? As I mentioned, you can have that. Unless I
don't understand what you want, in which case please elaborate.
> Single processor performance is nice, but not
> sufficient these days.
A single-threaded program running on 1 CPU vs a 10-times slower one
running on 2-way SMP? It's a tough choice :-P
Anyway,
> I started to use bigloo once for performance reasons. Stopped
> when I noticed it has no native threads (At least, that's what the
> manual says).
The latest release version has pthreads:
http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-4.html#Modules
> Well, like I said a lot of my reservations about bigloo are on
> a gut-level feeling. I'm sure if I was forced to use it for a
> real project it would work out well.
They seem to be mostly based on misperceptions, partly Manuel's failure
to market.
Like yourself, I was put off by Bigloo when I first looked at it,
mainly because Hello World does not run without some module
declaration, even though it's just one line, really. (Note to Manuel:
add a default BIGLOO-USER module if no modules are specified) Secondly,
not to point fingers, I noted someone's pro-Bigloo advocacy that was
actually counter-productive with me.
James Graves
<alex...@gmail.com> wrote:
>On the Bigloo mailing list, we jump with joy every time a new version
>of Bigloo comes out. However, it's clear that the number of people
>using Bigloo is quite small, even by Scheme standards. Going straight
>to the source, I wanted to ask: why aren't YOU using it?
>
>Here, I'll help taking this survey easier: Mark all that applies
>
>[ ] I don't even use Scheme
>[ ] I'm suspicious of Boehm's GC
>[ ] I'm suspicious of anything written by a single person
>[ ] 30-bit integers and similarly short vectors aren't enough
>[ ] I want a modern GUI library
>[X] Other: ____
I'd heard of Bigloo, but never investigated it. Mostly been using DrScheme's
enviroment to teach myself FP. It also has plenty of nifty stuff for experimenting
with GUIs and network programming.
And I'm using Scheme 48 for my research into object level confinement.
At some point, I may want to use a Scheme for some embedded projects (my day job).
I'd probably want something that compiles to C, and can be ported to other operating
systems which don't necessarily have Posix support (like a stripped down version of
eCos, for example).
James Graves
alex...@gmail.com
> That reminds me. Is there any scheme that integrates with VS 2005?
I don't know how backwards compatible VS 2005 is, but Bigloo has some
VS 2003 integration (that I never used though, in this combination):
http://www.yannis.bres.name/Bigloo/
alex...@gmail.com
alex...@gmail.com wrote:
> The latest release version has pthreads:
>
> http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-4.html#Modules
>
Wrong link
http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-9.html#Posix-Threads
Waldek Hebisch
> >Isn't that totally unimportant (to which degree it is interpreted,
> >JITed, or "fully" compiled), as long as it meets your speed requirements?
>
> NO! Distributing alle these nifty little programs to your
> friends and relations, who don't know zilch about computers,
> requires building executables with the simplest installation
> procedure there is: copy and then click to run.
> This means either a .exe or a .jar file.
So you want standalone executables, not a compiler. The difference may
be not so clear with scheme, but there are many compilers which do _not_
generate standalone executables either because they are image-based (SBCL
is a nice example) or due to shared libraries. OTOH many interpreters are
embeddable and allow generating executables (which bundle interpreter and
the program in a single binary).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Eli Barzilay
> The latter is my big criticism concerning the Dr.Scheme manual (at
> least the one I pinched with my Mac OSX download): for me it has
> been never clear what is native Dr.Scheme or PLT, etc. and what is
> native R5RS or some extension: It is sometimes hidden in between the
> text.
It should not be hidden. DrScheme's Help Desk should have different
manuals for R5RS, MzScheme, MzLib etc. The MzScheme manual generally
doesn't document things that are in R5RS, but it should be explicit
about extensions to R5RS. If there is text that can make you think
that some MzScheme functionality is in R5RS or the other way, then
it's a bug.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
alex...@gmail.com
Some random impressions/questions about R/Pi:
Is 45k LOC lean for a Scheme implementation? Half of it is C, but it
doesn't look auto-generated, just well-indented and virtually
comment-less.
I grep'ed the sources for "garbage", but couldn't find anything
related to GC. I hope it does have one.
The compilation procedure is a bit unfriendly: "Select suitable sub
directory and copy files in it to appropriate place, and edit its
contents if neccessary". Which of the ~5 files go into which
directory? Hmm...
Christoph Breitkopf
> > I don't want to. I prefer multiple files.
>
> Multiple files, one module? As I mentioned, you can have that. Unless I
> don't understand what you want, in which case please elaborate.
Don't bother - It's been some time since I looked at bigloo, and
currently I don't have the pleasure of working in Scheme.
Will check out bigloo again should a Scheme/Lisp project come up.
> > Single processor performance is nice, but not
> > sufficient these days.
>
> A single-threaded program running on 1 CPU vs a 10-times slower one
> running on 2-way SMP? It's a tough choice :-P
Well, that sums it up quite nicely, I'm afraid. ;-) I'm quite
disappointed with MP-support in the whole Lisp/Scheme community,
but now this seem to be rapidly improving. A year ago, things
were looking rather bleak.
Regards,
Chris
MJ Ray
> [ ] I want a modern GUI library
I want support for GNUstep, PostgreSQL and web development that
looks reasonably like some other libraries. Having users nearby
also helps, but less so.
Last I looked at Bigloo, it was relatively large, didn't seem
to support GNUstep/Cocoa easily and I didn't understand the
psql and web extensions quickly enough.
ronaldo
>related to GC.
GC is in kappa/cellhdlr.c
>Which of the ~5 files go into which directory? Hmm...
See the next few lines. Are you in that much haste that you
do not read the install file (only 211 lines) completely?
OK. Unzip the package, create bin and lib directories, copy
(your C compiler) configuration files from config dir to the
appropriate place and do make. That's all there is to it.
alex...@gmail.com
True, I forgot about the ones that run the program at compile time and
reduce it to
(write 17.32323)
:-)
Speaking of Stalin, a few questions:
The README says it's impossible to tell when it's using floats or
doubles. Is this true?
How does the compilation time depend on the program size? What would it
take to compile a 10-100k program?
Why "Stalin" ? Better than "Loo", I admit, but still.
MikhailGorbachev DONTSPAM gmail.com
[ ] I don't even use Scheme
[ ] I'm suspicious of Boehm's GC
[ ] I'm suspicious of anything written by a single person
[X] I want a modern GUI library
[X] Other: I like the proposed features of Arc, and am writing a
language of my own
Andi
- IDE with nice arrows
- libraries (PLaneT, sqlite)
- webserver included
I can't recall the exact reasons against Bigloo though
--
Andi
| Mail: bez...@web.de
| Web: http://beza1e1.tuxen.de
| Jabber: bez...@amessage.de
rsher...@gmail.com
Because it's a STAtic Language ImplementatioN. Compare to Dylan, a
DYnamic LANguage.
Rob Thorpe
I think it's called Stalin because your computer sends you to siberia
while it compiles.
Ulrich Hobelmann
If you want to execute your program many times, fast, well, Stalin is
the master of execution. ;)
The preparations take a while, though.
--
I wake up each morning determined to change the world...
and also to have one hell of a good time.
Sometimes that makes planning the day a little difficult.
E.B. White
alex...@gmail.com
high-performance Lisps might be interested}
My view is that Bigloo's big failing is in MARKETING and the first
impression it makes on someone new to Bigloo, but not necessarily new
to Scheme/Lisp. I know this from first-hand experience and how people
responded to the survey. The problems of the first impression are
easily fixable, although you can't undo years of bad marketing.
Bigloo fails to get these points across (these should be on the front
page somewhere)
1. There are compiled Schemes, and then there are COMPILED Schemes. In
my tests, Bigloo actually beats Stalin handily on code that Stalin's
author had not seen. Stalin does well on the benchmarks included with
it, but overall, its performance seems to be unpredictable, while
Bigloo is consistently very good. I don't claim to have tested every
Lisp in the world, but my impression so far is that Bigloo has no
equal.
2. Bigloo does have a REPL
3. Type declarations are optional, and they are part of the symbol
being declared, not syntax scattered around the code. Macros can see
them, and macros can create them. When I think about it, it's hard to
come up with anything more convenient (And I'm aware of Common Lisp's
approach)
P.S. My lawyer told me to add this disclaimer: if you morally oppose
cross-posting, don't read the above :-) Bigloo is what brought me to
the Scheme camp though. I'm usually sitting on the fence or close to
it, between CL and Scheme.
rsher...@gmail.com
>impression it makes on someone new to Bigloo
Are the authors (or should that be author?) of Bigloo interested in
marketing? An academic's job is to do original research, not to write
the intellectually boring libraries that are necessary for a popular
language, solve intellectually boring build problems across platforms,
evangelize a language, and answer questions on a mailing list. Note
that most popular languages don't come from university researchers.
I haven't followed Bigloo too closely, but I've but I've certainly had
the impression from other languages written by other researchers that,
with some exceptions, they either don't care or don't have time to try
to build a community or becoming popular (which is appropriate, IMHO,
because they're paid to do research, not to become the BDFL of the next
hot language).
BR
> Note that most popular languages don't come from university researchers.
*looks at group header*
Oops! :)
Förster vom Silberwald
alex...@gmail.com wrote:
> 1. There are compiled Schemes, and then there are COMPILED Schemes. In
> my tests, Bigloo actually beats Stalin handily on code that Stalin's
> author had not seen. Stalin does well on the benchmarks included with
> it, but overall, its performance seems to be unpredictable, while
> Bigloo is consistently very good. I don't claim to have tested every
> Lisp in the world, but my impression so far is that Bigloo has no
> equal.
I have to sort out your message: can you elaborate a little bit (maybe
in a new thread) and give some concrete examples where Stalin falls
behind. Your remarks seems very interesting to me.
Sir Franics Drake
Förster vom Silberwald
rsher...@gmail.com wrote:
> >My view is that Bigloo's big failing is in MARKETING and the first
> >impression it makes on someone new to Bigloo
>
> Are the authors (or should that be author?) of Bigloo interested in
> marketing? An academic's job is to do original research, not to write
> the intellectually boring libraries that are necessary for a popular
> language, solve intellectually boring build problems across platforms,
> evangelize a language, and answer questions on a mailing list. Note
> that most popular languages don't come from university researchers.
I for one do not think Bigloo has bad marketing. Surely, there are some
misconceptions and as I have written many times: it is due to the fact
that a lot of people who are using Bigloo never really will invest time
in browsing through the manual. They know some Scheme and get some
micsconception regarding Bigloo.
My first encounter with Bigloo was as follows: I dumbed fucking Python
(I do not understand and never will understand what actually attratcs
people to Python. I fail to grasp) and saw some Bigloo on the language
shootout page. The original Bigloo homepage made a /very, very
professional and serious impression/ to me and it was easy for me to
jump on the Bigloo bandwagon.
And we may not forget: Bigloo is not a toy project. Dr. Serrano is on
the important commitees and all the things will hopefully get
integrated proper into Bigloo.
However, lets get real: there are a lot of other good and /stable/
Scheme implementations out there as well: DrScheme, Chicken, etc.
Sir Francis Drake
Btw: Prior to buying my ibook and Mac OSX I had to make sure that
Bigloo will run on it. If Bigloo hadn't been known for running on Mac
OSX I would not have bought an ibook.
Ulrich Hobelmann
> (I do not understand and never will understand what actually attratcs
> people to Python. I fail to grasp)
Its use of indented expressions/statements WITHOUT parentheses. It
seems that parentheses are indeed very evil.
Of course that doesn't prevent people from advocating numerous
unreadable XML formats, even though they hate XML. Maybe round
parentheses escape their memory, while <> ones burn their image into
your mind forever. That, and that every closing tag takes up an extra
line, just as in Java/C {} syntax.
Marcin 'Qrczak' Kowalczyk
> That, and that every closing tag takes up an extra line, just as in
> Java/C {} syntax.
Putting closing tags in separate lines is more readable for me,
as long as there are not too many of them. Scheme has too many
of them and cannot be indented readably.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Ulrich Hobelmann
> Ulrich Hobelmann <u.hob...@web.de> writes:
>
>> That, and that every closing tag takes up an extra line, just as in
>> Java/C {} syntax.
>
> Putting closing tags in separate lines is more readable for me,
> as long as there are not too many of them. Scheme has too many
> of them and cannot be indented readably.
Well, but in C I don't have named let, or cool looping constructs as in
Common Lisp, so I think the ()s are worth it for me :)
Most languages have more compact syntax by sacrificing many constructs
or at least the possibility of a decent macro system. I think I
wouldn't be happy with Python.
Marcin 'Qrczak' Kowalczyk
>> Putting closing tags in separate lines is more readable for me,
>> as long as there are not too many of them. Scheme has too many
>> of them and cannot be indented readably.
>
> Well, but in C I don't have named let, or cool looping constructs
> as in Common Lisp, so I think the ()s are worth it for me :)
I didn't say that I prefer C the language to Scheme the language.
I only dislike Scheme syntax.
> Most languages have more compact syntax by sacrificing many
> constructs or at least the possibility of a decent macro system.
I'm going to show that decent macros don't need so many parens.
It will take some time, since I want hygiene done right too.
R5RS is wrong, SRFI-72 is right or mostly right. I haven't
designed separate compilation issues yet, and implementation
will take some time too.
rsher...@gmail.com
>> people to Python. I fail to grasp)
>Its use of indented expressions/statements WITHOUT parentheses. It
>seems that parentheses are indeed very evil.
It seems that the way that a language becomes popular is to offer an
improvement over existing fare, but in such a way that it doesn't
require much thought to migrate to it, because programmers are
conservative. Java was a better C++, C++ was a better C, Perl was a
better sed/awk/grep, Python was a better Perl, Ruby is a better Python
(at least according to their advocates). None of them required a
radical shift in thinking from what came before. Scheme and Lisp both
do, and the syntax is one of the things that makes them harder to
learn. Parentheses ARE evil before you learn not to count them, and
they remain evil if your editor/IDE of choice doesn't support Lisp well.
Ulrich Hobelmann
> conservative. Java was a better C++, C++ was a better C, Perl was a
> better sed/awk/grep, Python was a better Perl, Ruby is a better Python
> (at least according to their advocates). None of them required a
But a friend of mine is mostly turned off by Lisp's weirdness (including
syntax). So far he only knew Java and Pascal (mostly), but he likes Ruby.
I don't like any of the above languages, though I don't know Perl, Ruby,
Python too well. Maybe that's because they only try to improve other,
IMHO crappy, languages ;)
> radical shift in thinking from what came before. Scheme and Lisp both
> do, and the syntax is one of the things that makes them harder to
> learn. Parentheses ARE evil before you learn not to count them, and
> they remain evil if your editor/IDE of choice doesn't support Lisp well.
Scheme makes some trouble to some people, because it's so functional. I
could never quite go as far as Haskell, so I can understand that, though
I like Scheme or ML.
Maybe Emacs is a reason why Lisp isn't more popular, because most people
seem to hate it out there, even when the installed alternative is an
editor that can't even autoindent XML and balance tags automatically. ;)
James Graves
>I didn't say that I prefer C the language to Scheme the language.
>I only dislike Scheme syntax.
[...]
>I'm going to show that decent macros don't need so many parens.
>It will take some time, since I want hygiene done right too.
>R5RS is wrong, SRFI-72 is right or mostly right. I haven't
>designed separate compilation issues yet, and implementation
>will take some time too.
It is the prefix notation that gives Scheme the capability of a powerful
macro system.
Infix languages typically can't support powerful macro systems because
they have complicated operator precedence. Check the Gotchas section
(number 12) on Norvig's guide to Python for CL users:
http://www.norvig.com/python-lisp.html
So it is the relatively simple syntax of LISP languages which makes
powerful macro systems possible. What you see in a .scm file is not far
away from the actual structure of the code as used by computer.
Directly manipulating _that_ is a powerful concept.
I am sure you can design a language with a different syntax than Scheme
which has a powerful macro system. That will be interesting, please
keep us posted.
James Graves
alex...@gmail.com
I can, but I don't think it's a good idea. If I just say what I did,
it's just my *vote* (it seems to me that Bigloo may actually be faster
on real code), but if I post examples, it looks as if I'm proposing a
*proof* that Stalin is slower. See the difference?
Even if I spend 2 hours writing about how my example is not "proof" of
relative speed, about selection bias, etc., some USENET asshole will
think he'll look smart if he paraphrases all that back to me in form
of an accusation.
If you want to have an implementation/language speed comparison with
examples, post your own examples. IF they are interesting, we might
have a discussion about them.
David Rush
> Förster vom Silberwald wrote:
> > alex...@gmail.com wrote:
> >
> > > 1. There are compiled Schemes, and then there are COMPILED Schemes. In
> > > my tests, Bigloo actually beats Stalin handily on code that Stalin's
> > > author had not seen. Stalin does well on the benchmarks included with
> > > it, but overall, its performance seems to be unpredictable, while
> > > Bigloo is consistently very good. I don't claim to have tested every
> > > Lisp in the world, but my impression so far is that Bigloo has no
> > > equal.
> >
> > I have to sort out your message: can you elaborate a little bit (maybe
> > in a new thread) and give some concrete examples where Stalin falls
> > behind.
>
> I can, but I don't think it's a good idea.
Well many moons ago I did a fair bit of side-by-side comparison of
Scheme implementations in my quest for serious high-performance for
data mining in 2000-dimensional datasets. I could dig out my results
(although they live somewhere back in the data crypt that is
groups.google) but to summarize: Stalin produces the fastest code of
*anything*, assuming that you write well-typed Scheme code. This is
harder than you might think, and is probably the reason for your
experience with Stalin.
Bigloo was #2 by a factor of at least 3 (it was a decimal order of
magnitude before I started tweaking gcc options) - and Bigloo gets fast
(or at least used to) by making some ugly tradeoffs w/rt RnRS
semantics. And no, I don't really remember them anymore, I just
remember my Bigloo code crashing mysteriously, when every other Scheme
(including Stalin) would run the code to completion - which left me
with grave doubts about Bigloo's commitment to full TCO, which, I might
add, is crucial is you want to program in a truly type-aware idiom.
Gambit and Larceny came in very close to each other for the third place
spot. IIRC, I think Larceny won, and it was my favorite platform for a
long time - up until my Intel CPUs were kicking my Sparc systems' butts
(the Sparcs were not upgraded due to corporate policy). Gambit has
supplanted Larceny, because it's (with appropriate gsc and gcc tweaks)
darn close to as fast as Bigloo and *much* closer to RnRS in crucial
areas like full TCO, numeric compliance &cet.
Given all that, I still love Bigloo, if only because it's a great
example of how C programming *ought* to work. It is also very fast and
it's pretty darn easy to graft C libraries onto it.
As in all such things though, YMMV. I love the amount of choice there
is in Scheme. At one point I had my data-mining codebase building on
five or six different platforms.
david rush
--
Scheme ex-geek
Ray Dillinger
> Ulrich Hobelmann <u.hob...@web.de> writes:
>
>
>>That, and that every closing tag takes up an extra line, just as in
>>Java/C {} syntax.
>
>
> Putting closing tags in separate lines is more readable for me,
> as long as there are not too many of them. Scheme has too many
> of them and cannot be indented readably.
>
It can, but it isn't the default way emacs does it....
I've been meaning to make an emacs mode for this, but
I haven't gotten around to it.
Instead of indenting to the first space in the previous
line, you can indent 3 (or 2) spaces per nesting level.
It's not *quite* as readable for small expressions and
toy code, but when things start getting thick the preservation
of horizontal space is worth it.
I actually find it more annoying that emacs is
*inconsistent* in its indentation (for example in
indenting lambda and let expressions, it uses a
different rule) than I find indentation that
rigorously follows either rule.
Bear
pocm...@gmail.com
alex...@gmail.com escreveu:
>
> Speed. I think Bigloo is in a class of its own here (at least among
> free Schemes). There are other things, but speed is the biggest
> difference.
Are there any benchmarks against other Schemes, for example PLT Scheme?
Ray Dillinger
> I'm going to show that decent macros don't need so many parens.
> It will take some time, since I want hygiene done right too.
> R5RS is wrong, SRFI-72 is right or mostly right. I haven't
> designed separate compilation issues yet, and implementation
> will take some time too.
I'm going to show that Lisp doesn't need macros. Nothing
is "wrong", per se, with anything, except that in traditional
lisps the rules of interpretation of function calls make
functions underpowered.
Macrology is a way to access a restricted class of first-order
functions - basically those amenable to static analysis -
efficiently. What I have done in a toy interpreter is to make
first-order functions into entities that are also first class,
removing the restriction and allowing code that *isn't* amenable
to static analysis, although it is compute-time expensive (like
runtime macro expansion in traditional lisps).
What I *believe* can be done, and *hope* to do, with a smart
optimizing compiler and aggressive inlining of functions that
do unusual things with their argument expressions, is to make
99%+ of the cases that are amenable to static analysis - the
class of first-order functions available via macrology - as
efficient as accessing them via macros. And the remaining
cases, as far as I can tell, represent new expressive
capabilities anyway, so it doesn't really matter for purposes
of comparison if they are compute-time expensive.
Bear
Ray Dillinger
> It is the prefix notation that gives Scheme the capability of a powerful
> macro system.
That's true, but you could make still the syntax less alien
to other-language users, for example, by making function calls
look more like function calls in the languages they're used
to. Lisp syntax is traditionally
(function arg1 arg2 arg3)
and someone raised on some other language would probably
be less baffled by
function(arg1 arg2 arg3)
You still have prefix syntax, you still have the parse tree
in a standard form amenable to macrology, but you've made
some progress toward helping non-lispers understand what's
going on.
I dunno though; looking at it sort of makes me uneasy, and I
don't like it as well as traditional lisp syntax, but... that
may just be a matter of me liking what I'm used to.
Bear
alex...@gmail.com
> Bigloo was #2 by a factor of at least 3 (it was a decimal order of
> magnitude before I started tweaking gcc options) - and Bigloo gets fast
> (or at least used to) by making some ugly tradeoffs w/rt RnRS
> semantics.
Same factor of 3 here, but in favor of Bigloo, on some fixnum-intensive
code with no floating point. And I didn't even supply any
Bigloo-specific type declarations (regular Scheme)
Two tips/opinions: Bigloo is the one that's more "type-aware" (INRIA
and all); use -Obench / -O6 (safe, but slightly slower) to turn the
optimizations on.
P.S. It's possible that I'm not using Stalin right, I just supply -On
argument it demands.
P.P.S. It's also possible that Stalin does better on floating
point-intensive jobs, which I didn't test it on much.
alex...@gmail.com
And I thought it was because of the attitude: only enemies of the state
need macros.
Bruce Hoult
rsher...@gmail.com wrote:
Dylan does in fact stand for DYnamic LANguage, but that's really only in
comparison to what it was inteded to be competition for: C, C++, Pascal.
It's less dynamic than Scheme or CL or SmallTalk or Python or Ruby.
Which of course the people who designed and named it knew very well,
since they were themselves CL and SmallTalk experts and implementors.
The point was to be able to put something more dynamic and flexible in
front of C++ users, while being careful enough about *how* dynamic so
that a sufficiently good (but practical) compiler could keep the
performance up there with C++ code. Which d2c does pretty well.
In the meantime, the state of the arts of Scheme and CL compilers has
improved quite a bit since 1992, and the better ones also are in the
same ballpark with C++, as shown by for example the Computer Language
Shootout (but where are the Scheme compilers other than Chicken?).
--
Bruce | 41.1670S | \ spoken | -+-
Hoult | 174.8263E | /\ here. | ----------O----------
David Rush
> Two tips/opinions: Bigloo is the one that's more "type-aware"
Ummm - Bigloo is brain-damaged about types. It (historically, I've been
out of the Bigloop for at least 2 years) simply uses the fastest native
types in a very simple-minded fashion.
Stalin requires you as the programmer to be type-aware and very
consistent in your use of types. Imagine Stalin as being like an SML
compiler where, instead of the compiler throwing your program out as
*wrong*, the performance just degrades to accomodate the necessity for
run-time type disambiguation.
> P.S. It's possible that I'm not using Stalin right, I just supply -On
> argument it demands.
You're not, but it's not a matter of compilation options, it's a matter
of learning to think about your program structure typologically. A
classic example is the ASSOC function which has the type:
(datum, datum pair list) -> boolean | datum pair
The return type alone guarantees the necessity of run-time type
dispatch getting compiled into your code. Now compare that to ASSOC-K
(a non-standard function which I have in my standard library):
(assoc-k tag a-list k-success k-fail):
(datum, datum pair list, datum pair -> datum, nil -> datum)
which completely eliminates the run-time dispatch involved with the
failure case of ASSOC. Carrying this type-awareness through you can
make sure that ASSOC-K's context *also* receives a monomorphic value,
which eliminates even more type dispatch.
In summary, Stalin makes your code go fast only when it can *prove* the
correctness of the speedup. Bigloo makes your code go fast by doing
nothing. At the end of the day, Stalin can make your code go *faster*
if you program in a type-sensitive way. Some may argue whether or not
this violates the spirit of Scheme, but as far as I'm concerned, all
programs should be striving for a high degree of type coherence.
And I'm not religious about this either. If I was I'd be programming in
SML, but the lesson of SML is still very useful: high levels of
type-coherence tend to promote *correct* programs. It's also bloody
nice that they can be made to go very fast.
david rush
alex...@gmail.com
> You're not, but it's not a matter of compilation options, it's a matter
> of learning to think about your program structure typologically.
I don't think I need to learn that. I did my share of ML coding. I just
looked in the manual though, and found out that Stalin does not provide
GCC with any compile-time options, and decided to try -copt -O3, and
woah 6x improvement! Hmm...
David Rush
alex...@gmail.com wrote:
> Here, I'll help taking this survey easier: Mark all that applies
>
> [ ] Big "Loo" ?!
> [ ] I don't even use Scheme
> [x] I'm suspicious of Boehm's GC
I've had actual bugs that were clearly related to Boehm's GC.
> [ ] I'm suspicious of anything written by a single person
> [x] 30-bit integers and similarly short vectors aren't enough
> [ ] I want a modern GUI library
> [x] Other:
Broken TCO. Slow CALL/CC.
Big plus (assuming I remember the functions correctly and they're still
supported): read/regex and read/lalr.
david rush
Hermann Jurksch
> Gambit and Larceny came in very close to each other for the third place
> spot. IIRC,
Did you compare an actual Gambit Beta or Gambit 3.0?
Regards
Hermann
Ulrich Hobelmann
> (function arg1 arg2 arg3)
>
> and someone raised on some other language would probably
> be less baffled by
>
> function(arg1 arg2 arg3)
Maybe. But that kind of function syntax is why I try to use Lisp over
ML or Java wherever I can. As soon as expressions are only a tiny bit
nested, it's completely unreadable.
Ulrich Hobelmann
> Dylan does in fact stand for DYnamic LANguage, but that's really only in
> comparison to what it was inteded to be competition for: C, C++, Pascal.
> It's less dynamic than Scheme or CL or SmallTalk or Python or Ruby.
> Which of course the people who designed and named it knew very well,
> since they were themselves CL and SmallTalk experts and implementors.
Like, um, Lisp guy James Gosling? No, I'm being unfair. Dylan doesn't
seem bad at all.
Anton van Straaten
> I just
> looked in the manual though, and found out that Stalin does not provide
> GCC with any compile-time options, and decided to try -copt -O3, and
> woah 6x improvement! Hmm...
See Siskind's posts in this thread (about a raytracer benchmark):
http://groups.google.com/group/comp.lang.scheme/browse_frm/thread/349c51b1d30d2b3e/e47fa8ae534cc8f4
The options used for the Stalin compiles are given as:
-Ob
-Om
-On
-Or
-Ot
-dP
-dC
-dh
-q
-d
-db
-architecture IA32-align-double
-no-clone-size-limit
-split-even-if-no-widening
-copt -O3
-copt -fomit-frame-pointer
-copt -freg-struct-return
-copt -malign-double
-copt -march=prescott
-copt -ffast-math
Other tips are given in subsequent messages in that thread.
I personally wouldn't make any bets against Stalin when it comes to
runtime performance, particularly if you can get the author to supply
you with the appropriate compile options and optimization tips. ;)
BTW, the above post gives performance comparisons against g++, OCaml,
and MLton. Adding Bigloo (or any other speed-oriented Scheme) to that
list could be interesting.
Anton
Marcin 'Qrczak' Kowalczyk
>>I'm going to show that decent macros don't need so many parens.
>>It will take some time, since I want hygiene done right too.
>>R5RS is wrong, SRFI-72 is right or mostly right. I haven't
>>designed separate compilation issues yet, and implementation
>>will take some time too.
>
> It is the prefix notation that gives Scheme the capability of a
> powerful macro system.
No. Scheme-style macros require a clear correspondence between the
code and an abstract syntax tree, such that the transformation can
be done context-insensitively, before expanding macros.
It doesn't matter whether the source uses a prefix syntax, whether
there are any infix operators, whether parentheses enclose function
applications, or lists, or comma-separated argument lists, or whether
they merely resolve operator precedence.
> Infix languages typically can't support powerful macro systems
> because they have complicated operator precedence.
Operator precedence doesn't prevent powerful macros. It affects only
the mapping between the concrete syntax and the abstract syntax tree.
Macros are applied after the mapping is done, so for them it doesn't
matter how did the mapping look like, as long as it's easy for a human
macro writer to map in both directions in his head.
Ray Dillinger <be...@sonic.net> writes:
> Instead of indenting to the first space in the previous
> line, you can indent 3 (or 2) spaces per nesting level.
I agree and prefer this indentation style for non-Lispy languages.
I don't know whether Lisp/Scheme will look nice with it though.
For some reason Lisp/Scheme generate many times more different
indentation levels than most other syntaxes. I'm afraid this would
remain true even if the amount of a single indentation was kept
independent of word lengths.
Rob Thorpe
Interesting. Last time I installed Stalin it couldn't even complete
it's own benchmarks. I couldn't figure out whether the problem was
with Stalin or GCC, but it made it useless to me.
I haven't tried Bigloo yet.
James Graves
>What I *believe* can be done, and *hope* to do, with a smart
>optimizing compiler and aggressive inlining of functions that
>do unusual things with their argument expressions, is to make
>99%+ of the cases that are amenable to static analysis - the
>class of first-order functions available via macrology - as
>efficient as accessing them via macros. And the remaining
>cases, as far as I can tell, represent new expressive
>capabilities anyway, so it doesn't really matter for purposes
>of comparison if they are compute-time expensive.
I think I understand what you're saying. But an example would really
help my understanding, if you have time. Perhaps something that is
typically a macro in Lisp, such as DO or WHEN or such.
Thanks,
James Graves
alex...@gmail.com
Rob Thorpe wrote:
> Interesting. Last time I installed Stalin it couldn't even complete
> it's own benchmarks. I couldn't figure out whether the problem was
> with Stalin or GCC,
The problem is with the shell script
alex...@gmail.com
> In the interest of answering the original question:
>
> alex...@gmail.com wrote:
> > Here, I'll help taking this survey easier: Mark all that applies
> >
> > [ ] Big "Loo" ?!
> > [ ] I don't even use Scheme
> > [x] I'm suspicious of Boehm's GC
> I've had actual bugs that were clearly related to Boehm's GC.
>
> > [ ] I'm suspicious of anything written by a single person
> > [x] 30-bit integers and similarly short vectors aren't enough
> > [ ] I want a modern GUI library
> > [x] Other:
> Broken TCO. Slow CALL/CC.
>
Looking through the archives, as I understand, the "Boehm's GC" bugs
were actually related to CALL/CC in Bigloo. TCO has been fixed. Bugs
are bugs, but it seems kind of strange to switch to CL because your
current Lisp of choice does not like CALL/CC.
But anyway, it's fair to say that Bigloo has bugs. But so do many
others. I happened to look at the Lispworks mailing list earlier (And
there are far more users, developers, testers for LW than Bigloo).
Apparently making a hash table that's 256M elements long crashes LW on
OS X (and even causes kernel panic for some).
David Rush
> David Rush wrote:
> > In the interest of answering the original question:
> > alex...@gmail.com wrote:
> > > Here, I'll help taking this survey easier: Mark all that applies
> > >
> > I've had actual bugs that were clearly related to Boehm's GC.
> > Broken TCO. Slow CALL/CC.
> >
> Looking through the archives, as I understand, the "Boehm's GC" bugs
> were actually related to CALL/CC in Bigloo.
Yup. So is *that* fixed?
> TCO has been fixed.
So mutually tail-recursive functions no longer eat the stack? That
would be good news for those of us who like to implement state machines
using TCO idioms. I also use a lot of CPS code :)
> it seems kind of strange to switch to CL because your
> current Lisp of choice does not like CALL/CC.
I didn't switch to CL, I switched to Larceny and Gambit, which at the
time had comparable performance to Bigloo. I used Stalin when I need
that extra oomph. Now that I'm writing a bit of Scheme code again I'm
using Gambit 4. FWIW, support of full TCO is the make-or-break issue
for me - good CALL/CC is almost always an implication of full TCO.
david rush
--
oompha-loompha
David Rush
Anton van Straaten wrote:
> alex...@gmail.com wrote:
> > I just
> > looked in the manual though, and found out that Stalin does not provide
> > GCC with any compile-time options, and decided to try -copt -O3, and
> > woah 6x improvement! Hmm...
>
> See Siskind's posts in this thread (about a raytracer benchmark):
>
> http://groups.google.com/group/comp.lang.scheme/browse_frm/thread/349c51b1d30d2b3e/e47fa8ae534cc8f4
>
> The options used for the Stalin compiles are given as:
> I personally wouldn't make any bets against Stalin when it comes to
> runtime performance, particularly if you can get the author to supply
> you with the appropriate compile options and optimization tips. ;)
To be fair to Siskind and Stalin, I had much the same experience
optimizing for both Gambit and Bigloo. Various prominent developers of
the compilers ultimately helped me select the right set of
optimizations to get maximal speedups. I think this tells us something
about Scheme as a language, but I'm not entirely sure what.
david rush
--
Remember: There is no Scheme Underground
alex...@gmail.com
> So mutually tail-recursive functions no longer eat the stack?
With -O6 or -Obench, this runs forever:
(module foo)
(define (f x) (g (+ x 1)))
(define (g x) (f (- x 1)))
(write (f 0))
Same in the interpeter (runs for a while at least, without eating
memory) Compiled without -O* , this will crash (Probably unintended
behavior)
> I didn't switch to CL, I switched to Larceny and Gambit, which at the
> time had comparable performance to Bigloo. I used Stalin when I need
> that extra oomph. Now that I'm writing a bit of Scheme code again I'm
> using Gambit 4. FWIW, support of full TCO is the make-or-break issue
> for me - good CALL/CC is almost always an implication of full TCO.
I don't use CALL/CC at all, so I never paid attention to this issue.
Bigloo is probably not the best choice if you are into CALL/CC. Gambit
4 seems to be much slower than Bigloo (order of magnitude) on "normal"
(the kind I write) code though, making it unattractive to me.
Ray Dillinger
> I think I understand what you're saying. But an example would really
> help my understanding, if you have time. Perhaps something that is
> typically a macro in Lisp, such as DO or WHEN or such.
Okay... I'm extending lambda with various kinds of formal-argument
forms. One of these is (&promise argname) which means that the
function being defined takes this particular argument as a "promise"
(slightly specialized meaning; these promises contain a form and
environment, as expected, but do not inhibit multiple evaluation the
way scheme promises do) rather than a value. Most arguments are
evaluated when the function call is made, but that's under the
control of the called function; the &promise form in the formal
argument list simply denotes an exception.
So here's binary "and", implemented as a function (not a macro) in
terms of if.
(define and
(lambda (arg1 (&promise arg2)) ;;(&promise arg2) takes arg2 without evaluating it
(if arg1
(eval arg2) ;; if arg1 is true, returns the result of evaluating arg2.
arg1))) ;; a false value.
Note: eval, when applied to a promise, doesn't need an environment
argument, because a promise contains both a form and an environment.
Basic operations on my promises include
eval, which evaluates it and returns the result, (shown above)
get-env, which returns the environment where the promise was defined, and
get-form, which returns the form that would be evaluated in that
environment by a call to eval. (shown below)
Note that these 'promises' are not exactly what scheme means by a promise;
if you wanted to use them to inhibit multiple evaluation, you'd have to
do it explicitly by using set! or similar to replace the promise with the
result of evaluating it.
Here's a two-case "generalized set" for those who like generalized set...
(define gset! (lambda ((&promise loc) val)
(let ((locform (get-form loc))
((locenv (get-env loc)))
(cond ((atom? locform)
(eval (list 'set! (cdr locform) val) locenv))
((eqv? 'vector-ref (car locform))
(eval (list 'vector-set! (cdr locform) val) locenv))
;; insert more cases here
))))
Bear
Isaac Gouy
http://shootout.alioth.debian.org/sandbox/
Where are the Scheme programs?
iirc the Computer Language Shootout was revived partly with the aim of
showing off Scheme and Lisp and ironically we still don't do a good job
of showing off Scheme or Lisp.
(The folk who have most readily accepted the free advertising
opportunity are the Mlton and D guys - they quietly provide programs
for whatever silly benchmark we dream up, they make sure there's a
working program for every benchmark.)
And of course it helps if the language tools are packaged - Brent likes
to use a stable Debian package, and I like to use a stable Gentoo
ebuild (since starting GP4 I 've come to appreciate Brent's viewpoint)
- here are the Scheme package versions for Gentoo
http://packages.gentoo.org/packages/?category=dev-scheme
If you want to see Bigloo programs on the Computer Language Shootout
then send us Bigloo programs...
If you want to see Stalin programs on the Computer Language Shootout
then send us Stalin programs...
etc
With enough working programs the Scheme implementations will be shown
on the "The Computer Language Shootout Benchmarks" rather than "The
Sandbox"
The FAQ provides boringly detailed instructions on how to contribute a
program:
"How can I contribute a program or a fixed-program?"
http://shootout.alioth.debian.org/faq.php#contribute
Bruce Hoult
"Isaac Gouy" <ig...@yahoo.com> wrote:
> iirc the Computer Language Shootout was revived partly with the aim of
> showing off Scheme and Lisp and ironically we still don't do a good job
> of showing off Scheme or Lisp.
>
> (The folk who have most readily accepted the free advertising
> opportunity are the Mlton and D guys - they quietly provide programs
> for whatever silly benchmark we dream up, they make sure there's a
> working program for every benchmark.)
>
>
> And of course it helps if the language tools are packaged - Brent likes
> to use a stable Debian package, and I like to use a stable Gentoo
> ebuild (since starting GP4 I 've come to appreciate Brent's viewpoint)
> - here are the Scheme package versions for Gentoo
> http://packages.gentoo.org/packages/?category=dev-scheme
>
> If you want to see Bigloo programs on the Computer Language Shootout
> then send us Bigloo programs...
> If you want to see Stalin programs on the Computer Language Shootout
> then send us Stalin programs...
> etc
Personally I'm more interested in getting Dylan a few more places up.
Which I spent a bit of time on a few months ago, getting Gwydion above
g++, CMUCL and SBCL, but obviously some other people have done a bit of
work in the meantime becuase Gwydion has slipped now.
Isaac Gouy
Brent was delighted that at last there were enough working Dylan
programs!
As for working Bigloo programs, and Stalin, and ...
Bruce Hoult
"Isaac Gouy" <ig...@yahoo.com> wrote:
Unfortunately Toy programs like these aren't where our languages really
shine. They come into their own on larger projects. The ICFP
Programming Contest, for example, is a much more realistic size, though
still on the small side with 72 hours of effort in which we usually
write something on the order of 3000 lines of code. But I don't know
of any larger or more realistic venue for comparing large numbers of
languages on the same task. So the Shootout and ICFP is what we have to
work with.
Alas, Scheme and CL are largely MIA there as well :-(
Isaac Gouy
Agreed.
We find that people are willing to spend a little time and contribute
20 line programs but few are willing to spend enough time to complete
even a 100 line program.
And people can look at a 20 line program and perhaps have some
confidence they know what it's doing, while a 100 line program takes a
little too much time to understand.
So my rule of thumb for the tasks has been < ~100 lines in a Java/C#
like language (old procedural languages will be longer, scripting
languages and functional languages shorter).
> Alas, Scheme and CL are largely MIA there as well :-(
The good thing about Toy programs is that one or two people can easily
implement them over a couple of weeks. Recently that happened with Tcl
- someone decided to write the missing programs, and did a fair job of
it.
Förster vom Silberwald
alex...@gmail.com wrote:
> On the Bigloo mailing list, we jump with joy every time a new version
> of Bigloo comes out. However, it's clear that the number of people
> using Bigloo is quite small, even by Scheme standards. Going straight
> to the source, I wanted to ask: why aren't YOU using it?
>
> Here, I'll help taking this survey easier: Mark all that applies
>
> [ ] I don't even use Scheme
> [ ] I'm suspicious of anything written by a single person
> [ ] I want a modern GUI library
Some more words: Bigloo needs some more man-power insofar as to
providing more ready-to-use numerical libraries and stuff like that.
During my PhD term in my spare time at weekends I happpend to produce a
binding (downloadable from Bigloo homepage) to the sophisticated
plotting library DISLIN. It took me some time since I do not know much
about C. It took me longer than anticipated because I wanted to make it
as comfortable as the one binding under Python/DISLIN. One can now use
the Python DISLIN manual when using my binding under Bigloo (okay, you
must imagine the ((())) around Python functions; but the latter is easy
and straightforward).
I am not sure whether Will is still working on a binding to the gsl
(gnu scientific library).
As I said: man years are welcome. That is the way in Python: a lot of
projects start out as one-man project. Don't hesitate to contribute to
Bigloo too. And as you already know: genuine gentleman are using Scheme
and not Python.
That said:
Sir Francis Drake
bunn...@gmail.com
>
> > So mutually tail-recursive functions no longer eat the stack?
>
> With -O6 or -Obench, this runs forever:
>
> (module foo)
> (define (f x) (g (+ x 1)))
> (define (g x) (f (- x 1)))
> (write (f 0))
>
> Same in the interpeter (runs for a while at least, without eating
> memory) Compiled without -O* , this will crash (Probably unintended
> behavior)
>
That example is unfortunately not representative. What you want is
support for general tail calls, even across module boundaries.
cheers,
felix
alex...@gmail.com
Why should mutual recursion across modules/compilation units be
important? (I assume you are talking about them) Some statically typed
languages don't even allow this sort of thing, BTW.
bunn...@gmail.com
alex...@gmail.com wrote:
>
> Why should mutual recursion across modules/compilation units be
> important?
Global tail call optimization/elimination is the bread and butter of
Scheme
(this includes recursion, mutual recursion and general tail-position
calls, and additionally
touches areas like unnecessary garbage retention and the property of
being
"safe-for-space-complexity").
It is required by the language standard.
cheers,
felix
Shiro Kawai
alex...@gmail.com wrote:
> Why should mutual recursion across modules/compilation units be
> important? (I assume you are talking about them) Some statically typed
> languages don't even allow this sort of thing, BTW.
Does Bigloo run the following example in constant space?
In compilation unit 1, assuming exporting traverse:
(define (traverse obj proc seed)
(if (pair? obj)
(proc (car obj) seed
(lambda (seed2) (traverse (cdr obj) proc seed2)))
seed))
In compilation unit 2, assuming importing the unit 1.
(define (start)
(let ((infinite (list 'a)))
(set-cdr! infinite infinite)
(traverse infinite (lambda (elt seed cont) (cont seed)) 0)))
This is too simple to be useful, but I sometimes use the
traverse-like pattern; it becomes more useful when the
callback procedure gets more than one continuation procedures.
(I briefly tried by myself but couldn't find an introductory
document for separate compilation in Bigloo. I'll appreciate
if you can point one.)
alex...@gmail.com
>
> Does Bigloo run the following example in constant space?
>
Bigloo will exhaust the stack and segfault (Manuel promised to think
about replacing segfault on stack exhaustion with an exception throw).
Interestingly, I believe in OCaml your example will run in constant
space (I don't know if OCaml is properly tail recursive), so maybe the
goals of speed and inter-module tail recursion are not contradictory,
unlike what the opponents of Grand Unified Scheme say (you know who you
are).
I don't know if there is an introductory module tutorial for Bigloo,
but here's the complete set of files and commands to try your example:
$ ls -A
.afile prog.scm trav.scm
$ more *.scm .afile
::::::::::::::
prog.scm
::::::::::::::
(module prog
(import trav))
(define (start)
(let ((infinite (list 'a)))
(set-cdr! infinite infinite)
(traverse infinite (lambda (elt seed cont) (cont seed)) 0)))
(write (start)) ;; just in case it gets optimized without I/O
::::::::::::::
trav.scm
::::::::::::::
(module trav
(export traverse))
(define (traverse obj proc seed)
(if (pair? obj)
(proc (car obj) seed
(lambda (seed2) (traverse (cdr obj) proc seed2)))
seed))
::::::::::::::
.afile
::::::::::::::
((trav "trav.scm")
(prog "prog.scm"))
$ bigloo -O6 -c trav.scm
$ bigloo -O6 -c prog.scm
$ bigloo -O6 -o prog trav.o prog.o
$ ./prog
Ouch...
Shiro Kawai
> I don't know if there is an introductory module tutorial for Bigloo,
> but here's the complete set of files and commands to try your example:
Ah, thanks. ".afile" does the trick I was looking for.
SeaFu...@gmail.com
alex...@gmail.com wrote:
> On the Bigloo mailing list, we jump with joy every time a new version
> of Bigloo comes out. However, it's clear that the number of people
> using Bigloo is quite small, even by Scheme standards. Going straight
> to the source, I wanted to ask: why aren't YOU using it?
I think the short answer is "it wasn't ready to be used out of the box
on Windows." Don't take that as Visual Studio Slackerism: I invested
enormous amounts of time into the Bigloo learning curve, RTFM, doing my
own builds, submitting bug reports, trying to get a viable IDE
together, etc. I could measure that time investment in months, and in
hindsight, I'm surprised I spent that much time on it. The problem is
hardly unique to Bigloo. Generally, if you're not a UNIXen and don't
like Emacs / Vim, open source tools have tons of rough edges that
consume gobs of labor. So after putting a lot of time into something,
one often decides to move on.
After Bigloo, I went through a "gee maybe Common Lisp would give me
more unity / support / sanity" stage. But it turned out it didn't.
With all the different C FFIs, there was nothing "common" about Common
Lisp from my Windows game developer standpoint. It was identical to
the Scheme universe: you pick an implementation and you live or die by
its quirks.
So after that, I moved on to Chicken Scheme. Initial attractions were
(1) like Bigloo, it's performance oriented, (2) it has a larger user
community than Bigloo, (3) it has some C++ capabilities, (4) it has a
BSD license, which for my purposes is better than Bigloo's GPL license.
I have delusions of grandeur that I might write my own compiler
someday.
So imagine my chagrin when I simply couldn't get Chicken Scheme to
build with MinGW. Pain and agony. But apparently Felix doesn't like
the Autoconf build system anyways, and so I instigated a move to CMake.
www.cmake.org In the course of getting that to work, I built
relationships with Felix and also the CMake authors. These people are
definitely "keepers" as business partners, so I will continue to plod
along in the Chicken Scheme direction for the forseeable future. And,
yes, Chicken Scheme builds reliably on MinGW with CMake now, although
the official tarballs don't have that support highlighted. I need to
create generic CMake installation instructions, but there's a lot on my
New Year's TODO list as of yet.
I could see myself using Bigloo again. Manuel Serrano is very
responsive to bug reports, he's very professional. However, a major
dealbreaker is that the VC++ build still hasn't made it into source
control. It's not acceptable to have the stuff I need solely dependent
upon Yannis' prognostications. He does good work, but his work should
be part of a main source repository. In contrast, Chicken Scheme has a
public Darcs repository. Without public source control, there are
limits to how much other people can contribute to a project.
If the Bigloo crowd wants to convert to CMake, I and other people are
willing to help them do so. Recently we started a mailing list to make
people more aware of CMake, called CMake-Promote.
http://cmake.org/HTML/MailingLists.html
Cheers,
Brandon Van Every
Taking risk where others will not.
David Rush
> so maybe the
> goals of speed and inter-module tail recursion are not contradictory,
> unlike what the opponents of Grand Unified Scheme say (you know who you
> are).
I don't know who they are. There are people who think speed and
inter-module TCO are problematic? Trampolines aren't the only answer to
that problem, even if they are the easiest answer to implement
(especially if C is your assembly language).
As I've not been following the R6RS SRFIs and other discussions, this
comment makes me *exceptionally* nervous about the viability of the
proposed Scheme module system. Mind you, I've never seen a need for one
(modulo macrology) anyway.
drr
Rob Thorpe
> As I've not been following the R6RS SRFIs and other discussions, this
> comment makes me *exceptionally* nervous about the viability of the
> proposed Scheme module system. Mind you, I've never seen a need for one
> (modulo macrology) anyway.
I think there's a great need for one. At present, if you write a none
trivial length of scheme code then there is no way to change scheme
implementation without changing the code or putting it all in one huge
file.
David Rush
Piffle.
$ cat implementation-prolog.scm > compiler-ready.scm
$ cat *.module >> compiler-ready.scm
$ cat main.scm >> compiler-ready.scm
$ your-favorite-scheme-compiler --your-favorite-options
compiler-ready.scm
I mean, what are autoconf and make for, anyway?
More subtle methods are easy to build as well.
david rush
--
Checklists are no substitute for understanding
Rob Thorpe
> Rob Thorpe wrote:
> > David Rush wrote:
> > > As I've not been following the R6RS SRFIs and other discussions, this
> > > comment makes me *exceptionally* nervous about the viability of the
> > > proposed Scheme module system. Mind you, I've never seen a need for one
> > > (modulo macrology) anyway.
> >
> > I think there's a great need for one. At present, if you write a none
> > trivial length of scheme code then there is no way to change scheme
> > implementation without changing the code or putting it all in one huge
> > file.
>
> Piffle.
>
> $ cat implementation-prolog.scm > compiler-ready.scm
> $ cat *.module >> compiler-ready.scm
> $ cat main.scm >> compiler-ready.scm
> $ your-favorite-scheme-compiler --your-favorite-options
> compiler-ready.scm
It can be done that way, but it can be very time consuming recompiling
all the code every time.
> I mean, what are autoconf and make for, anyway?
Make is an OK way to do it, but often you can't use make as it should
be used because some scheme compilers do not have object code output.
So make can only be used to automate the concatenation you mention
above, which isn't really much use.
David Rush
> David Rush wrote:
> > > I think there's a great need for <a standard module system>. At present,
> > > if you write a none
> > > trivial length of scheme code then there is no way to change scheme
> > > implementation without changing the code or putting it all in one huge
> > > file.
> >
> > Piffle.
> >
> > I mean, what are autoconf and make for, anyway?
>
> Make is an OK way to do it, but often you can't use make as it should
> be used because some scheme compilers do not have object code output.
> So make can only be used to automate the concatenation you mention
> above, which isn't really much use.
It was a chop at the unsupportable 'great need' assertion. I wrote a
module system and a separate preprocessor for Scheme code. Once I got
to a deep level of the utility of HO functions and functors in the
lexically-scoped, latently-typed world of Scheme I realized it was all
a waste of effort. As in so many other things, Scheme already has the
core solutions embodied inherently in the language. The 'great need'
for a module system that is so frequently asserted is *primarily* a
desire for conformity to current fashions IMNSHO, and reflects a lack
of understanding of both the modularization problem and the reuse
problem.
CAVEAT LECTOR: I *am* ignoring the issues arising from macros, and
there are some real issues around figuring out just *when* macro
expansion ought to be performed (cf the _You Want It When?_ paper). My
experience, which goes up to the order of 10KLOC (not counting
libraries) Scheme programs, is firstly that macros often become
unecessary when the problem is correctly factored and secondly that a
simple dependency sort is generally sufficient to ensure correctness.
david rush
--
Module Maniac
Martin Rodgers
> CAVEAT LECTOR: I *am* ignoring the issues arising from macros, and
> there are some real issues around figuring out just *when* macro
> expansion ought to be performed (cf the _You Want It When?_ paper). My
> experience, which goes up to the order of 10KLOC (not counting
> libraries) Scheme programs, is firstly that macros often become
> unecessary when the problem is correctly factored and secondly that a
> simple dependency sort is generally sufficient to ensure correctness.
I've been very reluctant to add modules to any of my compilers, but I
recently
found a need for namespace control: hiding language options that may or may
not be available to the program being compiled. With modules, I can
solve the
question "Exactly which language should my compiler understand?" by allowing
the user to create the language from a library of modules.
Of course this could be done by the user simply by adding the "module" code
to their program file(s), but some of that code will be
implementation-specific.
It can also add considerably to the size of the user code, and the
effort required
to maintain it. There might also be portability and performance issues.
So I reluctantly decided to add modules and restructure the runtime
system so
that it uses it. Now I can happily use various SRFIs in the runtime
without also
providing them to the user program. No conflict arises between the language
required by the compiler library and the language required by the user
program.
For example, I can use error from SRFI-23 to report runtime errors without
also making it available to the user program, which might use a very
different
definition of error.
--
http://www.wildcard.demon.co.uk
Anton van Straaten
> It was a chop at the unsupportable 'great need' assertion.
"Unsupportable", eh? Why, sometimes I've supported as many as six
unsupportable things before breakfast.
> I wrote a
> module system and a separate preprocessor for Scheme code. Once I got
> to a deep level of the utility of HO functions and functors in the
> lexically-scoped, latently-typed world of Scheme I realized it was all
> a waste of effort. As in so many other things, Scheme already has the
> core solutions embodied inherently in the language. The 'great need'
> for a module system that is so frequently asserted is *primarily* a
> desire for conformity to current fashions IMNSHO, and reflects a lack
> of understanding of both the modularization problem and the reuse
> problem.
That may be true for systems developed by a single person, or by a team
which agrees on an internal standard for code modularization and reuse.
But the need for such an internal standard effectively refutes your
point. Such a standard is essentially a module system of some kind,
however ad-hoc or "manual" it is. The fact that a team of Scheme
developers has to agree on some such system in order to be able to
easily reuse each other's code demonstrates the "great need" for a
module system.
All that's left to decide is whether there's a great need to extend
agreement about the modularization approach to a larger community, for
the same sorts of reasons: the ability to easily reuse other people's
code, and to easily integrate multiple independent libraries of code.
So the question is not whether there's a great need for a module system,
it's whether there's a great need for a widely standardized module system.
The answer to that does somewhat depend on one's requirements. If
you're largely working alone, you may not think you have much use for a
more broadly standardized module system -- although chances are fairly
high that you'd be wrong in thinking that, since a standardized module
system is likely to bring benefits that you haven't considered.
However, if we look beyond people who took Olin's Acknowledgements too
much to heart ("I did it all myself"), there are many people that do
have a great need to rely on code written by other people. There are
also people who have a great need for a system which makes it simple to
publish libraries of code. A standardized module system would satisfy
these needs. (Also, any solution which satisfies these needs has to
include module system functionality.)
> CAVEAT LECTOR: I *am* ignoring the issues arising from macros, and
> there are some real issues around figuring out just *when* macro
> expansion ought to be performed (cf the _You Want It When?_ paper). My
> experience, which goes up to the order of 10KLOC (not counting
> libraries) Scheme programs, is firstly that macros often become
> unecessary when the problem is correctly factored and secondly that a
> simple dependency sort is generally sufficient to ensure correctness.
Macros are the main reason that the module system remains an issue in
Scheme. Ignoring them makes the issue a relatively trivial one, but the
resulting solutions don't address the real needs.
Many useful Scheme libraries rely on macros for usability reasons. In
those cases, the use of macros has nothing to do with factoring, i.e.
factoring out the macros would be detrimental. Some specific examples
include Schelog, Kanren, and SchemeQL. More generally, the same goes
for object systems, pattern matchers, parser generators, etc.
As for the dependency sort, I'm guessing that is meant in the context of
a block compiling approach. However, block compiling is just not a
viable solution in many situations.
In summary, if you follow some reasonably consistent convention for
modularizing your code, take steps to minimize macro dependency issues,
expend the necessary effort to integrate external code, and use
non-standard tools, language extensions, and/or plain manual effort to
manage compilation dependency issues, then you can certainly survive
without a module system. It doesn't follow from this that there is no
great need for a module system, though.
Now if you'll excuse me, I'm long overdue for my breakfast.
Anton