The crux of people's issues with PLT Scheme?
excord80
free time I can find (and deciding on an implementation to use (at
least, for a while)). So far, it seems to me as if there are 2 major
camps in the Scheme community: those that like classic spare standard
Scheme (R5RS), and those who prefer PLT with its practical additions
(R6RS). I'd appreciate correction on this if I'm mistaken.
Anyway, my question is this: are the issues that some people have with
R6RS about serious flaws that they see with R6RS -- which will cause
pain down the road -- or are the issues mostly about not ruining the
simple and elegant quality of Scheme (say, mostly cosmetic)?
Because, if it's the latter, then I'll probably use PLT and put up
with just a little ugliness to get the useful additions and large
community support. But if it's the former, I'll stick with an R5R6
until the madness ends. :)
Thank you.
Aaron W. Hsu
>Hi. I'm brand new to Scheme, trying to learn my way around in what
>free time I can find (and deciding on an implementation to use (at
>least, for a while)). So far, it seems to me as if there are 2 major
>camps in the Scheme community: those that like classic spare standard
>Scheme (R5RS), and those who prefer PLT with its practical additions
>(R6RS). I'd appreciate correction on this if I'm mistaken.
PLT is its own beast. It happens to have an R6RS capability in it, but
the main language is not R6RS. And I don't think you can divide up the
community in this manner. There are a lot of people who like R6RS but
who still have rather lean and efficient systems, and there are people
who like R5RS who have fairly sophisticated and complex sets of
libraries that they use. Also, it's kind of a trick to say "practical
additions" because that's saying too much and too little at the same
time.
>Anyway, my question is this: are the issues that some people have with
>R6RS about serious flaws that they see with R6RS -- which will cause
>pain down the road -- or are the issues mostly about not ruining the
>simple and elegant quality of Scheme (say, mostly cosmetic)?
The issues span both of these spectrums. R6RS was a deviation from what
many people deemed the spirit of Scheme (though this is debated) and
others took issue with it on technical merits. Both people have cases.
There are serious practical flaws in the system, and it leads to real
programming issues. Likewise, there are real philosophical questions
about R6RS and whether it was the right way to go or not. You can come
down on whatever side of the camp you want once you have played with
them more. When you are just learning, you should not have to worry
about this too much.
>Because, if it's the latter, then I'll probably use PLT and put up
>with just a little ugliness to get the useful additions and large
>community support. But if it's the former, I'll stick with an R5R6
>until the madness ends. :)
The madness probably will not end, so do not hold your breath. There
are a variety of other Schemes with large libraries and systems that
have good community support are different than PLT. Chicken is one
example. Also, at this stage in your work, you can use the basic
features of Scheme and call upon the wisdom of the greater Scheme
community, especially as you learn the basics. You probably do not need
to jump into the more sophisticated nuances of the Scheme
implementations until much later.
--
Aaron W. Hsu <arc...@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
Grant Rettke
What are some of your goals for the first 3 months with Scheme?
If your focus is on learning, you can stay close to R5RS and use any
Scheme distribution without cause for hesitation.
If you are more concerned about "getting things done", and doing so
with a lot of libraries, though, then you should just pick one
distribution and stick with it.
PLT would serve you well for either.
excord80
>
> community support. But if it's the former, I'll stick with an R5R6
> until the madness ends. :)
Typo: s/R5R6/R5RS/
excord80
>
> There
> are a variety of other Schemes with large libraries and systems that
> have good community support are different than PLT. Chicken is one
> example.
Thank you for the tip. Will check out Chicken.
> Also, at this stage in your work, you can use the basic
> features of Scheme and call upon the wisdom of the greater Scheme
> community, especially as you learn the basics.
:)
excord80
> Hi Excord,
>
> What are some of your goals for the first 3 months with Scheme?
SICP, for now. I won't hazard a guess as to how much I can get through
in 3 months though. :)
Thanks for the tips.
Aaron W. Hsu
>On Jan 17, 12:16=A0am, Grant Rettke <gret...@gmail.com> wrote:
>> Hi Excord,
>>
>> What are some of your goals for the first 3 months with Scheme?
>SICP, for now. I won't hazard a guess as to how much I can get through
>in 3 months though. :)
If that is what you want, you may find MIT Scheme to be a good choice.
It also has a large set of libraries, was the implementation used for
SICP (more or less), but it doesn't have as active a community, nor is
the documentation as complete. Although, if you're just trying to get
through SICP, CLS is a great place for that.
William D Clinger
> Anyway, my question is this: are the issues that some people have with
In my case, yes.
> -- which will cause pain down the road --
or have already caused pain.
One of the R6RS's more fundamental flaws is that it
absolutely forbids implementation via pure interpreters
or via interactive read/eval/print loops. Consequently,
programmers who want to use a traditional REPL or a pure
interpreter have no choice but to ignore the R6RS. The
only alternatives available to them are to stick with
the R5RS/IEEE/ANSI standards, go with ERR5RS, or use yet
another nonstandard semantics for their REPL or interpreter
(which is the choice made in three or four of the six
available partial or complete implementations of the R6RS).
Since there are many people who like to use a traditional
REPL or a pure interpreter, there was never any real
opportunity for the R6RS to displace the R5RS and IEEE/ANSI
standards completely. At best, the R6RS offered a new
mode of execution that could supplement those standards.
At worst, the R6RS divided the community still further
and created yet another impediment to portability of
Scheme programs.
> or are the issues mostly about not ruining the
> simple and elegant quality of Scheme (say, mostly cosmetic)?
You err by thinking simplicity and elegance are mostly
cosmetic. Simplicity and elegance are overwhelmingly
practical virtues. Many of the R6RS's practical problems
resulted from its abandonment of simplicity and elegance.
Will
Marek Kubica
Aaron W. Hsu <arc...@sacrideo.us> wrote:
> PLT is its own beast. It happens to have an R6RS capability in it,
> but the main language is not R6RS. And I don't think you can divide
> up the community in this manner. There are a lot of people who like
> R6RS but who still have rather lean and efficient systems, and there
> are people who like R5RS who have fairly sophisticated and complex
> sets of libraries that they use. Also, it's kind of a trick to say
> "practical additions" because that's saying too much and too little
> at the same time.
To sum it up, we are talking of three different versions of Scheme. The
older R5RS Scheme which is supported by a number of implementations,
the newer R6RS Scheme which hasn't yet as many implementations
(currently MzScheme (from PLT), Ikarus and Larceny as well as Ypsilon
and probably Guile). The third one is the Module language which is a
PLT-specific version of Scheme.
regards,
Marek
excord80
R5RS (plus useful libs) for me. The idea being, post-SICP I'll likely
be trying to write webapps and GUI apps with it too.
I wouldn't want to give up the repl, nor do I think a language
standard should be telling you how to implement a language. Also,
after reading a bit about the R5/R6 diffs, I don't think I need
unicode for anything, and I'm guessing that I can get things like
exceptions and a module system as libs with the R5RS that I end up
using.
I'll keep my eye on the ERR5RS effort. Sounds like that will end up
receiving far broader community support than R6RS, but that's just my
guess from a new user's perspective. Is the ERR5RS spec complete yet?
(Love the ERR5RS acronym (leetronym?) BTW. :) ) When it is complete,
if the implementation I'm using doesn't follow it, I'll probably go
shopping around again for impl's at that point.
And also, I must say that there is something very attractive about a
mere 50-page language spec.
Grant Rettke
> One of the R6RS's more fundamental flaws is that it
Is this a problem that Common Lisp solved? How did they address it?
> At worst, the R6RS divided the community still further
> and created yet another impediment to portability of
> Scheme programs.
On one hand, it seems like one thing that R6RS did do was to shed
light on the lack of interest implementers had in portability.
On the other, it makes it seem like there was never a portability
problem that needed to be solved.
Which one was it?
William D Clinger
> > One of the R6RS's more fundamental flaws is that it
> > absolutely forbids implementation [...] via interactive
> > read/eval/print loops.
>
> Is this a problem that Common Lisp solved? How did they address it?
Common Lisp solved the problem the same way the
original and revised reports on Scheme did, which
is the same way the RRRS/R3RS/R4RS/R5RS/IEEE/ANSI
standards did: by not creating the problem in the
first place.
Both uses of the word "must" in the last sentence
of R6RS 5.5 are gratuitous in the sense that there
is scant technical justification for them, but both
uses were entirely deliberate. As can be seen from
chapter 8 of their rationale, the editors really
did want to rule out pure interpreters and REPLs.
The editors appear to have believed that having a
few ambiguities in a REPL-compatible semantics is
worse than not having any REPL-compatible semantics
at all.
> On one hand, it seems like one thing that R6RS did do was to shed
> light on the lack of interest implementers had in portability.
>
> On the other, it makes it seem like there was never a portability
> problem that needed to be solved.
>
> Which one was it?
That's a weird false dichotomy.
It can be argued that the R6RS shed light on the R6RS
editors' lack of interest in portability, but it can
also be argued that the portability problems created
by the R6RS arose from carelessness, poor design, or
a belief that users and implementors would support
any standard, no matter how bad, so long as it could
be ratified by at least 60% of the voters. As it is,
two of the three systems represented by the editors
themselves still do not support the R6RS, and the
only one that does (PLT Scheme) appears to regard
both the R6RS and R5RS as "legacy" standards while
encouraging programmers to write nonstandard and
PLT-specific code.
Will
Marek Kubica
excord80 <exco...@gmail.com> wrote:
> Thank you Marek and William for the great summaries. Looks like it's
> R5RS (plus useful libs) for me. The idea being, post-SICP I'll likely
> be trying to write webapps and GUI apps with it too.
Then you won't get with pure R5RS very far. Andreas Rottman is working
on R6RS-portable gobject-intropection bindings (that is basically
anything that uses gobject, like GTK+ and everything around GNOME) which
should work on R6RS Schemes with decent Foreign Function Interface, so
things may improve.
> I'll keep my eye on the ERR5RS effort. Sounds like that will end up
> receiving far broader community support than R6RS, but that's just my
> guess from a new user's perspective.
Don't know. I know only one implementation that says it supports ERR5RS
but more which support R6RS. And even more which are at R5RS or
lower :) So R5RS is the common denominator which you can rely on and
everything beyond that...
> And also, I must say that there is something very attractive about a
> mere 50-page language spec.
I thought that too, but finding out that everything that goes beyond
this must be either implemented by oneself or taken from a SRFI or from
extensions is not that much fun anymore. But this is a topic that has
been discussed to quite some extent and doesn't need to be discussed
here. Opinions very.
regards,
Marek
excord80
> On Sat, 17 Jan 2009 21:49:25 -0800 (PST)
>
> > Thank you Marek and William for the great summaries. Looks like it's
> > R5RS (plus useful libs) for me. The idea being, post-SICP I'll likely
> > be trying to write webapps and GUI apps with it too.
>
> Then you won't get with pure R5RS very far.
Sorry for the clumsy wording. I meant that I would use the extra libs
(not just pure R5RS) for the webapps and GUI apps.
> Andreas Rottman is working
> on R6RS-portable gobject-intropection bindings (that is basically
> anything that uses gobject, like GTK+ and everything around GNOME) which
> should work on R6RS Schemes with decent Foreign Function Interface, so
> things may improve.
Well, I see that although Chicken (on their "Eggs Unlimited" page)
does not seem to have bindings to GTK+, it does have them for Qt
(which will be fine thanks to their upcoming licensing change).
> > I'll keep my eye on the ERR5RS effort. Sounds like that will end up
> > receiving far broader community support than R6RS, but that's just my
> > guess from a new user's perspective.
>
> Don't know. I know only one implementation that says it supports ERR5RS
Which one?
Grant Rettke
> it can also be argued that the portability problems created
> by the R6RS arose from carelessness, poor design, or
> a belief that users and implementors would support
> any standard, no matter how bad, so long as it could
> be ratified by at least 60% of the voters.
Do you think that the community will self-correct for R7RS?
William D Clinger
> Do you think that the community will self-correct for R7RS?
It will have that opportunity, and I hope it will
take advantage of it.
I think there's a good chance of self-correction,
because few people are really happy with the current
situation. On the other hand, it's much harder to
correct a ratified standard than to fix the problems
before ratification, partly because the spirit of
technical cooperation that prevails while proposals
are being drafted is more conducive to progress than
the adversarial spirit that prevails during and
persists after an extremely controversial election.
Will
Marek Kubica
excord80 <exco...@gmail.com> wrote:
> > > I'll keep my eye on the ERR5RS effort. Sounds like that will end
> > > up receiving far broader community support than R6RS, but that's
> > > just my guess from a new user's perspective.
> >
> > Don't know. I know only one implementation that says it supports
> > ERR5RS
>
> Which one?
Larceny by William D Clinger, you might want to look into it, as it has
support for R5RS and R6RS too, so you are free to choose what standard
you like to use. I haven't used it yet, though.
regards,
Marek
klohm...@yahoo.de
> Because, if it's the latter, then I'll probably use PLT and put up
> with just a little ugliness to get the useful additions and large
> community support. But if it's the former, I'll stick with an R5R6
> until the madness ends. :)
>
> Thank you.
Speed is an issue and nothing beats Bigloo so far. Moreover Bigloo has
a much better documentation than PLT (okay last checked it couple of
years ago) with respect to "what actually is R5R5 and what add ons are
in there". I am not saying that I ever have cared about if my code is
R5RS compliant or not but still when reading the document it gives you
some clue what's been included into Bigloo by some form of
extensions.
Not only has Bigloo a lot of additional features it has a way to
document code by means of giving types. Why one wouldn't want to use
such a feature is beyond my understanding of things:
==
(define (this-sucks a b c)
(+ a b))
==
==
(define (this-also-sucks a-vector b-vector c-class-array)
(add-vec a-vector b-vector))
==
==
(define (this-Bigloo-way-is-okay a::vector b::vector c::class-array
(add-vec a b))
==
The above Bigloo code will also spot compile time errors in case you
pass a wrong data type (e.g. class) to the function. It not only helps
to document your code it also improves your debugging cycle.
Don't get me wrong: my level of Scheme knowledge is very basic but it
is beyond me why people are opting to chose PLT. Okay Bigloo has more
resemblance to a compiler but anyway.
Marek Kubica
klohm...@yahoo.de wrote:
> Don't get me wrong: my level of Scheme knowledge is very basic but it
> is beyond me why people are opting to chose PLT.
Not everyone values speed above functionality and PLT brings a lot of
the latter:
* Command line parsing
* Units
* Scrible
* R6RS support
* Quite extensive documentation
* Friendly mailing list
* A nice editor, well integrated
* An easy to use toolkit
* useful, graphical macro expander
* debugger
* web-server
* package repository (PLaneT)
* graph plotting
* access to OpenGL
* SSL support
* Lazy Scheme
* COM integration on Windows
There's a lot more, this is just the things that come to my mind at
first. I haven't used everything there and I'm sure Bigloo also has
some of these features but this might give you an impression why people
choose PLT.
regards,
Marek
klohm...@yahoo.de
I acknowledge there is probably a lot more in store for PLT library
wise. However, at the same time I fail to understand what might be so
exciting in investing time, energy, and manpower in a dog slow PLT
implementation. Speed is simply an issue. comp.lang.python e.g. is
full of threads which discuss 'speed'. Instead that we learn from
them and start using Bigloo (because a fast, mature Scheme is already
out there) people are tricked into all the slow Scheme implementations
instead.
There are a lot of Python projects aimed to speed up Python. And in
the end Scheme will have lost the game.
I can understand that the PLT developers are not keen to contribute to
a french academic project (and vice versa) even though bigloo is open
source. Academics gave us Scheme but at the same time are the biggest
impediment for a grant collaboration.
Aaron W. Hsu
>On Jan 20, 12:20=A0pm, Marek Kubica <ma...@xivilization.net> wrote:
>> Not everyone values speed above functionality and PLT brings a lot of
>> the latter:
[...]
>I acknowledge there is probably a lot more in store for PLT library
>wise. However, at the same time I fail to understand what might be so
>exciting in investing time, energy, and manpower in a dog slow PLT
>implementation. Speed is simply an issue. comp.lang.python e.g. is
>full of threads which discuss 'speed'. Instead that we learn from
>them and start using Bigloo (because a fast, mature Scheme is already
>out there) people are tricked into all the slow Scheme implementations
>instead.
Speed is also relative. Some people do not need as much speed as
others. There is always a trade-off, and we have to understand that
sometimes, other factors play a bigger role than speed does.
William D Clinger
"very basic" wrote:
> However, at the same time I fail to understand what might be so
> exciting in investing time, energy, and manpower in a dog slow PLT
> implementation.
You are not expected to understand such things.
On the other hand, you should not assume that your
failure to understand gives you special insight.
Several years ago, it would have been fair to refer
to PLT Scheme as "dog slow". Nowadays, however, PLT
Scheme is JIT-compiled on IA32 and PowerPC machines
(and maybe some others). PLT Scheme remains slower
than at least half a dozen other implementations of
Scheme, but it is no longer embarrassingly slow on
the most common platforms, especially when compared
to interpreters for languages like Python.
> Speed is simply an issue. comp.lang.python e.g. is
> full of threads which discuss 'speed'.
Speed is often discussed in comp.lang.python because
Python programmers often discover that the Python
reference implementation isn't fast enough.
> There are a lot of Python projects aimed to speed up Python.
One of the reasons there are so many projects is
that Python has been a single-implementation language
for most of its history, and that implementation
is a (byte code) interpreter.
Scheme, on the other hand, has always had a semantics
that allows effective compilation, and there have been
effective compilers for Scheme since 1978. So there
have already been a lot of Scheme projects that have
succeeded in making Scheme fast.
> And in the end Scheme will have lost the game.
Scheme may indeed lose whatever game you're playing,
but it isn't likely to lose for lack of speed compared
to Python.
Will
Marek Kubica
klohm...@yahoo.de wrote:
> I acknowledge there is probably a lot more in store for PLT library
> wise. However, at the same time I fail to understand what might be so
> exciting in investing time, energy, and manpower in a dog slow PLT
> implementation. Speed is simply an issue. comp.lang.python e.g. is
> full of threads which discuss 'speed'.
This is not true. For many applications speed is not an issue at all.
Nobody cares whether a GUI (that is typicially written in C or C++ and
has bindings to other languages) answers in 65ms or 300ms to a button
click. Number crunching is only one aspect of software but much
software is written for companies (think "enterprise") some even argue
that it's more than for end-users. And this software is rarely speed
related.
For other examples take PHP. Many PHP apps run just fine without any
bytecode cache or whatever - 1 parse & run cycle per Request. Does
anyone care? Rarely.
I am also a Python user and in fact I know Python much better than
Scheme and use it for quite some years. I haven't yet had a case where
the speed is a problem. When I know from the beginning that speed is
going to be an issue and it can't be solved by Python means, I simply
don't choose Python. Some improvements can be achived by using the
Python-JIT Psyco, using NumPy for working with big arrays or Cython for
compiling a Python-like language into C-Modules but these cases are not
that common. I enjoy the language because it provides the features it
does, not because it would outpower C, C++ or OCaml. That's simply not
an issue.
What is an issue is that I'd need to build everything myself. This
costs time and as not everyone just does hobby coding costs actual
money. So starting with something that has an comprehensive standard
library or many 3rd party modules is a huge gain.
> Instead that we learn from them and start using Bigloo (because a
> fast, mature Scheme is already out there) people are tricked into all
> the slow Scheme implementations instead.
If I would need to implement everything myself that I use, the time
would easily outperform any performance gains that a faster
implementation could ever save.
> There are a lot of Python projects aimed to speed up Python. And in
> the end Scheme will have lost the game.
Not so many as you might think. Besides PyPy, a research project on
dynamic languages (not only Python, so Scheme implementations could
profit from it as well) there is not so much. Python 2.6 is a bit
slower than 2.5 and Python 3.0 is even slower. I hope that the
situation will improve in following 3.x releases but this doesn't
bother me that much. I could also use MRI-Ruby which is even slower if
it would provide me with what I need.
Another thing that surprises me is why CPython folks haven't yet looked
at GNU Lighning which is used by PLT to speed up their implementations.
> I can understand that the PLT developers are not keen to contribute to
> a french academic project (and vice versa) even though bigloo is open
> source.
Same applies in the other direction. My hope would be some common
ground so many libraries could be shared between Scheme
implementations. This is why I mentioned sbank, the R6RS-binding for
gobject which might be eventually able to run on more than one
implementation and to which all implementors and users could contribute.
regards,
Marek
Andrew Reilly
> Speed is simply an issue. comp.lang.python e.g. is
> full of threads which discuss 'speed'. Instead that we learn from them
> and start using Bigloo (because a fast, mature Scheme is already out
> there) people are tricked into all the slow Scheme implementations
> instead.
PLT (on machines that support the JIT compiler) is already much faster
than Python, on my code anyway. Yes, speed is an issue: it is one of the
reasons that I switched my project from Python to Scheme. I, for one,
don't need "C speed", though. Just fast enough. And batteries included
(in my case that mostly means xml and match libraries -- ymmv).
Cheers,
--
Andrew
dj3v...@csclub.uwaterloo.ca.invalid
Marek Kubica <ma...@xivilization.net> wrote:
>This is not true. For many applications speed is not an issue at all.
>Nobody cares whether a GUI (that is typicially written in C or C++ and
>has bindings to other languages) answers in 65ms or 300ms to a button
>click.
Your point is valid, but your example is not. 300ms for response to a
button click is slow enough to make a GUI feel laggy to the point of
being unusable.
(300ms to complete an operation the user expects to be nontrivial, on
the other hand, is easily fast enough for something that's only
happening in response to interactive input, especially if the GUI is
still responsive while it's happening.)
There are, from the interactive user's point of view, approximately
five speeds that things can happen at:
-Instantaneous (under around 100ms)
-Blink of an eye (under around 200-500ms)
-Stop to stretch (under 5-10s)
-Wait a minute (1-2min)
-Go get coffee (5-10min)
Response to interactive input *has* to be instantaneous; even if
everything else is running faster, laggy interactive response makes the
system feel slow. For almost anything else (including, in most cases,
doing whatever operation the interactive input is asking for), 'blink
of an eye' is good and 'stop to stretch' is acceptable. ('Stop to
stretch' becomes less acceptable as the frequency of the operation
increases.)
In general, changes in speed that don't cross these boundaries (whether
faster or slower) don't matter for interactive use. (Once something is
taking longer than 5-10 minutes, it's not interactive anymore, it's an
interactively queued batch operation. It's quite reasonable to put "Go
get coffee" on the other side of that threshold.)
(For non-interactive use, the relevant question isn't "How fast is
it?", but "Is it fast enough to meet the deadlines?". Nobody cares
whether the payroll run takes ten minutes or all night[1], as long as
paychecks are available on payday.)
dave
[1] Unless they want to use the computer for something else, of course,
but that's just setting deadlines for releasing the computing
resources as well as for producing the results.
--
Dave Vandervies dj3vande at eskimo dot com
[They think] that spinning your tires madly makes you accelerate faster. When
they catch up to my minivan at the next light, I try to explain this fallacy of
their thinking to them as well. --Paul Tomko in the scary devil monastery
klohm...@yahoo.de
users.org> wrote:
> PLT (on machines that support the JIT compiler) is already much faster
> than Python, on my code anyway. Yes, speed is an issue: it is one of the
> reasons that I switched my project from Python to Scheme. I, for one,
> don't need "C speed", though. Just fast enough. And batteries included
> (in my case that mostly means xml and match libraries -- ymmv).
How do you do
I haven't got any concrete figures yet but I think where Bigloo shines
is how it handles memory. I used it a lot for bigger projects and had
to deal with large data sets. I am not sure but I think a compiler
helps a lot in this respect.
I am the first to switch to PLT (I have no close relationship to
Bigloo whatsoever I find it only quite useful) if they would do the
following: a) implement a means to include Stalin or Bigloo mode for
numerical code in PLT (I have never used Psyco C mode but I have a
colleague who's using it a lot) b) compiler for PLT which produces
fast programs on Mac OS X and Linux/Unix c) a method to indicate types
for clarifying ones own code
I understand that Bigloo its type system is far off from what people
understand under a type system and typed language and encapsulation of
types and data. However, it is quite useful and I am quite sure
someone will come up in the Python community to implement a similar
feature. If they had it, among a compiler, I would have been using
Python already.
See You, Dracula
Marek Kubica
On Wed, 21 Jan 2009 01:24:08 -0800 (PST)
klohm...@yahoo.de wrote:
> I understand that Bigloo its type system is far off from what people
> understand under a type system and typed language and encapsulation of
> types and data. However, it is quite useful and I am quite sure
> someone will come up in the Python community to implement a similar
> feature. If they had it, among a compiler, I would have been using
> Python already.
There was a proposal by Guido van Rossum to add static typing
annotations but the majority (me included) was strongly against
introducing something like this.
regards,
Marek
klohm...@yahoo.de
> There was a proposal by Guido van Rossum to add static typing
> annotations but the majority (me included) was strongly against
> introducing something like this.
>
> regards,
> Marek
Why don't you want write readable code? For me giving type annotations
is not so much about static typing it is about writing readable code.
Why people don't want this is beyond me. In Bigloo I can go away
without giving types as we are used to in Scheme but it is there if I
need to.
Marek Kubica
klohm...@yahoo.de wrote:
> Why don't you want write readable code?
For me code without type annotations is more readable. Like in the
original SICP-taught Scheme. Nobody complains that the code is difficult
to read there, so why shoult it be in Python?
I also prefer static type systems with type inference like Scala to
what Java does (it if really has to be static). YMMV.
regards,
Marek
Marek Kubica
Marek Kubica <ma...@xivilization.net> wrote:
> On Wed, 21 Jan 2009 03:06:17 -0800 (PST)
> klohm...@yahoo.de wrote:
>
> > Why don't you want write readable code?
>
> For me code without type annotations is more readable. Like in the
> original SICP-taught Scheme. Nobody complains that the code is
> difficult to read there, so why shoult it be in Python?
Oh, I forgot it, there's Typed Scheme for all who want to use
it inside PLT: <http://www.ccs.neu.edu/home/samth/typed-scheme/>.
regards,
Marek
Kjetil S. Matheussen
Seems like you are confusing explisit typing with static typing.
Anyhow, in scheme you are free to add comments about types, make
types part of variabel names, or write your
own preprocessor in scheme to remove types, if you want to.
Besides, less verbose code is also more readable. Explisit typing
is more verbose.
Here's some interesting stuff to read:
http://en.wikipedia.org/wiki/Type_system
Aaron W. Hsu
>On Jan 21, 11:01=A0am, Marek Kubica <ma...@xivilization.net> wrote:
>> There was a proposal by Guido van Rossum to add static typing
>> annotations but the majority (me included) was strongly against
>> introducing something like this.
>Why don't you want write readable code?
You may find explicit type declarations in your code makes your code
more readable, but in my experience, it only makes my code harder to
read.
klohm...@yahoo.de
wrote:
> Anyhow, in scheme you are free to add comments about types, make
> types part of variabel names,
And this simply sucks in my opinion. I wouldn't use Scheme if Bigloo
hadn't given me the type annotations. I know what it means to program
in a language without such a mechanism. I sometimes have to use IDL
(similar to Matlab) and whilst IDL only has some basics data types it
is a nightmare to read other peoples and ones own code even after
trying to give meaningful names to variables and data structures.
(Btw: Bigloo has more than type annotations because passing the wrong
data structure turns Bigloo in a picky compiler.)
klohm...@yahoo.de
> You may find explicit type declarations in your code makes your code
> more readable, but in my experience, it only makes my code harder to
> read.
Could you give me a minimal example or demonstration why? I know one
could abuse it in this way: number::array. But then still better than
only having descriptive names of variables and data structures (thats
fine to the point once you create them but will become a problem once
you start chancing your data structures and descriptive names become
not descriptive anymore if you don't change every instance too).
Pascal Costanza
(define (some? f:predicate x:pair-or-null)
(if (null? x:pair-or-null)
#f
(or (f:predicate (car x:pair-or-null))
(some? f:predicate (cdr x:pair-or-null)))))
(define (mymap f:procedure x:pair-or-null . xs:list-of-pair-or-null)
(if (or (null? x:pair-or-null)
(some? null? xs:list-of-pair-or-null))
'()
(cons (apply f:procedure (car x:pair-or-null)
(mymap car xs:list-of-pair-or-null))
(apply mymap f:procedure (cdr x:pair-or-null)
(mymap cdr xs:list-of-pair-or-null)))))
;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
klohm...@yahoo.de
> (define (some? f:predicate x:pair-or-null)
> (if (null? x:pair-or-null)
> #f
> (or (f:predicate (car x:pair-or-null))
> (some? f:predicate (cdr x:pair-or-null)))))
>
> (define (mymap f:procedure x:pair-or-null . xs:list-of-pair-or-null)
> (if (or (null? x:pair-or-null)
> (some? null? xs:list-of-pair-or-null))
> '()
> (cons (apply f:procedure (car x:pair-or-null)
> (mymap car xs:list-of-pair-or-null))
> (apply mymap f:procedure (cdr x:pair-or-null)
> (mymap cdr xs:list-of-pair-or-null)))))
>
> ;)
>
Hi: For the rest of us could you comment a bit further? Thanks,
Frankenstein
Pascal Costanza
Is this code easier to understand?
(define (some? f x)
(if (null? x)
#f
(or (f (car x))
(some? f (cdr x)))))
(define (mymap f x . xs)
(if (or (null? x) (some? null? xs))
'()
(cons (apply f (car x) (mymap car xs))
(apply mymap f (cdr x) (mymap cdr xs)))))
If so, then you have an example where code is easier to understand when
type annotations are left out.
klohm...@yahoo.de
The Scheme people want the following:
==
(define (some? f:predicate x:pair-or-null)
(if (null? x:pair-or-null)
#f
(or (f:predicate (car x:pair-or-null))
(some? f:predicate (cdr x:pair-or-null)))))
==
I have this: the Bigloo way to go:
==
(define (some?::obj f::predicate x::pair-or-null)
(if (null? x)
#f
(or (f (car x))
(some? f (cdr x)))))
==
I wouldn't want to understand why you might chose the following over
the above Bigloo code:
==
(define (some? f x)
(if (null? x)
#f
(or (f (car x))
(some? f (cdr x)))))
==
Sam TH
In Typed Scheme[1], you can write:
(: some? (All (a) ((a -> Boolean) (Listof a) -> Boolean)))
(define (some? f x)
(if (null? x)
#f
(or (f (car x))
(some? f (cdr x)))))
which seems to be to have all the advantages of static typing,
including soundness (which I don't think the bigloo type system gives
you), without the code clutter. Typed Scheme is built entirely using
a library, on top of the PLT Scheme macro and module system.
[1] http://www.ccs.neu.edu/~samth/typed-scheme/
sam th
Sam TH
> Hi. I'm brand new to Scheme, trying to learn my way around in what
> free time I can find (and deciding on an implementation to use (at
> least, for a while)). So far, it seems to me as if there are 2 major
> camps in the Scheme community: those that like classic spare standard
> Scheme (R5RS), and those who prefer PLT with its practical additions
> (R6RS). I'd appreciate correction on this if I'm mistaken.
There are really multiple camps in the Scheme community. Here's a non-
exhaustive list (with representatives):
1. People who prefer R5RS, and think it should not have been extended.
(Felix Winkelmann, maintainer of Chicken)
2. People who like R5RS, dislike R6RS, but think a better standard for
Scheme is possible (Will Clinger, maintainer of Larceny)
3. People who use R6RS as their primary language (Aziz Ghoulum,
maintainer of Ikarus)
4. People who use a particular Scheme implementation (myself, using
PLT)
Many of the practical additions to R6RS have analogues in
implementation-specific extensions, especially in PLT, which may be
what led to your confusion.
Right now, groups 1 and 2 seem similar, since they don't have a
standard to disagree about. Group 4 often looks like the PLT group,
because PLT encourages writing programs in PLT dialects (they're
nice!).
> Anyway, my question is this: are the issues that some people have with
> R6RS about serious flaws that they see with R6RS -- which will cause
> pain down the road -- or are the issues mostly about not ruining the
> simple and elegant quality of Scheme (say, mostly cosmetic)?
>
> Because, if it's the latter, then I'll probably use PLT and put up
> with just a little ugliness to get the useful additions and large
> community support. But if it's the former, I'll stick with an R5R6
> until the madness ends. :)
Opinions differ strongly on your question, as I'm sure you can see. I
would say that the elegant qualities of Scheme are very much there in
R6RS, and also in PLT Scheme. The unfortunate aspects of R6RS are
mostly cosmetic. However, if you're going to use PLT Scheme (which I
encourage), you should probably just use the `scheme' language, rather
than attempting to program in R6RS, since this gives you access to all
of the features and community of PLT Scheme.
Hope that helps,
sam th
Aaron W. Hsu
I do not know if this will satisfy you, but it is precisely because I
change data structures that I do not want to worry about the type
declarations in the code.
For example, I often use some preliminary data representation that is
very simple and easy to implement, then, I change things under the hood.
The object that my abstraction procedure returns could change. Sure,
I would normally have extracted these out into their own types by this
time as well, but this still results in a lot of tedious book keeping,
and it doesn't really help the reliability of my program any, because I
already know that the procedures working on my code are going to use the
same data structures.
(define db-insert! ...)
(define make-db ...)
(define db-delete! ...)
(define db-ref ...)
(define do-something-with-db
(lambda (db blah)
...))
(define starter
(lambda ()
(let ([db (make-db)])
(do-something-with-db db 'yeah))))
Now, I don't think this is a very strong example, per se, but someone
has already contributed another example. In this case, I don't have to
care about the type of db, and why should I? I am using the interface,
and whatever happens around there shouldn't matter.
Or take the following:
(define get-results
(lambda (input1 input2 type)
(let-values ([(port write read) (grab-io-ops type)])
(map (lambda (key val)
(write key port)
(write val port)
(read port))
input1 input2))))
And so forth. I don't see why these would benefit in clarity from
type declarations that are explicit. For example, with LET-VALUES are
you going to say that type declarations would make more sense there as
well? If not,then what is the use of having a type declaration for
GRAB-IO-OPS if we don't check the values that it returns? If we are just
checking function calls, well, there are a lot of, constructs which bind
and aren't explicit lambdas, are we going to put type declarations in
all of these?
I don't think any of these forms would benefit much from that kind of
type declaration. Of course, Typed Scheme is a whole other ball game,
and if you like types, then why not use a typed language like Typed
Scheme? Otherwise, I use Scheme, and I'm not such a fan of explicit
type declarations.
Aaron W. Hsu
>The Scheme people want the following:
>
>(define (some? f:predicate x:pair-or-null)
> (if (null? x:pair-or-null)
> #f
> (or (f:predicate (car x:pair-or-null))
> (some? f:predicate (cdr x:pair-or-null)))))
>I have this: the Bigloo way to go:
>(define (some?::obj f::predicate x::pair-or-null)
> (if (null? x)
> #f
> (or (f (car x))
> (some? f (cdr x)))))
>I wouldn't want to understand why you might chose the following over
>the above Bigloo code:
>(define (some? f x)
> (if (null? x)
> #f
> (or (f (car x))
> (some? f (cdr x)))))
I find none of these solutions to be good style. Do you need ugly type
declarations when you use good names like the following? I don't think
the types like the ones in Bigloo that you are mentioning help here with
clarity:
(define some?
(lambda (proc? lst)
(if (null? lst)
#f
(or (proc? (car lst))
(some? proc? (cdr lst))))))
Michael Schuerig
> On Jan 21, 1:39 pm, "Kjetil S. Matheussen" <k.s.matheus...@notam02.no>
> wrote:
>
>> Anyhow, in scheme you are free to add comments about types, make
>> types part of variabel names,
>
> And this simply sucks in my opinion. I wouldn't use Scheme if Bigloo
> hadn't given me the type annotations.
This statement may be the clue to the entire disagreement.
Apparently, you have found a language (implementation) that suits your
taste -- great. Implying that others who don't share your taste are
somehow defective is not so great. Your earlier "Why don't you want
write readable code?" wasn't meant as a question, I take it, but rather
an accusation.
What it comes down to is this: Is it your aim to understand people who
make different choices than yourself or do you intend to convert them?
Michael
--
Michael Schuerig
mailto:mic...@schuerig.de
http://www.schuerig.de/michael/
Sam TH
> Grant Rettke quoting me:
>
> > > One of the R6RS's more fundamental flaws is that it
> > > absolutely forbids implementation [...] via interactive
> > > read/eval/print loops.
>
> > Is this a problem that Common Lisp solved? How did they address it?
>
> Common Lisp solved the problem the same way the
> original and revised reports on Scheme did, which
> is the same way the RRRS/R3RS/R4RS/R5RS/IEEE/ANSI
> standards did: by not creating the problem in the
> first place.
>
> Both uses of the word "must" in the last sentence
> of R6RS 5.5 are gratuitous in the sense that there
> is scant technical justification for them, but both
> uses were entirely deliberate. As can be seen from
> chapter 8 of their rationale, the editors really
> did want to rule out pure interpreters and REPLs.
>
> The editors appear to have believed that having a
> few ambiguities in a REPL-compatible semantics is
> worse than not having any REPL-compatible semantics
> at all.
The portions of Section 5.5 to which you refer no more rule out REPLs
than they rule out C compilers (by which I mean compilers for the C
programming language). They simply do not address their behavior or
relationship to R6RS programs.
For example, DrScheme's Module language provides a REPL for R6RS
programs, which is not in conflict with the R6RS, but also not
required or specified or constrained by it.
> > On one hand, it seems like one thing that R6RS did do was to shed
> > light on the lack of interest implementers had in portability.
>
> > On the other, it makes it seem like there was never a portability
> > problem that needed to be solved.
>
> > Which one was it?
>
> That's a weird false dichotomy.
>
> It can be argued that the R6RS shed light on the R6RS
> editors' lack of interest in portability, but it can
> also be argued that the portability problems created
> by the R6RS arose from carelessness, poor design, or
> a belief that users and implementors would support
> any standard, no matter how bad, so long as it could
> be ratified by at least 60% of the voters. As it is,
> two of the three systems represented by the editors
> themselves still do not support the R6RS, and the
> only one that does (PLT Scheme) appears to regard
> both the R6RS and R5RS as "legacy" standards while
> encouraging programmers to write nonstandard and
> PLT-specific code.
It is not the case that PLT regards R6RS as a legacy standard - only
R5RS is marked that way in the documentation.
sam th
klohm...@yahoo.de
> Apparently, you have found a language (implementation) that suits your
> taste -- great. Implying that others who don't share your taste are
> somehow defective is not so great. Your earlier "Why don't you want
> write readable code?" wasn't meant as a question, I take it, but rather
> an accusation.
>
> What it comes down to is this: Is it your aim to understand people who
> make different choices than yourself or do you intend to convert them?
Good morning
[I haven't seen any convincing examples from you so far]. I do not
want to convince people here but nobody should ask me why I as manager
wouldn't let people chose Scheme in a bigger project whilst using
Scheme as my own pet language (I used it daily for a couple of years].
Scheme stands no chance as long as people are not going to improve the
speed (compiler) and type declarations (readable code). Okay good it's
great if the majority of Scheme programmers are happy with that
situation displaying the desire to use a slow implementation for
mimicking the Python programmer. That's it.
klohm...@yahoo.de
> In Typed Scheme[1], you can write:
>
> (: some? (All (a) ((a -> Boolean) (Listof a) -> Boolean)))
> (define (some? f x)
> (if (null? x)
> #f
> (or (f (car x))
> (some? f (cdr x)))))
>
> which seems to be to have all the advantages of static typing,
> including soundness (which I don't think the bigloo type system gives
> you), without the code clutter. Typed Scheme is built entirely using
> a library, on top of the PLT Scheme macro and module system.
>
> [1]http://www.ccs.neu.edu/~samth/typed-scheme/
>
> sam th
Hi
This sounds interesting didn't know that PLT has a layered type
mechanism on top of it. Thanks for posting and sharing this. However,
for my needs PLT would still be way to slow. I am speaking of huge
data sets from climate models and post-processing. Even post-
processing of the model outputs (depending on my developed algorithm)
takes in my case 2 to 3 days on a workstation until it converges (add
this to the couple of week long basic model runs on parallel
processors). I haven't used Bigloo because we have some handy to use
Fortran codes to read the binary data format from the global chemistry
model. But I think Bigloo would do well (according to my experience
using it during my PhD for larger data sets) in my post evaluation.
I have no empirical figures to back this up but I think even if one
would use a foreign C function to lets say processing arrays (e.g.
eigenvalues or matrix inverse) PLT will fail catastrophically due to
how it copes with memory. I think a compiler (even if memory being
garbage collected in Bigloo) will help.
I gather speed is not only an issue in my field. As I said I am the
first to jump queue and start using PLT once they give me a compiler
and type system. I also would like to use a Scheme with a larger
community (I guess there are more people using PLT than Bigloo).
Fortress sounds interesting for high performance computing but I
haven't found any useful examples on the net (the original Sun site
does not do much). Does Fortress have higher order functions?
Thanks, Fruit&Brain Muesli
Andrew Reilly
> PLT will fail catastrophically due to how it copes with memory. I think
> a compiler (even if memory being garbage collected in Bigloo) will help.
What gives you the impression that PLT is bad with memory? I agree that
memory management is crucial: all dynamic languages live and die, in the
large, by the sophistication and efficiency of their memory management.
You can typedef until you're blue in the face but it's all for naught if
your cache thrashes because your memory is all over the place. After
all, dynamic languages refuse to let the programmers deal with it, for
good reason, but that is a double edged sword. From what I've read, and
in my personal experience, I'd say that PLT's BIBOP-based memory
management is exceptionally good. They might not be quite up with a
couple of the high-end JVMs with respect to multi-processor or real-time,
but they're well ahead of the conservative collectors used in C-friendly
environments like Bigloo, I thnink. (Bigloo still uses a standard Bohem
conservative collector, doesn't it?) And streets ahead of Python's
reference counting, of course.
Cheers,
--
Andrew
Pascal Costanza
...and there are those who think that car, cdr and maybe even lst are
bad names, and so on, and so on.
Readability is in the eye of the beholder, and human beings can get used
to almost anything with regard to readability with enough practice. The
things you find most "natural" are probably just those which you
happened to have learned first, which is very likely a completely
arbitrary accident.
For example, I find German is the easiest language to understand, and I
don't get it how people can put up with anything else. ;-)
Sam TH
> On Jan 21, 4:21 pm, Sam TH <sam...@gmail.com> wrote:
>
>
>
> > In Typed Scheme[1], you can write:
>
> > (: some? (All (a) ((a -> Boolean) (Listof a) -> Boolean)))
> > (define (some? f x)
> > (if (null? x)
> > #f
> > (or (f (car x))
> > (some? f (cdr x)))))
>
> > which seems to be to have all the advantages of static typing,
> > including soundness (which I don't think the bigloo type system gives
> > you), without the code clutter. Typed Scheme is built entirely using
> > a library, on top of the PLT Scheme macro and module system.
>
> > [1]http://www.ccs.neu.edu/~samth/typed-scheme/
>
> > sam th
>
> Hi
>
> This sounds interesting didn't know that PLT has a layered type
> mechanism on top of it. Thanks for posting and sharing this. However,
> for my needs PLT would still be way to slow.
Do you have an particular benchmarks on which PLT performs poorly?
> I am speaking of huge
> data sets from climate models and post-processing. Even post-
> processing of the model outputs (depending on my developed algorithm)
> takes in my case 2 to 3 days on a workstation until it converges (add
> this to the couple of week long basic model runs on parallel
> processors). I haven't used Bigloo because we have some handy to use
> Fortran codes to read the binary data format from the global chemistry
> model. But I think Bigloo would do well (according to my experience
> using it during my PhD for larger data sets) in my post evaluation.
>
> I have no empirical figures to back this up but I think even if one
> would use a foreign C function to lets say processing arrays (e.g.
> eigenvalues or matrix inverse) PLT will fail catastrophically due to
> how it copes with memory. I think a compiler (even if memory being
> garbage collected in Bigloo) will help.
Claims about program performance without empirical data are rarely
useful, in my experience.
> I gather speed is not only an issue in my field. As I said I am the
> first to jump queue and start using PLT once they give me a compiler
> and type system. I also would like to use a Scheme with a larger
> community (I guess there are more people using PLT than Bigloo).
PLT Scheme, as Will Clinger pointed out, does include a compiler for
all significant platforms, and as I pointed out, comes with an
optional type system.
>
> Fortress sounds interesting for high performance computing but I
> haven't found any useful examples on the net (the original Sun site
> does not do much). Does Fortress have higher order functions?
There's extensive documentation and examples for Fortress here:
http://projectfortress.sun.com/Projects/Community
Fortress does support higher-order functions.
sam th
Aaron W. Hsu
>[I haven't seen any convincing examples from you so far]. I do not
>want to convince people here but nobody should ask me why I as manager
>wouldn't let people chose Scheme in a bigger project whilst using
>Scheme as my own pet language (I used it daily for a couple of years].
>Scheme stands no chance as long as people are not going to improve the
>speed (compiler) and type declarations (readable code). Okay good it's
>great if the majority of Scheme programmers are happy with that
>situation displaying the desire to use a slow implementation for
>mimicking the Python programmer. That's it.
You do realize that there are quite a few highly performant Scheme
implementations out there, right? They're fast. I use one; it is
called Chez. Comparing Scheme to Python with regards to speed is fairly
useless, because they're no where close to the same situation. In
Scheme you have Stalin, Bigloo, Chez, Gambit, Larceny, Chicken, and the
like, all of which are fairly competent compilers. You have JIT
Compilation that is under development in PLT. You have pure
interpreters, bytecode interpreters, and whatnot too if you prefer that.
You mentioned memory management: Scheme implementations differ widely in
how they implement it, but there are some Schemes which have very good
memory management.
Whether you have type declarations or not is rather moot, since we are
talking about Scheme here.
BTW, do you have some benchmarking examples of some code that you
believe doesn't perform very well? I would be interested if you could
put up some code demonstrating the kind of applications are you trying
to build and run for which you think Scheme is less than satisfactory.
Forgive me if you have already done this.
William D Clinger
> The portions of Section 5.5 to which you refer no more rule out REPLs
> than they rule out C compilers (by which I mean compilers for the C
> programming language). They simply do not address their behavior or
> relationship to R6RS programs.
True. The absolute requirements at the end of R6RS 5.5
imply only that implementations of the R6RS cannot use
a REPL. They do not prevent implementations of ERR5RS
or the IEEE/ANSI/R5RS standards or SamsLisp or C from
using a REPL.
> It is not the case that PLT regards R6RS as a legacy standard - only
> R5RS is marked that way in the documentation.
On the other hand, you yourself confirmed the main point
of my sentence earlier in this thread when you wrote that
"PLT encourages writing programs in PLT dialects" as
opposed to writing portable code in standard languages
such as those described by the IEEE/ANSI/R5RS standards
or the R6RS.
Will
David Rush
> However, at the same time I fail to understand what might be so
> exciting in investing time, energy, and manpower in a dog slow PLT
> implementation. Speed is simply an issue. comp.lang.python e.g. is
> full of threads which discuss 'speed'. Instead that we learn from
> them and start using Bigloo (because a fast, mature Scheme is already
> out there)
For performace, there are what I like to think of as "the big four":
Bigloo
Larceny
Gambit
Stalin
Unfortunately, my personal and private opinions are somewhat dated.
Stalin has been semi-abandoned even though it was one of the most
efficient compilers on the planet. Compiled Chicken has developed a
reputation for being fast when compiled (I've never gotten around to
benchmarking recent version against my applications). Ikarus is also
reputed to be fast but I couldn't build it on my x86_64 last time I
tried and I am also allergic to Cygwin.
Overall, I find Gambit to be the most portable, but I use Larceny
because it has a less complex tool chain (it compiles to native x86
machine code on Windows without using an external C compiler). For all
of these systems you have to spend time tweaking optimization settings
in order to get peak performance. Avoiding type ambiguities also
helps :)
david rush
Aaron W. Hsu
>I have no empirical figures to back this up but I think even if one
>would use a foreign C function to lets say processing arrays (e.g.
>eigenvalues or matrix inverse) PLT will fail catastrophically due to
>how it copes with memory. I think a compiler (even if memory being
>garbage collected in Bigloo) will help.
If you are interested in efficient and fast memory management, you
should check out the various methods each of the Scheme implementations
use. Chez is known to be pretty good in this area, and it uses a
generational garbage collector. I do not know what Bigloo uses, but you
should hunt around and expirement.
David Rush
> On Tue, 20 Jan 2009 05:42:54 -0800 (PST)
> For many applications speed is not an issue at all.
> Nobody cares whether a GUI (that is typicially written in C or C++ and
> has bindings to other languages) answers in 65ms or 300ms to a button
> click.
Um, I would definitely care. There is a very noticeable different
between 65ms and 300 ms. Had you chosen 10ms and 50ms I might have
agreed with you...
david
klohm...@yahoo.de
> BTW, do you have some benchmarking examples of some code that you
> believe doesn't perform very well? I would be interested if you could
> put up some code demonstrating the kind of applications are you trying
> to build and run for which you think Scheme is less than satisfactory.
> Forgive me if you have already done this.
Sorry I don't have examples handy right now. As I said I believe
Bigloo would be up to the task. However, could you post an example on
how to read in a binary file (must work on big and little endian) of
the following kind:
==
144 91 100000 12.23 3.34 4.55 6.7 ...
==
first 3 numbers are the dimension (3 dim array: typically
144x91x100000) and the rest denotes the double precision numbers. I
could create a test example in PLT to read in 10 arrays of dimension
144x91x100000 for every day in a year (that's 365 days times 12 month)
and additionally some other artificial arrays. I am not going
implementing my algorithm but could simply check if PLT can cope with
large data sets. I don't need all days at once: day after day.
I haven't tried it yet with Bigloo (I have a function to read in
binary data very quickly though).
Even in my Fortran program reading in the arrays is a performance
killer.
If you post me a function for PLT I could try to create such a test-
bed (frankly: not today, not tomorrow, probably in the next couple of
weeks or even months to come). If you want first see my Bigloo
function for reading the binary drop me a note (here in cls) and I
will post it here on the forthcoming weekend.
Thanks, Dracula
klohm...@yahoo.de
> If you post me a function for PLT I could try to create such a test-
> bed (frankly: not today, not tomorrow, probably in the next couple of
> weeks or even months to come). If you want first see my Bigloo
> function for reading the binary drop me a note (here in cls) and I
> will post it here on the forthcoming weekend.
sorry typo: my typical arrays or data sets (10 for each day) are:
67x67x50000 in dimension or 7x7x1e5
William D Clinger
> If you are interested in efficient and fast memory management, you
> should check out the various methods each of the Scheme implementations
> use. Chez is known to be pretty good in this area, and it uses a
> generational garbage collector. I do not know what Bigloo uses, but you
> should hunt around and expirement.
Chez Scheme, Larceny, and Ikarus use generational collectors,
and Chicken's collector behaves a little like a generational
collector. I believe that Bigloo, Gambit, MIT Scheme, and
Stalin use non-generational collectors by default, although
some of them (Gambit, at least) offer alternative collectors
as well.
Generational collectors tend to perform better on typical
allocation-intensive programs, but don't help much (and may
actually hurt) on really nasty gc-intensive programs because
their worst-case behavior is usually about the same as for
non-generational collectors (and they add a bit of overhead
besides).
Although the person who admits he has "no empirical figures
to back this up" thinks PLT Scheme's memory management is
worse than Bigloo's, my empirical figures fail to support
his belief. Bigloo does tend to perform better than PLT
Scheme on gc-intensive benchmarks, but no more so than on
other kinds of benchmarks [1].
Will
[1] http://www.ccs.neu.edu/home/will/Larceny/benchmarks.html
Marek Kubica
Sam TH <sam...@gmail.com> wrote:
> > I gather speed is not only an issue in my field. As I said I am the
> > first to jump queue and start using PLT once they give me a compiler
> > and type system. I also would like to use a Scheme with a larger
> > community (I guess there are more people using PLT than Bigloo).
>
> PLT Scheme, as Will Clinger pointed out, does include a compiler for
> all significant platforms, and as I pointed out, comes with an
> optional type system.
I wonder, do the type checks make it any faster? That is: are there
optimizations for this or is it layered on top as a way of providing
additional type checks for those who want them?
regards,
Marek
klohm...@yahoo.de
> Although the person who admits he has "no empirical figures
> to back this up" thinks PLT Scheme's memory management is
> worse than Bigloo's, my empirical figures fail to support
> his belief. Bigloo does tend to perform better than PLT
> Scheme on gc-intensive benchmarks, but no more so than on
> other kinds of benchmarks [1].
I am worried about memory out of this reasons: IDL for example (have
no idea what kind of garbage collector is being used there) does
consume memory as long as there is enough free memory and all in a
sudden wreaks havoc. Even if one tries to free up memory in the code
e.g. A=0 (setting a large array to and integer zero).
What would happen if one writes (set! a 0) in PLT (a is lets say an
array of dimension 67x67x50000)?
Marek Kubica
klohm...@yahoo.de wrote:
> Scheme stands no chance as long as people are not going to improve the
> speed (compiler) and type declarations (readable code).
Let's take for example the rise of Ruby on Rails which has probably
more users than all Scheme implementations altogether (at least it is a
whole lot easier to find people knowing it and jobs). Rails is based on
Ruby which has neither type annotations nor a good speed (in fact, Ruby
1.8 is usually the slowest of all dynamic languages). Was this a
problem? Not at all. People were able to solve their problems fast,
that is what mattered.
As said, speed may matter to you and it is fine, because you probably
work on large data sets and heavy computation. Most people don't.
regards,
Marek
Aaron W. Hsu
>Readability is in the eye of the beholder, and human beings can get used
>to almost anything with regard to readability with enough practice. The
>things you find most "natural" are probably just those which you
>happened to have learned first, which is very likely a completely
>arbitrary accident.
Of course, I agree with you. I was not trying to argue that there
exists some one clearest style.
Aaron W. Hsu
>For performace, there are what I like to think of as "the big four":
>Bigloo
>Larceny
>Gambit
>Stalin
Aw, not gonna mention Chez? :-) Commercial compilers get sidelined, eh?
Sam TH
> Sam TH wrote:
> > The portions of Section 5.5 to which you refer no more rule out REPLs
> > than they rule out C compilers (by which I mean compilers for the C
> > programming language). They simply do not address their behavior or
> > relationship to R6RS programs.
>
> True. The absolute requirements at the end of R6RS 5.5
> imply only that implementations of the R6RS cannot use
> a REPL. They do not prevent implementations of ERR5RS
> or the IEEE/ANSI/R5RS standards or SamsLisp or C from
> using a REPL.
I'm not sure what you believe the import of this to be. Do you
believe that the REPL provided by DrScheme's module language for R6RS
programs is in violation of the R6RS? If not, how is this not an
implementation of R6RS with a REPL? Or are you merely pointing out
that it is not possible to rely on a REPL in and R6RS program?
> > It is not the case that PLT regards R6RS as a legacy standard - only
> > R5RS is marked that way in the documentation.
>
> On the other hand, you yourself confirmed the main point
> of my sentence earlier in this thread when you wrote that
> "PLT encourages writing programs in PLT dialects" as
> opposed to writing portable code in standard languages
> such as those described by the IEEE/ANSI/R5RS standards
> or the R6RS.
First, I think it's a mistake to conflate the IEEE/ANSI standard with
the R5RS, since they specify different languages. Second, this
doesn't make R6RS a legacy standard - merely not the language that we
feel is best suited for developing applications. If portability
between different Scheme implementations is a requirement for your
program, I think R6RS is the correct standard to choose. However, in
my experience this is rarely an important requirement. Your
experience may differ.
sam th
Sam TH
Typed Scheme is layered on top of untyped PLT Scheme. Currently,
there's no way to use the type information to optimize the code, but
we hope to eventually take advantage of this.
sam th
Sam TH
[samth@punge:~] mzscheme
Welcome to MzScheme v4.1.4.1 [3m], Copyright (c) 2004-2009 PLT Scheme
Inc.
> (collect-garbage)
> (current-memory-use)
7606276
> (define a (make-vector 1000000))
> (current-memory-use)
11684884
> (set! a 0)
> (collect-garbage)
> (current-memory-use)
7621248
>
sam th
William D Clinger
> I'm not sure what you believe the import of this to be. Do you
> believe that the REPL provided by DrScheme's module language for R6RS
> programs is in violation of the R6RS?
It would be a violation of the R6RS only if PLT Scheme
were to claim that the REPL implements R6RS. Presumably
PLT Scheme makes no such claim, and you are the only
person who is trying to give any such impression.
> If not, how is this not an implementation of R6RS with a REPL?
PLT Scheme is an implementation of the R6RS that is also
an implementation of the R5RS and is also an implementation
of a non-R6RS REPL that someone thinks might be useful to
R6RS programmers. What you refer to as "the REPL provided
by DrScheme's module language for R6RS programs" is analogous
to Larceny's ERR5RS mode; it is not an implementation of the
R6RS.
> First, I think it's a mistake to conflate the IEEE/ANSI standard with
> the R5RS, since they specify different languages.
There are about half a dozen minor differences between
the IEEE/ANSI standard and the R5RS, with no outright
incompatibilities between the two. Almost all systems
that have implemented the IEEE/ANSI standard have also
implemented the R5RS in the same mode, so there is very
little practical difference between the IEEE/ANSI standard
and the R5RS.
Compare that situation to the R6RS. At this moment, there
is at most one implementation (Ypsilon) that conforms to
the R6RS. The differences between the languages implemented
by the six R6RS-compatible implementations are considerably
more significant than the differences between the IEEE/ANSI
standard and the R5RS.
Will
Aaron W. Hsu
>144 91 100000 12.23 3.34 4.55 6.7 ...
>first 3 numbers are the dimension (3 dim array: typically
>144x91x100000) and the rest denotes the double precision numbers. I
>could create a test example in PLT to read in 10 arrays of dimension
>144x91x100000 for every day in a year (that's 365 days times 12 month)
>and additionally some other artificial arrays. I am not going
>implementing my algorithm but could simply check if PLT can cope with
>large data sets. I don't need all days at once: day after day.
Before someone could write a reasonably efficient implementation of this
code, he would want:
A) The format of the numbers if they are binary rather than
textual.
B) The directionality and majorness (?) of the matrix. That is,
how is the matrix laid out in the file?
C) Are the matrices sparse or well populated?
D) What operations are most important to you when handling these
matrices? Is it traversal, random access, random write, or
something else?
E) How much memory do the machines you are using have?
F) What does the program look like that is using the matrix?
G) Does the program need the entire matrix in memory at one
time?
H) Did I miss anything?
You can't just give me the above and expect me to come up with a
solution, or anyone to come up with a solution for that matter, out of
the description you gave. I have worked with matrices like this in
Scheme before, and they can be rather large, but they are plenty
manageable with a decent Scheme system so long as you know what your
application does and how you will need to handle things. For example, I
had very large matrices, but I could take advantage of some sparsity.
This doesn't appear to be the case for you, but if it is, then that
plays a factor.
Aaron W. Hsu
>On Jan 22, 2:43=A0pm, klohmusc...@yahoo.de wrote:
>> If you post me a function for PLT I could try to create such a test-
>> bed (frankly: not today, not tomorrow, probably in the next couple of
>> weeks or even months to come). If you want =A0first see my Bigloo
>> function for reading the binary drop me a note (here in cls) and I
>> will post it here on the forthcoming weekend.
> sorry typo: my typical arrays or data sets (10 for each day) are:
>67x67x50000 in dimension or 7x7x1e5
That is helpful to know. Is there an upper bound on the dimensions of
the arrays? I ask this because there are sometimes very high fixed
limits for certain data structures in given implementations that have to
be worked around if the datasets are too large for those data
structures. This is a limitation inherent in the implementation, not
the language, though.
klohm...@yahoo.de
> That is helpful to know. Is there an upper bound on the dimensions of
> the arrays? I ask this because there are sometimes very high fixed
> limits for certain data structures in given implementations that have to
> be worked around if the datasets are too large for those data
> structures. This is a limitation inherent in the implementation, not
> the language, though.
Hi Aaron:
There are no upper bounds I guess I am not only using climate model
outputs I am also using satellite observations. I have had to pre-
process the satellite data because 1 day worth of observations is
about 350MB larges. The idea for my post-processing is: using output
of climate/chemistry models, some theory called 'inversion' and all is
constraint by the satellite observations.
I shall post the Bigloo version for reading the binary arrays in the
next couple of days. I would have been interested in how one could
read binary data in PLT. The code itself (I only have a brute - no
algorithm - Fortran 95 version of it) does a lot of matrix
multiplications and calculating the inverse of a matrix. In this whole
process a lot of new intermediary arrays are being created (I use
'allocate' and 'free' in Fortran 90). I haven't adopted the code for
our multiprocessors but a typical runtime on my local machine is 48 to
72 hours (as I said reading in the data is a limiting factor because I
cannot read in all the data - even when pre-processed and cut down
from 350MB for one day - and keep it in memory because I only have 2
MB). However, memory is not an issue because my code only takes up 500
MB at any time and reads in data sequential.
Btw: I wrote a Bigloo binding to lapack (I implemented all of the more
than over 1000 functions, however haven't had time to test it). Maybe
one day I will find some more time to test how long Bigloo would take
for my problem (instead of using Fortran).
I am interested in how to you handle multi-processors with your Scheme
implementation? We use the ifort compiler and as far I have seen from
other peoples code giving MPI comments before a loop is quite straight
forward and the ifort compiler will do the rest.
William D Clinger
> Sorry I don't have examples handy right now. As I said I believe
> Bigloo would be up to the task. However, could you post an example on
> how to read in a binary file (must work on big and little endian) of
> the following kind:
See below.
With a 7x7x10000 input, which is the smaller of the two
sizes you said was typical, the double precision numbers
occupy about 4 megabytes, so what you have described
would be more of an io benchmark than a storage management
benchmark.
With a 67x67x50000 input, which the larger of the two
sizes you said was typical, the double precision numbers
occupy 1.8 gigabytes, so storage might indeed become a
factor.
I suspect that at least one of the sizes you mentioned
was another typo. If the larger input size is correct,
then I suspect you are using arrays of unboxed flonums.
Although neither the R5RS nor the R6RS provide standard
representations for such arrays, they are easily
implemented in portable R6RS code; for the benchmark,
I just used raw bytevectors (which is not what I would
use for a real application, but it makes the benchmark
a little simpler and has little effect on the timing).
For the larger 67x67x50000 input, PLT Scheme reads the
array from the file in 4.2 seconds on my 2.4 GHz MacBook
Pro. (The current version of Larceny takes 5 minutes
because it reads a byte at a time; improving the speed
of get-bytevector is on our todo list for the next
version.)
So if you have to read 10 of those arrays per day, then
using PLT Scheme instead of Bigloo couldn't possibly
cost you more than 42 seconds.
Bigloo's io may well be faster than PLT Scheme's. Once
you have translated the portable R6RS top-level program
below into a non-portable Bigloo-specific program of the
kind Sam TH advocates, you can compare Bigloo against
PLT Scheme on your own machine and tell us the results.
Will
;;; Benchmark requested by someone on comp.lang.scheme
;;;
;;; The original request:
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; ....could you post an example on
;;; how to read in a binary file (must work on big and little endian)
of
;;; the following kind:
;;; ==
;;; 144 91 100000 12.23 3.34 4.55 6.7 ...
;;; ==
;;;
;;; first 3 numbers are the dimension (3 dim array: typically
;;; 144x91x100000) and the rest denotes the double precision numbers.
;;;
;;; sorry typo: my typical arrays or data sets (10 for each day) are:
;;; 67x67x50000 in dimension or 7x7x1e5
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; Further assumption:
;;;
;;; Each of the three integers at the beginning of the file
;;; is represented by 32 bits, and the endianness is the same
;;; as for the double precision numbers.
;;;
;;; Usage:
;;;
;;; The first command-line argument is the name of the binary file.
;;; The second command-line argument, if supplied, is a boolean
;;; that (if true) tells the program to print the sum of all array
;;; elements.
;;;
;;; Note that the actual syntax of the command line is
;;; implementation-dependent.
#!r6rs
(import (rnrs))
;;; Given the name of a binary file in the format described
;;; by the comment above, returns a vector of vectors of bytevectors
;;; representing double-precision numbers.
;;;
;;; The endianness, if supplied, must be one of the symbols
;;; { little, big }. If no endianness is supplied, the native
;;; endianness is used.
(define (read-binary-array filename . rest)
(let ((endianness (if (null? rest) (native-endianness) (car rest))))
(call-with-port
(open-file-input-port filename)
(lambda (p)
(read-binary-array-from-port p endianness)))))
(define (read-binary-array-from-port p endianness)
(let ((bv (get-bytevector-n p 12)))
(if (and (bytevector? bv)
(= 12 (bytevector-length bv)))
(let ((n1 (bytevector-u32-ref bv 0 endianness))
(n2 (bytevector-u32-ref bv 4 endianness))
(n3 (bytevector-u32-ref bv 8 endianness)))
(read-flonums-from-port p endianness n1 n2 n3))
(read-binary-array-io-error 'read-binary-array-from-port p))))
(define (read-flonums-from-port p endianness n1 n2 n3)
(define (readvec1)
(let ((v (make-vector n1 '#())))
(do ((i 0 (+ i 1)))
((= i n1)
v)
(vector-set! v i (readvec2)))))
(define (readvec2)
(let ((v (make-vector n2 '#())))
(do ((i 0 (+ i 1)))
((= i n2)
v)
(vector-set! v i (readvec3)))))
(define (readvec3)
(let* ((v (make-vector n3 0.0))
(n3*8 (* 8 n3))
(bv (get-bytevector-n p (* 8 n3))))
(if (and (bytevector? bv)
(= n3*8 (bytevector-length bv)))
bv
(read-binary-array-io-error 'read-flonums-from-port p))))
(readvec1))
;;; Reports an io error.
(define (read-binary-array-io-error procname port)
(error procname "io error" port))
;;; Computes sum of all elements of the 3-dimensional array.
;;; Assumes all dimensions are positive, and native endianness
;;; (since this is just for testing the result of a benchmark).
(define (sum-array3 a)
(let* ((n1 (vector-length a))
(n2 (vector-length (vector-ref a 0)))
(n3 (bytevector-length (vector-ref (vector-ref a 0) 0)))
(n3 (/ n3 8)))
(define (sum1 a)
(do ((i 0 (+ i 1))
(sum 0.0 (+ sum (sum2 (vector-ref a i)))))
((= i n1) sum)))
(define (sum2 a)
(do ((i 0 (+ i 1))
(sum 0.0 (+ sum (sum3 (vector-ref a i)))))
((= i n2) sum)))
(define (sum3 bv)
(let ((n3*8 (* 8 n3)))
(do ((i 0 (+ i 8))
(sum 0.0 (+ sum (bytevector-ieee-double-native-ref bv
i))))
((= i n3*8) sum))))
(sum1 a)))
;;; Do the deed, using native endianness.
(let* ((args (cdr (command-line)))
(a (read-binary-array (car args))))
(if (and (not (null? (cdr args)))
(cadr args))
(begin (write (sum-array3 a))
(newline))))
;;; eof
klohm...@yahoo.de
>
btw: I should add I have a very clever colleague who is doing similar
things than me (climate models, satellite observations, inversion) but
he is using Python. I have no idea why he survives with Python. Every
day he wants me to start using Python.
klohm...@yahoo.de
> Dracula wrote:
Thanks (I will hopefully find some more time to test your code the
weekend after this weekend; sorry we are pushing a paper right now).
Btw: I cannot remember the details but I had to use Bigloo its native
facility to read the file first into a string using ordinary ports was
way to slow. If memory serves me right reading in a double precision
7x7x65000 took 17seconds on my 2MHz Mac Book but using 'mmap' took
only 0.9seconds. Honestly Bigloo does not come fast upfront, however,
making and truning it decently fast is often straightforward. Thanks,
anyway
William D Clinger
> If memory serves me right reading in a double precision
> 7x7x65000 took 17seconds on my 2MHz Mac Book but using 'mmap' took
> only 0.9seconds.
On my 2.4GHz machine, that takes less than half a
second in PLT Scheme, and about four seconds in
Larceny v0.963.
If your recollection is correct, then highly bummed
Bigloo-specific code is slower than portable R6RS
code in PLT Scheme.
Of course, that conclusion applies only to the
computation that most concerned you. Bigloo might
have an edge for some other kinds of computations.
Will
Marek Kubica
The numbers I chose were pretty random. Might be faster or might be
slower.
regards,
Marek
Marek Kubica
klohm...@yahoo.de wrote:
> I have no idea why he survives with Python. Every
> day he wants me to start using Python.
So it is obviously not that painful as you might imagine?
regards,
Marek
Sam TH
> Sam TH wrote:
> > I'm not sure what you believe the import of this to be. Do you
> > believe that the REPL provided by DrScheme's module language for R6RS
> > programs is in violation of the R6RS?
>
> It would be a violation of the R6RS only if PLT Scheme
> were to claim that the REPL implements R6RS. Presumably
> PLT Scheme makes no such claim, and you are the only
> person who is trying to give any such impression.
I have not tried to give any such impression. What I have pointed out
is that PLT Scheme support the R6RS, and provides a REPL, without
violating the terms of the R6RS by providing said REPL. This is what
you claimed Section 5.5 of the R6RS prohibited.
> > If not, how is this not an implementation of R6RS with a REPL?
>
> PLT Scheme is an implementation of the R6RS that is also
> an implementation of the R5RS and is also an implementation
> of a non-R6RS REPL that someone thinks might be useful to
> R6RS programmers. What you refer to as "the REPL provided
> by DrScheme's module language for R6RS programs" is analogous
> to Larceny's ERR5RS mode; it is not an implementation of the
> R6RS.
Right, it is certainly not an implementation the R6RS, since it's a
REPL. But it's not prohibited by the R6RS.
> > First, I think it's a mistake to conflate the IEEE/ANSI standard with
> > the R5RS, since they specify different languages.
>
> There are about half a dozen minor differences between
> the IEEE/ANSI standard and the R5RS, with no outright
> incompatibilities between the two. Almost all systems
> that have implemented the IEEE/ANSI standard have also
> implemented the R5RS in the same mode, so there is very
> little practical difference between the IEEE/ANSI standard
> and the R5RS.
>
> Compare that situation to the R6RS. At this moment, there
> is at most one implementation (Ypsilon) that conforms to
> the R6RS. The differences between the languages implemented
> by the six R6RS-compatible implementations are considerably
> more significant than the differences between the IEEE/ANSI
> standard and the R5RS.
I'm not intimately familar with the IEEE/ANSI standard, but at a
minimum, it doesn't seem to include multiple value return or macros,
two features that I think of as rather significant the R5RS. Perhaps
I've misread the document, though.
sam th
William D Clinger
> I have not tried to give any such impression. What I have pointed out
> is that PLT Scheme support the R6RS, and provides a REPL, without
> violating the terms of the R6RS by providing said REPL. This is what
> you claimed Section 5.5 of the R6RS prohibited.
R6RS section 5.5 does state absolute requirements that
forbid REPLs. That was not a typo.
I agree with you that R6RS section 5.5 is not binding
on implementations that do not implement the R6RS.
Since PLT Scheme's various REPLs do not implement the
R6RS, those REPLs do not violate the R6RS...
...unless, of course, PLT Scheme actually claims that
one of its REPLs implements the R6RS. Until you can
provide proof that PLT Scheme's documentation actually
claims that one of its REPLs implements the R6RS, I
will not consider that possibility further.
> I'm not intimately familar with the IEEE/ANSI standard, but at a
> minimum, it doesn't seem to include multiple value return or macros,
True.
> two features that I think of as rather significant the R5RS.
I'll grant their significance, but I regard those
differences as minor (for the purpose of what I
thought was our discussion of portability) because
both multiple values and the R5RS macro system are
straightforward to implement in portable IEEE Scheme,
and compatibility files that convert IEEE-conforming
implementations into R5RS-conforming implementations
have been around for a long time. Hence any portable
R5RS program can be run in any IEEE-conforming system
by loading a standard compatibility file first.
Besides, as I said, most implementations of the
IEEE/ANSI standard now implement the R5RS without
even requiring the user to load a compatibility file.
My use of notations like RRRS/R3RS/R4RS/IEEE/ANSI/R5RS
is not meant to imply that all of those documents describe
exactly the same language, and I am sorry you thought
otherwise. For future reference, please note that names
like Fortran, Scheme, Java, and IEEE floating point are
often used with a broader denotation than one specific
version of the relevant standards.
Will
Dimiter "malkia" Stanev
All in all, it's going to bite them later. Ruby is not definitely not
green computing, Ruby is a giant American SUV - wastes too much CPU
power for nothing... Excuse me, but it has to be said...
Now it's okay for your language, runtime, or current build settings to
waste your own, or your colleagues's CPU - it's local, that's okay - but
once deployed largely - if it wastes a lot, then it's a problem.
Sam TH
> Sam TH wrote:
> > I have not tried to give any such impression. What I have pointed out
> > is that PLT Scheme support the R6RS, and provides a REPL, without
> > violating the terms of the R6RS by providing said REPL. This is what
> > you claimed Section 5.5 of the R6RS prohibited.
>
> R6RS section 5.5 does state absolute requirements that
> forbid REPLs. That was not a typo.
>
> I agree with you that R6RS section 5.5 is not binding
> on implementations that do not implement the R6RS.
> Since PLT Scheme's various REPLs do not implement the
> R6RS, those REPLs do not violate the R6RS...
>
> ...unless, of course, PLT Scheme actually claims that
> one of its REPLs implements the R6RS. Until you can
> provide proof that PLT Scheme's documentation actually
> claims that one of its REPLs implements the R6RS, I
> will not consider that possibility further.
Look, the issue here is very simple. Either PLT Scheme implements the
R6RS correctly (modulo the documented exceptions), or it doesn't. If
it does, then REPLs are clearly not prohibited, since PLT Scheme
provides one. If it doesn't, then there must be some portion of the
R6RS that is being violated.
> > I'm not intimately familar with the IEEE/ANSI standard, but at a
> > minimum, it doesn't seem to include multiple value return or macros,
>
> True.
>
> > two features that I think of as rather significant the R5RS.
>
> I'll grant their significance, but I regard those
> differences as minor (for the purpose of what I
> thought was our discussion of portability) because
> both multiple values and the R5RS macro system are
> straightforward to implement in portable IEEE Scheme,
> and compatibility files that convert IEEE-conforming
> implementations into R5RS-conforming implementations
> have been around for a long time. Hence any portable
> R5RS program can be run in any IEEE-conforming system
> by loading a standard compatibility file first.
>
> Besides, as I said, most implementations of the
> IEEE/ANSI standard now implement the R5RS without
> even requiring the user to load a compatibility file.
>
> My use of notations like RRRS/R3RS/R4RS/IEEE/ANSI/R5RS
> is not meant to imply that all of those documents describe
> exactly the same language, and I am sorry you thought
> otherwise. For future reference, please note that names
> like Fortran, Scheme, Java, and IEEE floating point are
> often used with a broader denotation than one specific
> version of the relevant standards.
In general, you seem to be dividing Scheme standards into two groups,
those listed above, and the R6RS, suggesting that the important
distinction among these standards is along that division. I was
objecting to that conflation, which I think obscures more than it
illuminates.
sam th
William D Clinger
> Look, the issue here is very simple. Either PLT Scheme implements the
> R6RS correctly (modulo the documented exceptions), or it doesn't. If
> it does, then REPLs are clearly not prohibited, since PLT Scheme
> provides one. If it doesn't, then there must be some portion of the
> R6RS that is being violated.
I infer that you have been unable to locate anything
within the PLT Scheme documentation that claims one
of their REPLs implements the R6RS.
Nothing in the R6RS forbids PLT Scheme (which is the
name of a system that includes implementations of a
variety of languages) to provide a REPL for, say, the
R5RS language or for some subset of Java. Similarly,
nothing in the R6RS forbids PLT Scheme to provide a
REPL for ERR5RS or for any other language that may
resemble the R6RS in some ways but doesn't claim to
be the R6RS. After all, the R6RS can only impose its
will on implementations of the R6RS.
I have never said otherwise. What I have said is
that the absolute requirements of R6RS section 5.5
forbid REPLs. Which they do.
Those facts are, as you say, very simple.
> In general, you seem to be dividing Scheme standards into two groups,
> those listed above, and the R6RS, suggesting that the important
> distinction among these standards is along that division. I was
> objecting to that conflation, which I think obscures more than it
> illuminates.
The RRRS/R3RS/R4RS/IEEE/ANSI/R5RS documents are indeed
more compatible with each other than with the R6RS.
In particular, each document of that sequence defines
a language that is very nearly a subset of the language
defined by the next document in the series.
I'm sorry you think that fact obscures more than it
illuminates.
Will
Sam TH
> Sam TH wrote:
> > Look, the issue here is very simple. Either PLT Scheme implements the
> > R6RS correctly (modulo the documented exceptions), or it doesn't. If
> > it does, then REPLs are clearly not prohibited, since PLT Scheme
> > provides one. If it doesn't, then there must be some portion of the
> > R6RS that is being violated.
>
> I infer that you have been unable to locate anything
> within the PLT Scheme documentation that claims one
> of their REPLs implements the R6RS.
>
> Nothing in the R6RS forbids PLT Scheme (which is the
> name of a system that includes implementations of a
> variety of languages) to provide a REPL for, say, the
> R5RS language or for some subset of Java. Similarly,
> nothing in the R6RS forbids PLT Scheme to provide a
> REPL for ERR5RS or for any other language that may
> resemble the R6RS in some ways but doesn't claim to
> be the R6RS. After all, the R6RS can only impose its
> will on implementations of the R6RS.
1. If you write a program in PLT Scheme beginning with #!r6rs, that
program is described by the documentation [1] as being run according
to R6RS, with the exception of documented inconsitencies [2] which are
not relevant here.
2. If you run that program in the Module language of DrScheme, you are
presented with a REPL.
We therefore have (a) an implementation of R6RS (b) with a REPL. Now,
that REPL cannot implement the R6RS REPL semantics, since no such
semantics exist. But that REPL is not prohibited.
If your claim is merely that it is impossible to provide an R6RS-
conforming REPL, then that is true, but trivial. It is simlarly
impossible to provide an R6RS-conforming toaster, but the R6RS does
not prohibit toasters.
> I have never said otherwise. What I have said is
> that the absolute requirements of R6RS section 5.5
> forbid REPLs. Which they do.
To take another example, Ikarus provides a REPL. This REPL, again,
cannot support the non-existent R6RS REPL semantics, but does do
something. Is it your position that this REPL is an R6RS conformance
bug? If not, then it is a REPL not prohibited by the R6RS.
> > In general, you seem to be dividing Scheme standards into two groups,
> > those listed above, and the R6RS, suggesting that the important
> > distinction among these standards is along that division. I was
> > objecting to that conflation, which I think obscures more than it
> > illuminates.
>
> The RRRS/R3RS/R4RS/IEEE/ANSI/R5RS documents are indeed
> more compatible with each other than with the R6RS.
> In particular, each document of that sequence defines
> a language that is very nearly a subset of the language
> defined by the next document in the series.
'More compatible with' is a tricky concept. Subset is a more concrete
concept. However, the RRRS is clearly not a syntactic subset of the
R5RS, since #!true is missing. Even avoiding the lexical syntax, R5RS
is not a conservative extension [3] of RRRS since (not (eq? #f
'())).
At this point we're left with subjective judgements about what is
'more compatible' with what else. While it's certainly possible to
have reasonable differing perspectives about which dialect is more
compatible, the language has changed sufficently over the years that I
think trying to divide it into only two groups is a mistake. Scheme
has a complex history, as you know better than almost anyone, and I
don't think we should try to compress that to a single binary division
merely because that's the division that seems most prominent at the
moment.
sam th
Helmut Eller
> I have never said otherwise. What I have said is
> that the absolute requirements of R6RS section 5.5
> forbid REPLs. Which they do.
What is your definition of a REPL?
I naively assumed that the following R6RS program is a also a REPL:
(import (rnrs)
(rnrs eval))
(define (prompt)
(newline)
(display "> "))
(define (repl env)
(prompt)
(let ((form (read)))
(cond ((eof-object? form) form)
(#t
(guard (condition
((error? condition)
(display "error during eval:\n")
(display condition)
(repl env)))
(let ((value (eval form env)))
(write value)
(repl env)))))))
(repl (environment '(rnrs)))
Helmut.
jos...@corporate-world.lisp.de
What does EVAL do in R6RS Scheme?
I've read the spec:
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-17.html#node_chap_16
If I call
(eval '(define x 3)) - is that allowed?
What would then a next call to eval do? Like:
(eval 'x)
Does it return 3?
What is an 'expression'?
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_chap_4 does
not define 'expression'.
So an expression is e in http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-15.html#node_sec_A.2
?
Helmut Eller
>
> What does EVAL do in R6RS Scheme?
Presumably evaluating the first argument, in a manner similar as R5RS's
EVAL would to.
> I've read the spec:
>
> http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-17.html#node_chap_16
>
> If I call
>
> (eval '(define x 3)) - is that allowed?
Depends what you mean by "allowed". The R6RS seems to say that it
should raise a &violation condition. I guess than means that it is not
allowed.
I don't know if R6RS also prohibits a compliant implementation to offer a
implementation-specific way continue the operation anyway. I think a
non-masochistic implementation could just offer a continue restart, just
like most CL implementations offer such a restart when an undefined
variable is encountered.
I don't think that R6RS prohibits the user from catching the condition
and return to the REPL.
> What would then a next call to eval do? Like:
>
> (eval 'x)
>
> Does it return 3?
If the evaluation was aborted this will also raise a condition.
If the implementation continued in a implementation-specific way, then
it depends on the implementation.
>
> What is an 'expression'?
I don't know. I think for EVAL it's the same thing what Lispers usually
call Sexps.
Helmut.
Marco Maggi
"joswig" wrote:
> What does EVAL do in R6RS Scheme?
Using informal, imprecise words: evaluate a form given as
list; the form can "use" bindings from a selection of
libraries (the environment); the form can define "local"
bindings, but cannot add those definitions to the
environment.
>If I call
>
>(eval '(define x 3)) - is that allowed?
No, because an environment argument is mandatory and
"floating" definitions are not allowed. We can have "local"
definitions:
| (eval '(letrec* ()
| (define a 1)
| (+ a 2))
| (environment '(rnrs)))
| => 3
Definitions like:
| (eval '(define a 1) (environment '(rnrs)))
have "nowhere to go", because there is no associative
container (= mutable environment) in which "a=1" can be
stored, saved between evaluations, and accessed later. By
using LETREC* we can "request that container", but only for
a single EVAL shot. R6RS defines the environment argument
to EVAL to be immutable.
If we need to "save the new definitions" we have to
transform the expression-as-datum in a such way that local
local definitions are stored somewhere, and multiple return
values are used to retrieve them. For example:
| (define prog '((define a 1)
| (display a)
| (+ a 2)))
could be transformed to:
| (define prog1 '(letrec* ((a 1))
| (display a)
| (values (+ a 2)
| (list 'a a))))
and then:
| (let-values (((result state)
| (eval prog1 (environment '(rnrs)))))
| ---)
later we can build a new program with state with:
| (list 'letrec* (list state) '(display a))
>What is an 'expression'?
As described in the definition of EVAL:
| "expression" must be a syntactically valid Scheme
| expression represented as a datum value
for the definition of expression:
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-4.html#node_sec_1.2
there is a circular dependency between the concept of
"evaluation" and the concept of "expression", but they have
to start from somewhere (else what does "it means" means?).
--
Marco Maggi
detm...@googlemail.com
> What does EVAL do in R6RS Scheme?
>
> I've read the spec:
>
>
> If I call
>
> (eval '(define x 3)) - is that allowed?
>
> What would then a next call to eval do? Like:
>
> (eval 'x)
>
> Does it return 3?
>
> What is an 'expression'?
>
> http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_chap_4 does
> not define 'expression'.
> So an expression is e in http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-15.html#node_sec_A.2
> ?
Hello Rainer,
you should have a look at 1.2 and 1.4, specifically the following:
"Definitions are not expressions, and cannot appear in all places
where an expression can occur. Moreover, a definition has no value."
Regards,
Christian
William D Clinger
> What is your definition of a REPL?
> I naively assumed that the following R6RS program is a also a REPL:
I have been using variations of the following statements
interchangeably:
* The R6RS forbids REPLs.
* No REPL can implement the R6RS.
* No REPL can implement the R6RS without violating the
absolute requirements of R6RS section 5.5.
* Any implementation that claims to provide a REPL that
implements the R6RS is making a false claim.
Your program is a REPL, but it is clearly not a REPL that
implements the R6RS; in particular, it evaluates only
side-effect-free expressions, not definitions or programs.
If you were to claim that your REPL is an implementation
of the R6RS, then you would be making a false claim as
well as violating several absolute requirements of the
R6RS.
So long as you make no such claim, there's no problem.
It appears that all implementors of the R6RS understand
this point. Although most of them ship a REPL with their
systems, none (to my knowledge) claim that their REPL
actually implements the R6RS, and several of them explicitly
acknowledge that their REPLs do not conform to the R6RS.
Will
Sam TH
disagreements, and for the purposes of not further dragging this out,
it suffices to say the following.
1. As Will correctly points out, an implementation of R6RS top-level
programs that proceeded by reading a single form, and then evaluating
that single form, before proceeding on the next form, would violate
the semantics of the R6RS (at a minimum, the requirements of section
5.5).
2. As I have pointed out, implementations of the R6RS are free to
provide a REPL which allows expressions and definitions entered at
that REPL to interact with R6RS libraries and R6RS top-level
programs. This REPL is not, in itself, an implementation of the R6RS.
I believe that we both agree with both of these statements. The
disagreement in this thread is a lesson in the need to keep the many
possible meanings of the term REPL separate.
sam th
Helmut Eller
> Helmut Eller wrote:
>> What is your definition of a REPL?
>> I naively assumed that the following R6RS program is a also a REPL:
>
> I have been using variations of the following statements
> interchangeably:
>
> * The R6RS forbids REPLs.
> * No REPL can implement the R6RS.
> * No REPL can implement the R6RS without violating the
> absolute requirements of R6RS section 5.5.
> * Any implementation that claims to provide a REPL that
> implements the R6RS is making a false claim.
>
> Your program is a REPL, but it is clearly not a REPL that
> implements the R6RS; in particular, it evaluates only
> side-effect-free expressions, not definitions or programs.
Do you count set! and display as side-effect-free?
> If you were to claim that your REPL is an implementation
> of the R6RS, then you would be making a false claim as
> well as violating several absolute requirements of the
> R6RS.
>
> So long as you make no such claim, there's no problem.
>
> It appears that all implementors of the R6RS understand
> this point. Although most of them ship a REPL with their
> systems, none (to my knowledge) claim that their REPL
> actually implements the R6RS, and several of them explicitly
> acknowledge that their REPLs do not conform to the R6RS.
Hmm.. I guess this just means that strict R6RS doesn't allow REPLs but
it's rather easy to implement a REPL which implements almost the same
language (just ignore section 5.5).
Helmut.
William D Clinger
> Hmm.. I guess this just means that strict R6RS doesn't allow REPLs but
> it's rather easy to implement a REPL which implements almost the same
> language (just ignore section 5.5).
Yes! And that is exactly what most implementations of the
R6RS have done.
In my opinion, this provides evidence that the absolute
requirements of the R6RS should not have been abolute,
and should become less absolute when the R6RS is replaced
by a more reasonable standard.
Will
jos...@corporate-world.lisp.de
...
> | (define prog '((define a 1)
> | (display a)
> | (+ a 2)))
>
> could be transformed to:
>
> | (define prog1 '(letrec* ((a 1))
> | (display a)
> | (values (+ a 2)
> | (list 'a a))))
>
> and then:
>
> | (let-values (((result state)
> | (eval prog1 (environment '(rnrs)))))
> | ---)
>
> later we can build a new program with state with:
>
> | (list 'letrec* (list state) '(display a))
Okay. So EVAL not only takes simple 'source expressions' (something
that usually would be read from text (file, ...)), but it
allows arbitrary data be passed by creating expressions with list
functions. So, I could pass in continuations, closures, records,
vectors?
I could modify those vectors then?
Should it also work for example for continuations/closures/records
that
are returned in a? Can I pass I/O ports back and forth?
Can I pass mutable vectors back and forth?
Say, I have created a closure in evaluation a) and pass that
closure like in your model to evaluation b), can I
modify the binding in evaluation b)? So, I could pass
mutable data between evaluations? Right?
>
> >What is an 'expression'?
>
> As described in the definition of EVAL:
>
> | "expression" must be a syntactically valid Scheme
> | expression represented as a datum value
>
> for the definition of expression:
>
> http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-4.html#node_sec_1.2
>
> there is a circular dependency between the concept of
> "evaluation" and the concept of "expression", but they have
> to start from somewhere (else what does "it means" means?).
Hmmpf.
> --
> Marco Maggi
William D Clinger
> 'More compatible with' is a tricky concept. Subset is a more concrete
> concept. However, the RRRS is clearly not a syntactic subset of the
> R5RS, since #!true is missing. Even avoiding the lexical syntax, R5RS
> is not a conservative extension [3] of RRRS since (not (eq? #f
> '())).
True. Intersection, however, is as concrete as subset.
There are infinitely many programs that lie within the
intersection of the languages specified by the RRRS, R3RS,
R4RS, R5RS, and IEEE/ANSI standards.
For each of those languages, the intersection with R6RS
programs is empty.
That fact is both concrete and objective, with nothing tricky
about it. The changes in the R6RS that account for that fact
are also important, IMO, but that's a subjective judgment so
you're free to disagree.
Will
Marco Maggi
"joswig" wrote:
>Okay. So EVAL not only takes simple 'source expressions'
>(something that usually would be read from text (file,
>...)), but it allows arbitrary data be passed by creating
>expressions with list functions. So, I could pass in
>continuations, closures, records, vectors?
To answer this you can try it with Ypsilon, Ikarus, Larceny
(in order of usefulness of error messages and speed from
download to run-the-program) and see what happens.
I dunno the language enough to give you a precise answer,
but a simple rule is: if you can WRITE it and READ it back,
it will work; else it will not.
AFAIU to have a Scheme interpreter as first class object
(like the one implemented by Tcl with the [interp] command)
requires a lot of work and experience, and probably it
cannot can be done with R6RS's EVAL (sharing closures is a
tough one).
(import (rnrs)
(rnrs eval))
(let ((e (environment '(rnrs)
'(rnrs mutable-strings)))
(charf 'char-upcase))
(let*-values
(((res0 state)
(eval '(letrec* ((num 123)
(vec (vector 1 2 3))
(str (string #\a #\b #\c)))
(write (list num vec str))
(newline)
(set! num (+ 1 num))
(values num
`((num ,num)
(vec (quote ,vec))
(str ,str))))
e))
((res1 state)
(eval `(letrec* ,state
(write (list num vec str))
(newline)
(vector-set! vec 1 (+ 1 (vector-ref vec 1)))
(values vec
`((num ,num)
(vec (quote ,vec))
(str ,str))))
e))
((res2 state)
(eval `(letrec* ,state
(write (list num vec str))
(newline)
(string-set! str 1 (,charf (string-ref str 1)))
(values str
`((num ,num)
(vec (quote ,vec))
(str ,str))))
e)))
(write (list res0 res1 res2))
(newline)))
--
Marco Maggi
Marco Maggi
I have written:
>cannot can be done with R6RS's EVAL
I meant "cannot be done with R6RS's EVAL".
--
Marco Maggi
klohm...@yahoo.de
[William's original code at the end of my lenghty posting]
Thanks William for posting your code I think a lot of people will find
it useful because recipies for reading in binary data are rare for any
programming language. I downloaded PLT not long (frankly: in the
afternoon) ago but honestly I have better things to do than investing
the rest of my life understanding PLT and all the other trillions of
different modes there (why it is considered a beginners implementation
maybe God and Jesus know). I have absolutely no idea how to employ
your posted code.
Doing this:
a.scm has your posted code
==
./mzc a.scm
./mzscheme a.scm
gives the error message:
mcar: expects argument of type <mutable-pair>; given ()
==
However honestly I am not interested in PLT (I am quite sure the error
messages are also not the best there: I want a line number where the
error first appears as what I am used to get it in Bigloo).
Nevertheless I am posting my code (I will simply forget otherwise) for
reading binary files (Fortran files would be easy as well but for the
fact that one has to read in the record identifiers first). I HAVEN't
tested the code with strict f64 vectors yet and it is not the exact
same code you posted. Anyway the following gives an idea of the
benchmark (btw: it is not a benchmark because I still claim PLT would
fail catastrophically on my big data sets which not only does reading
in data but does 3 consecutive days on calculations in a row): The
dimension of the array is 7x7x65769
==
bigloo -Obench bin.scm
time ./a.out
dims 7 7 65769
real 0m1.120s
user 0m0.994s
sys 0m0.118s
==
IT WOULD BE SLIGHTLY faster on my Mac OS X Mac Book (2GHZ, Leopard)
but Mac OS X is a piece of utter crap and junk and paged out 2GB in
the afternoon. So I did not do the binary stuff on a clean purged
memory machine but used a Mac Book with a completely crippled memory
layout.
The following code is ready to use on the latest Bigloo and hopefully
might be a first starting point for others who'd like to get an idea
how one may use Bigloo for reading a binary data file.
All the best, Kasper Hauser
==
(module read-bin)
;;;; helper for array manipulation
(define-inline
(v&::obj x::vector i::int)
(vector-ref x i))
(define-inline
(v!::obj x::vector i::int el::obj)
(vector-set! x i el))
;;
(define-inline
(a&::obj x::vector i::int j::int)
(vector-ref (vector-ref x i) j))
(define-inline
(a!::obj x::vector i::int j::int el::obj)
(vector-set! (vector-ref x i) j el))
;;
(define-inline
(a2&::obj x::vector i::int j::int)
(vector-ref (vector-ref x i) j))
(define-inline
(a2!::obj x::vector i::int j::int el::obj)
(vector-set! (vector-ref x i) j el))
;;
(define-inline
(a3&::obj x::vector i::int j::int z::int)
(vector-ref (vector-ref (vector-ref x i) j) z))
(define-inline
(a3!::obj x::vector i::int j::int z::int el::obj)
(vector-set! (vector-ref (vector-ref x i) j) z el))
(define
(make-array::vector rows cols
#!key (val 0.0))
(let ((mx (make-vector rows val)))
(do ((i 0 (+ 1 i)))
((= i rows))
(let ((row (make-vector cols val)))
(do ((j 0 (+ 1 j)))
((= j cols))
(v! row j val))
(v! mx i row)))
(o==> mx)))
(define
(make-2d-array::vector rows::int cols::int
#!key (val 0.0))
(let ([mx (make-vector rows val)])
(do ((i 0 (+ 1 i)))
((= i rows))
(let ([row (make-vector cols val)])
(do ((j 0 (+ 1 j)))
((= j cols))
(v! row j val))
(v! mx i row)))
(o==> mx)))
(define-inline
(make-3d-array::vector dim1::int dim2::int dim3::int
#!key (val 0.0))
(let ((erg::vector (make-2d-array dim1 dim2 val: val)))
(do ((i 0 (+fx i 1)))
((=fx i dim1))
(do ((j 0 (+fx j 1)))
((=fx j dim2))
(let ((1d-vec::vector (make-vector dim3 val)))
(a2! erg i j 1d-vec))))
erg))
;;;;;;
;;;; helper for converting string to integer
;; no error check whatsoever
;; I COPIED THe following piece of code from srfi-56
(define
(arithmetic-shift a i)
(if (negative? i)
(bit-rsh a i)
(bit-lsh a i)))
(define
(combine-ls bytes)
(let loop ((b bytes) (acc 0))
(if (null? b) acc
(loop (cdr b)
(+fx (arithmetic-shift acc 8)
(car b))))))
(define-inline
(string->uint::int string::bstring endian::obj)
(let ((size::int (string-length string))
(port::obj (open-input-string string)))
(assert (integer? size) (positive? size))
(let loop ((i size) (ls '()))
(if (zero? i)
(begin
(close-input-port port)
; cons reverse here not to confuse with endianess
(combine-ls (if (eq? endian 'swap-bytes)
ls
(reverse ls))))
(begin
(let ((b::byte (read-byte port)))
(if (eof-object? b)
b
(loop (-fx i 1) (cons b ls)))))))))
;;;;; ieee-string to double
;;; this is an undocumented Bigloo native function
(define-inline
(ieee-str->f8::double string::bstring endian::obj)
(if (eq? endian 'swap-bytes)
(ieee-string->double
(list->string (reverse (string->list string))))
(ieee-string->double string)))
;;;;; we are reading a 3D binary array
;;;; we are using Bigloo mmap here
(define
(rc-3d-bin::vector file-name::string endian::obj)
(let* ((buf::mmap (open-mmap f-avk read: #t))
(dim1::int (string->uint (mmap-get-string buf 4) endian))
(dim2::int (string->uint (mmap-get-string buf 4) endian))
(dim3::int (string->uint (mmap-get-string buf 4) endian)))
(print "dims " dim1 " " dim2 " " dim3)
;(exit)
(let ((erg::vector (make-3d-array dim3 dim1 dim2)))
(do ((i 0 (+fx i 1)))
((=fx i dim3)
erg)
(do ((j 0 (+fx j 1)))
((=fx j dim1))
(do ((z 0 (+fx z 1)))
((=fx z dim2))
(let ((val::double (ieee-str->f8 (mmap-get-string buf 8)
endian)))
(a3! erg i j z val))))))))
(define f-avk "/Users/xxx/xxx.bin")
(define (erg-avk) (rc-3d-bin f-avk 'big-endian))
(erg-avk)
==
klohm...@yahoo.de
(define (o==>::obj x::obj) x)
sincerely yours, dr.shiwago
> > ...
>
> read more »
William D Clinger
> I have absolutely no idea how to employ your posted code.
Save it in a file, say a.sps, and correct the two line
wrappings that were inserted by Google Groups when I
posted it. If your binary file of test input is named
test.data, then you can run it like this:
% time plt-r6rs a.sps test.data
real 0m0.668s
user 0m0.461s
sys 0m0.159s
BTW, those timings include compile time.
> (btw: it is not a benchmark because I still claim PLT would
> fail catastrophically on my big data sets which not only does reading
> in data but does 3 consecutive days on calculations in a row)
That's very odd. On the three machines I use to benchmark
various implementations of Scheme, PLT Scheme hasn't been
stressed at all by that kind of workload.
> IT WOULD BE SLIGHTLY faster on my Mac OS X Mac Book (2GHZ, Leopard)
Which means that, if you can figure out how to run my
portable R6RS program on your machine, it should run
about 50% faster than your highly bummed Bigloo-specific
code.
> but Mac OS X is a piece of utter crap and junk and paged out 2GB in
> the afternoon.
I'm sorry you're having such bad luck with your software.
Will
Andrew Reilly
> I am posting my code (I will simply forget otherwise) for reading binary
> files (Fortran files would be easy as well but for the fact that one has
> to read in the record identifiers first). I HAVEN't tested the code with
> strict f64 vectors yet and it is not the exact same code you posted.
> Anyway the following gives an idea of the benchmark
> IT WOULD BE SLIGHTLY faster on my Mac OS X Mac Book (2GHZ, Leopard) but
> Mac OS X is a piece of utter crap and junk and paged out 2GB in the
> afternoon. So I did not do the binary stuff on a clean purged memory
> machine but used a Mac Book with a completely crippled memory layout.
Just out of interest, in what sense do you consider your Mac Book's
memory layout to be crippled? In fact, in what sense are you aware of
its memory layout at all?
> ;;;;; ieee-string to double
> ;;; this is an undocumented Bigloo native function (define-inline
> (ieee-str->f8::double string::bstring endian::obj) (if (eq? endian
> 'swap-bytes)
> (ieee-string->double
> (list->string (reverse (string->list string))))
Ow! You'd want to hope that endian is never 'swap-bytes, or the overhead
of burning cons cells here will probably dwarf most of the rest of the
read process...
> (ieee-string->double string)))
>
>
>
>
> ;;;;; we are reading a 3D binary array ;;;; we are using Bigloo mmap
> here
> (define
> (rc-3d-bin::vector file-name::string endian::obj) (let* ((buf::mmap
> (open-mmap f-avk read: #t))
> (dim1::int (string->uint (mmap-get-string buf 4) endian))
(dim2::int
> (string->uint (mmap-get-string buf 4) endian)) (dim3::int (string-
>uint
> (mmap-get-string buf 4) endian)))
> (print "dims " dim1 " " dim2 " " dim3) ;(exit)
> (let ((erg::vector (make-3d-array dim3 dim1 dim2)))
> (do ((i 0 (+fx i 1)))
> ((=fx i dim3)
> erg)
> (do ((j 0 (+fx j 1)))
> ((=fx j dim1))
> (do ((z 0 (+fx z 1)))
> ((=fx z dim2))
> (let ((val::double (ieee-str->f8 (mmap-get-string buf
8)
> endian)))
> (a3! erg i j z val))))))))
I'm intrigued by this code, too. The usual reason for using mmap is
because you know that you want to access the data out-of-order or
sparsely (at a page level), but you seem to be reading it completely
sequentially, using a read-byte-string abstraction over the top. If that
doesn't wind up running at *exactly* the same speed as the standard
buffered read mechanism, (which will sometimes have the advantage over
mmap of not being constrained to the size of the address space) then
there's something wrong with the standard read mechanism.
So: what was the performance of the standard port byte read mechanism,
before you switched to using mmap?
Cheers,
--
Andrew
klohm...@yahoo.de
> Kasper Hauser (aka Dracula) wrote:
> Save it in a file, say a.sps, and correct the two line
> wrappings that were inserted by Google Groups when I
> posted it. If your binary file of test input is named
> test.data, then you can run it like this:
>
> % time plt-r6rs a.sps test.data
>
> real 0m0.668s
> user 0m0.461s
> sys 0m0.159s
Hi Will:
Have you also tested my Bigloo code against your timing on your
machine? Would be interesting to know. As I said I haven't tested it
on strict f64 vectors. Thanks, Sir Francis Drake
klohm...@yahoo.de
users.org> wrote:
> I'm intrigued by this code, too. The usual reason for using mmap is
> because you know that you want to access the data out-of-order or
> sparsely (at a page level), but you seem to be reading it completely
> sequentially, using a read-byte-string abstraction over the top. If that
> doesn't wind up running at *exactly* the same speed as the standard
> buffered read mechanism, (which will sometimes have the advantage over
> mmap of not being constrained to the size of the address space) then
> there's something wrong with the standard read mechanism.
>
> So: what was the performance of the standard port byte read mechanism,
> before you switched to using mmap?
Good morning:
My recollection is a s follows:
I started out with reading binary data with ordinary ports and some
code from srfi-56. In that case my test file (same as the one I posted
timings for the other day) took around 17 seconds (I think machine
specification could be important since sometimes running the same code
on the same data on a different machine with equal MHz specification
will give different timings): low power (2 GHz, 1 GB main memory),
Power Book, Leopard 10.5.xxx): 17 seconds. Quite slow.
Later on someone posted the tip to use Bigloo its undocumented (ieee-
string->double) function (I have no idea why this and some other
related functions are not in the official Bigloo documentation): This
speeded up a bit to about 12 seconds run time.
However, the biggest boost comes from using mmap. I don't know why
reading in via ordinary file ports went that slow.If you want I can
send you my binary file so you can use my Bigloo code (or Williams) to
experiment for yourself.
However, it could equally well be the case that I got something wrong
with using ports (even the Bigloo dicumentation is not that clear what
is best to use and there is more than one option on reading files in
Bigloo).
Sincerly Yours, Speaker of the Vatican
> --
> Andrew