Scheme as a virtual machine?
Oleg Parashchenko
I'd like to try the idea that Scheme can be considered as a new
portable assembler. We could code something in Scheme and then compile
it to PHP or Python or Java or whatever.
Any suggestions and pointers to existing and related work are welcome.
Thanks!
My current approach is to take an existing Scheme implementation and
hijack into its backend. At this moment Scheme code is converted to
some representation with a minimal set of bytecodes, and it should be
quite easy to compile this representation to a target language. After
some research, the main candidates are Gambit, Chicken and CPSCM:
http://uucode.com/blog/2010/09/28/r5rs-scheme-as-a-virtual-machine-i/
http://uucode.com/blog/2010/09/28/r5rs-scheme-as-a-virtual-machine-ii/
If there is an interest in this work, I could publish progress
reports.
--
Oleg Parashchenko olpa@ http://uucode.com/
http://uucode.com/blog/ XML, TeX, Python, Mac, Chess
realazthat
> Hello,
>
> I'd like to try the idea that Scheme can be considered as a new
> portable assembler. We could code something in Scheme and then compile
> it to PHP or Python or Java or whatever.
>
> Any suggestions and pointers to existing and related work are welcome.
> Thanks!
>
> My current approach is to take an existing Scheme implementation and
> hijack into its backend. At this moment Scheme code is converted to
> some representation with a minimal set of bytecodes, and it should be
> quite easy to compile this representation to a target language. After
> some research, the main candidates are Gambit, Chicken and CPSCM:
>
>
> If there is an interest in this work, I could publish progress
> reports.
>
> --
I've been approaching a similar problem and have been doing research
in the past few days.
http://realazthat.wikkii.com/wiki/MathML2X
http://realazthat.wikkii.com/wiki/HLML
pjotr
What you probably want is to increase portability. For this, I think
you should look at Bigloo, which includes 5 back-ends already
(bytecode, C, JVM, .NET and Javascript), besides the interpreter. I
have had a few successful encounters with multi-backend library
creation using Bigloo: cross-compiling the same Scheme library into
native, JVM and .NET versions, also using external C/Java libraries.
Larceny is another candidate targeting native x86 and .NET. There are
other compilers too (e.g., Ikarus).
I think the major obstacle shall be Scheme's lack of static typing
(and hence - lack of certifiable machine translation). Although Bigloo
has some support for static typing (for unboxed vectors etc.), it is
not standard Scheme. Also, it does no type-inference, which is
probably not a problem if you want to use it as an assembler language
and include type annotations everywhere.
I have also been thinking about Scheme as an assembler language, but
then from the higher-level language perspective: why reinvent the low-
level virtual machines with garbage collection, data-representation
etc. for each implementation of the major FP languages (*ML, Haskell),
goal-directed (e.g., Icon) and logic languages (e.g., Prolog) while
one could just define one such low-level virtual machine (i.e., a
Scheme system) and then provide multitude of front-end translations
from all those languages to Scheme (the assembler language). Then
everyone can use each other's modules (without falling back to C) and
still use his/her own favourite FP/Logic language to the heart's
content.
In fact, there already are several such front-ends: Yale Haskell
(requires some grave-digging), Camloo (being revived at INRIA as we
speak) and Kanren provides low-level support for logic programming in
Scheme.
Furthermore, sharing a common base of middle-end transformations,
optimizations and language infrastructure (e.g., debugging) shall
serve to improve the overall quality of FP/Logic language
implementations and provide a better basis for comparisons, benchmarks
and possibly wider acceptance.
In this sense, I am very much interested in reducing the complexity of
the total solution from N*M*K (N front-ends, M back-ends and K middle-
ends) to N+M+K. The difference in effort is better spent in improving
each individual front-, middle- and back-end, I think...
namekuseijin
> Hello,
>
> I'd like to try the idea that Scheme can be considered as a new
> portable assembler. We could code something in Scheme and then compile
> it to PHP or Python or Java or whatever.
>
> Any suggestions and pointers to existing and related work are welcome.
> Thanks!
>
> My current approach is to take an existing Scheme implementation and
> hijack into its backend. At this moment Scheme code is converted to
> some representation with a minimal set of bytecodes, and it should be
> quite easy to compile this representation to a target language. After
> some research, the main candidates are Gambit, Chicken and CPSCM:
>
>
> If there is an interest in this work, I could publish progress
> reports.
>
> --
it may be assembler, too bad scheme libs are scattered around written
in far too many different flavors of assembler...
It warms my heart though to realize that Scheme's usual small size and
footprint has allowed for many quality implementations targetting many
different backends, be it x86 assembly, C, javascript or .NET. Take
python and you have a slow c bytecode interpreter and a slow
bytecode .NET compiler. Take haskell and its so friggin' huge and
complex that its got its very own scary monolithic gcc. When you
think of it, Scheme is the one true high-level language with many
quality perfomant backends -- CL has a few scary compilers for native
code, but not one to java, .NET or javascript that I know of...
Pascal J. Bourguignon
Yep, it only has two for java.
> .NET or javascript that I know of...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Ertugrul Söylemez
> Take haskell and its so friggin' huge and complex that its got its
> very own scary monolithic gcc. When you think of it, Scheme is the
> one true high-level language with many quality perfomant backends --
> CL has a few scary compilers for native code, but not one to java,
> .NET or javascript that I know of...
What exactly is "friggin' huge" and "complex" about Haskell, and what's
this stuff about a "very own monolithic gcc"? Haskell isn't a lot more
complex than Scheme. In fact, Python is much more complex. Reduced to
bare metal (i.e. leaving out syntactic sugar) Haskell is one of the
simplest languages. Since recent versions of GHC produced code is also
very small.
The only downside of Haskell is that the popular VMs like JVM and .NET
are not supported. But that's also because their type systems are very
incompatible. Haskell can express types, which they can't express. The
only thing I could imagine to bring the worlds together is another
foreign function interface, a JFFI and a VESFFI.
In my opinion Scheme is not the "one true high-level language". For me
personally Haskell gets much closer to this. For others it's probably
Common Lisp or something else.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
namekuseijin
> What exactly is "friggin' huge" and "complex" about Haskell, and what's
> this stuff about a "very own monolithic gcc"? Haskell isn't a lot more
> complex than Scheme. In fact, Python is much more complex. Reduced to
> bare metal (i.e. leaving out syntactic sugar) Haskell is one of the
> simplest languages.
yeah, like scheme, it's essentially evaluation of lambda expressions.
Unlike scheme, it's got a huge plethora of syntatic sugar as big and
complex as a full numeric tower. Such is the fear to avoid
parentheses at all costs that they allowed lots of perlisms into the
language ($ . `` >>= etc) plus python's significant whitespace. So,
in practice, even though at the core it's as simple as scheme's core,
at practice it's so mindnumbing complex that only one implementation
is worth of note. And one as complex and scary beast as gcc... that's
the cost of a very irregular syntax...
namekuseijin
wrote:
> namekuseijin <namekusei...@gmail.com> writes:
> > On 11 out, 08:49, Oleg Parashchenko <ole...@gmail.com> wrote:
> >> Hello,
>
> >> I'd like to try the idea that Scheme can be considered as a new
> >> portable assembler. We could code something in Scheme and then compile
> >> it to PHP or Python or Java or whatever.
>
> >> Any suggestions and pointers to existing and related work are welcome.
> >> Thanks!
>
> >> My current approach is to take an existing Scheme implementation and
> >> hijack into its backend. At this moment Scheme code is converted to
> >> some representation with a minimal set of bytecodes, and it should be
> >> quite easy to compile this representation to a target language. After
> >> some research, the main candidates are Gambit, Chicken and CPSCM:
>
>
> >> If there is an interest in this work, I could publish progress
> >> reports.
>
> >> --
> >> Oleg Parashchenko olpa@http://uucode.com/http://uucode.com/blog/ XML, TeX, Python, Mac, Chess
>
> > it may be assembler, too bad scheme libs are scattered around written
> > in far too many different flavors of assembler...
>
> > It warms my heart though to realize that Scheme's usual small size and
> > footprint has allowed for many quality implementations targetting many
> > different backends, be it x86 assembly, C, javascript or .NET. Take
> > python and you have a slow c bytecode interpreter and a slow
> > bytecode .NET compiler. Take haskell and its so friggin' huge and
> > complex that its got its very own scary monolithic gcc. When you
> > think of it, Scheme is the one true high-level language with many
> > quality perfomant backends -- CL has a few scary compilers for native
> > code, but not one to java,
>
> Yep, it only has two for java.
I hope those are not Clojure and Qi... :p
Ertugrul Söylemez
That's nonsense. There is only little syntactic sugar in Haskell. And
all of them make your life considerably easier. You get multiple
function clauses instead of an explicit 'case', which makes your
functions much more readable. You get 'do'-notation for monads, which
makes (many) monadic computations much easier to read. And you get
support for infix functions with a very clean syntax. That's about all
the syntactic features you use in general.
BTW, you mentioned symbols ('$', '.' and '>>='), which are not syntactic
sugar at all. They are just normal functions, for which it makes sense
to be infix. The fact that you sold them as syntactic sugar or
"perlisms" proves that you have no idea about the language, so stop
crying. Also Python-style significant whitespace is strictly optional.
It's nice though. After all most Haskell programmers prefer it.
Further Scheme lacks these:
* A powerful type system,
* lazy evaluation,
* non-strict semantics,
* easy, straightforward to use concurrency,
* easy, straightforward to use parallelism and
* much more.
I'm not saying Scheme is a bad language (I recommend it to beginners),
but it doesn't beat Haskell in any way, at least for me, and in contrast
to you I /can/ make a comparison, because I have used both productively.
> And one as complex and scary beast as gcc... that's the cost of a very
> irregular syntax...
What also proves that you have no idea is the fact that there is no
Haskell compiler called 'gcc'. That's the GNU C compiler. There is the
Glasgow Haskell Compiler, GHC, and it's by far not the only one. It's
just the one most people use, and there is such a compiler for all
languages. Many Schemers use Racket, for example.
You never used Haskell seriously, so stop complaining.
Oleg Parashchenko
thanks for the comments.
On 13 Okt., 11:02, pjotr <peter.kourza...@gmail.com> wrote:
> Oleg,
>
> What you probably want is to increase portability.
Yes, and my list includes PHP and Python.
> For this, I think
> you should look at Bigloo, which includes 5 back-ends already
> (bytecode, C, JVM, .NET and Javascript), besides the interpreter.
Bigloo now supports JavaScript? Great news, I'd like to see it, but I
can't find a link on the official site.
The big problems with Bigloo are:
1) Just like with many others Schemes (except Chicken and Gambit),
there is no documentation how to implement own backend.
2) This statement makes my worried:
"""
The JVM back-end supports the entire Bigloo source language but the
call/cc function. More precisely, using the JVM back-end, the
continuation reified in a call/cc form can only be invoked in the
dynamic extent of that form.
The other restrictions of the C back-end apply to the JVM back-end.
Mainly,
* Bigloo is not able to compile all the tail recursive call
without stack consumption (however, most of the tail recursive calls
are optimized by Bigloo and don't use stack activation frames).
...
"""
> I
> have had a few successful encounters with multi-backend library
> creation using Bigloo: cross-compiling the same Scheme library into
> native, JVM and .NET versions, also using external C/Java libraries.
That's very interesting. Are the any (blog) notes about it, with
examples?
...
Pascal J. Bourguignon
pjotr
But so can Scheme or MLs, (possibly, for other applications). As I
understand it, there is no conclusion to static vs. dynamic typing and
strict vs. lazy debate. You have these options in all of functional
languages (there is Typed and Lazy Scheme as well as a way to program
Untyped Lazy ML or Untyped Strict Haskell).
But it does get irritating when you start looking at some particular
language through a book or a lecture, where someone advocates lazy
evaluation (or static typing for that matter) as a solution to all the
world's problems and then comes with a nasty and ugly looking stuff
like this:
http://haskell.org/haskellwiki/Foldr_Foldl_Foldl%27.
Also read: http://users.aber.ac.uk/afc/stricthaskell.html.
Some quotes from http://haskell.org/haskellwiki/Stack_overflow:
"When should foldl be used? The pragmatic answer is: by and far, it
shouldn't be used... However, I can't think of a really convincing
example. In most cases, foldl' is what you want. "
and from http://haskell.org/haskellwiki/Performance/Strictness:
"then consider instead writing do … … return $! fn x; it is very rare
to actually need laziness in the argument of return here."
BTW, I don't know how many Haskell programmers actually use these
annotations... But I do think that foldl is the most widely-used fold.
To summarise: which notation do you prefer: "!" and "seq"/"$!"/"$!!"
everywhere, or (delay) and (force) wherever you do really need it?
namekuseijin
> BTW, you mentioned symbols ('$', '.' and '>>='), which are not syntactic
> sugar at all. They are just normal functions, for which it makes sense
> to be infix. The fact that you sold them as syntactic sugar or
> "perlisms" proves that you have no idea about the language, so stop
> crying. Also Python-style significant whitespace is strictly optional.
> It's nice though. After all most Haskell programmers prefer it.
it still makes haskell code scattered with perlisms, be it syntax or
function name... in practice, Haskell code is ridden with such
perlisms and significant whitespace, and infix function application
and more special cases. All of these contribute to a harder to parse
language and to less compilers for it.
> > And one as complex and scary beast as gcc... that's the cost of a very
> > irregular syntax...
>
> What also proves that you have no idea is the fact that there is no
> Haskell compiler called 'gcc'. That's the GNU C compiler.
ORLY?
do you understand what a comparison is?
> Glasgow Haskell Compiler, GHC, and it's by far not the only one. It's
> just the one most people use, and there is such a compiler for all
> languages.
yeah, there's also some Yale Haskell compiler in some graveyard, last
time I heard...
Nate
> I'd like to try the idea that Scheme can be considered as a new
> portable assembler. We could code something in Scheme and then compile
> it to PHP or Python or Java or whatever.
> some research, the main candidates are Gambit, Chicken and CPSCM:
That exactly parallels something I've wanted to do in scheme for a
long time! The CPSCM project is pretty small, portable (with minimal
work) & easy to grok. Unfortunately, it appears completely dormant
right now ... Dan Muresan never responded to a request I sent him to
join the project in google code about two years ago.
regards,
NT
pjotr
> Bigloo now supports JavaScript? Great news, I'd like to see it, but I
> can't find a link on the official site.
>
That's because this support is part of Hop (currently, the main Bigloo
application from my understanding): http://hop.inria.fr/#home-notepad=np:5
They have written some papers about it.
> The big problems with Bigloo are:
>
> 1) Just like with many others Schemes (except Chicken and Gambit),
> there is no documentation how to implement own backend.
I think this applies to many FP languages. Even GCC is struggling
there... But again, I haven't tried writing my own backend myself so I
can not say how easy/difficult it is. I am actually more interested in
front-ends /to/ Scheme rather than back-ends /from/ Scheme.
> 2) This statement makes my worried:
>
> """
> The JVM back-end supports the entire Bigloo source language but
> ...
Yes, there are some limitations. From what I understood these have to
do with efficiency - there apparently is no easy way to copy parts of
the JVM native stack, maybe due to security reasons. But on the other
hand, you plan to generate PHP and Python (not their respective
bytecodes), so you can just implement your own stack, since you
already loose so much efficiency by targeting a higher-level
language.
So, maybe you should consider reversing your task and write a PHP or
Python front-end;-) This shall also give you portability, albeit of a
different kind. I am personally more interested in Icon/Unicon
front-end, but currently have some other obligations...
> > I
> > have had a few successful encounters with multi-backend library
> > creation using Bigloo: cross-compiling the same Scheme library into
> > native, JVM and .NET versions, also using external C/Java libraries.
>
> That's very interesting. Are the any (blog) notes about it, with
> examples?
>
Not really... However, you can try it yourself. I know SSAX-SXML
library is very popular, so I took the version for Bigloo from SF and
upgraded it with JVM and .NET support. You can get it from:
http://sub-lime.sourceforge.net/cgi-bin/hgwebdir.cgi/home/groupsust /s/
su/sub-lime/repos/ssax-sxml/
Just say make (after setting your Bigloo version in Makefile). For
JVM/.NET comment out all lazy parts of example.scm.
> ...
>
> --
> Oleg Parashchenko olpa@http://uucode.com/http://uucode.com/blog/ XML, TeX, Python, Mac, Chess
Oleg Parashchenko
On 14 Okt., 20:31, Nate <nth...@gmail.com> wrote:
> On Oct 11, 6:49 am, Oleg Parashchenko <ole...@gmail.com> wrote:
>
> > I'd like to try the idea that Scheme can be considered as a new
> > portable assembler. We could code something in Scheme and then compile
> > it to PHP or Python or Java or whatever.
> > After
> > some research, the main candidates are Gambit, Chicken and CPSCM:
>
> That exactly parallels something I've wanted to do in scheme for a
> long time! The CPSCM project is pretty small, portable (with minimal
> work) & easy to grok.
Yes, I've found CPSCM a very good starting point and right now I'm
playing with it.
Meanwhile, I realized that the project could be logically split on 3
parts:
* Compiling to some internal form
* Compiling from the internal form to a backend
* Runtime support for a backend
With this approach, I can re-use the part 3 from CPSCM, but implement
parts 1 and 2 for Gambit or Chicken. It would be interesting to look
at these hybrids and compare theirs characteristics.
> Unfortunately, it appears completely dormant
> right now ... Dan Muresan never responded to a request I sent him to
> join the project in google code about two years ago.
Recently I became interested in git thanks to an article about
github.com. One of the killer feature was an incentive to make forks
and return new work back without administrative overhead. I tried it,
and github helped to steel the whole CPSCM repository, including log
history:
>
> regards,
> NT
Ertugrul Söylemez
> On 14 out, 00:26, Ertugrul Söylemez <e...@ertes.de> wrote:
> > BTW, you mentioned symbols ('$', '.' and '>>='), which are not
> > syntactic sugar at all. They are just normal functions, for which
> > it makes sense to be infix. The fact that you sold them as
> > syntactic sugar or "perlisms" proves that you have no idea about the
> > language, so stop crying. Also Python-style significant whitespace
> > is strictly optional. It's nice though. After all most Haskell
> > programmers prefer it.
>
> it still makes haskell code scattered with perlisms, be it syntax or
> function name... in practice, Haskell code is ridden with such
> perlisms and significant whitespace, and infix function application
> and more special cases. All of these contribute to a harder to parse
> language [...]
So what? The quality of a language isn't measured by the difficulty to
parse it. Haskell has certainly more syntactic special cases than
Scheme, but I don't care, because they are /useful/.
> [...] and to less compilers for it.
That's an arbitrary and wrong statement. The reason why there aren't
many Haskell compilers is that Haskell needs a good run-time system and
a lot of algorithms, which you wouldn't need in languages like Scheme
(including typed Scheme), which have a comparably simple type system.
Also you have to deal with laziness, and ideally you would want to write
a smart optimizer. This is easier for other languages.
But what's the matter? GHC is BSD-licensed. Derive your project from
it, if you are, for some reason, not happy with it.
> > > And one as complex and scary beast as gcc... that's the cost of a
> > > very irregular syntax...
> >
> > What also proves that you have no idea is the fact that there is no
> > Haskell compiler called 'gcc'. That's the GNU C compiler.
>
> ORLY?
>
> do you understand what a comparison is?
Sure, sure. I'd probably say that, too, in your situation. ;)
> > Glasgow Haskell Compiler, GHC, and it's by far not the only
> > one. It's just the one most people use, and there is such a
> > compiler for all languages.
>
> yeah, there's also some Yale Haskell compiler in some graveyard, last
> time I heard...
http://haskell.org/haskellwiki/Implementations
Jon Harrop
news:20101014052...@tritium.streitmacht.eu...
> That's nonsense.
Actually namekuseijin is right. You really need to persevere and familiarize
yourself with some of the other languages out there. Haskell is many things
but simple is not one of them. If Haskell were half of the things you think
it is, it would have more credible success stories.
Cheers,
Jon.
Ertugrul Söylemez
Jon, I don't care about your opinion, because it's biased. If you were
to advocate Haskell in any way, you would lose money. So you must fight
it where possible. This makes all your postings about Haskell (and many
other languages) meaningless and reading them a waste of time.
Haskell is a simple language with a comparably small specification.
It's not as simple as Common Lisp, but it's simple. Note that simple
doesn't mean easy. Haskell is certainly more difficult to learn than
other languages, which explains the low number of success stories. On
the other hand, I'm doing rapid web development in it.
After all there aren't many CL success stories either, but Paul Graham's
story [1] speaks for itself.
[1] http://www.paulgraham.com/avg.html
markha...@gmail.com
> "Jon Harrop" <use...@ffconsultancy.com> wrote:
> > "Ertugrul Söylemez" <e...@ertes.de> wrote in message
> >news:20101014052...@tritium.streitmacht.eu...
>
> > > That's nonsense.
>
> > Actually namekuseijin is right. You really need to persevere and
> > familiarize yourself with some of the other languages out
> > there. Haskell is many things but simple is not one of them. If
> > Haskell were half of the things you think it is, it would have more
> > credible success stories.
>
> Jon, I don't care about your opinion, because it's biased.
All opinions are biased.
Raffael Cavallaro
> All opinions are biased.
All opinions show some bias. Not all opinions represent what is usually
called a "conflict of interest." Since JH makes his living selling
tools and training for certain languages, he has a severe conflict of
interest wrt asessing the value of various other languages. If these
other languages are just as good or better than those he makes his
living from, it would be very damaging to his livlihood for him to
admit this fact. As a result, he is a completely unreliable source on
the question.
This is why judges must recuse themselves from both civil and criminal
trials if they have some significant conflict of interest. The law
recognizes that we cannot expect a fair judgement from someone who
stands to profit significantly if the judgement goes one way or the
other. Similarly, we cannot expect a fair judgement on the relative
value of various language tools from a person whose livlihood depends
on the audience choosing only those certain language tools that he
sells services and training for.
warmest regards,
Ralph
--
Raffael Cavallaro
Howard Brazee
wrote:
>Haskell is a simple language with a comparably small specification.
>It's not as simple as Common Lisp, but it's simple. Note that simple
>doesn't mean easy. Haskell is certainly more difficult to learn than
>other languages, which explains the low number of success stories. On
>the other hand, I'm doing rapid web development in it.
I wonder how much that difficulty is innate, and how much is due to
learning other languages first.
I'm an old time CoBOL programmer, and know of quite a few people who
tried to learn OO-CoBOL without much luck. The way to learn it was
to forget it - learn OO with some other language, then come back to it
later. We had to divorce ourselves from the old paradigm first.
--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."
- James Madison
toby
> On Mon, 22 Nov 2010 05:38:53 +0100, Ertugrul S ylemez <e...@ertes.de>
> wrote:
>
> >Haskell is a simple language with a comparably small specification.
> >It's not as simple as Common Lisp, but it's simple. Note that simple
> >doesn't mean easy. Haskell is certainly more difficult to learn than
> >other languages, which explains the low number of success stories. On
> >the other hand, I'm doing rapid web development in it.
>
> I wonder how much that difficulty is innate, and how much is due to
> learning other languages first.
This is a good (if familiar) observation. Teaching children (or young
people with little exposure to computers) how to program in various
paradigms could produce interesting primary evidence. Pity that this
isn't examined widely and systematically. We could learn something
about how to teach programming and design languages this way, don't
you agree?
The OLPC might do some interesting things in this area but it is still
one set of tools. More interesting might be to compare outcomes across
a range of different tools, paradigms, syntaxes, and teaching
strategies.
scattered
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> On 2010-11-22 08:12:27 -0500, MarkHanif...@gmail.com said:
>
> > All opinions are biased.
>
> All opinions show some bias. Not all opinions represent what is usually
> called a "conflict of interest." Since JH makes his living selling
> tools and training for certain languages, he has a severe conflict of
> interest wrt asessing the value of various other languages. If these
> other languages are just as good or better than those he makes his
> living from, it would be very damaging to his livlihood for him to
> admit this fact. As a result, he is a completely unreliable source on
> the question.
>
And you don't think that Jon Harrop could write a book about Haskell
if he honestly came to think that it were a superior all-aroung
language? The fact that he *didn't* mindlessly reject F# in favor of
O'Caml when F# came out (despite the fact that at the time his company
was deeply (exclusively?) invested in O'Caml and arguably had a vested
interest in having F# fail to gain support) suggests that he is able
to fairly evaluate the merits of other languages. Doubtless he has
biases, but there is no reason to think that they are any greater than
the bias of any programmer who has invested substantial amounts of
time in becoming fluent in a particular language.
> This is why judges must recuse themselves from both civil and criminal
> trials if they have some significant conflict of interest.
But an advocate isn't a judge. Nobody is handing down binding
decisions here - they are just advocating their positions. It would be
better to compare JH to a defense lawyer. You can't reject the
defense's arguments just because the lawyer has a vested interest in
the outcome of the trial.
> the law recognizes that we cannot expect a fair judgement from someone who
Howard Brazee
<to...@telegraphics.com.au> wrote:
>This is a good (if familiar) observation. Teaching children (or young
>people with little exposure to computers) how to program in various
>paradigms could produce interesting primary evidence. Pity that this
>isn't examined widely and systematically. We could learn something
>about how to teach programming and design languages this way, don't
>you agree?
I do.
A study such as that would be more useful than how to teach languages
- it could be useful in teaching other stuff as well.
Tamas K Papp
> On Nov 22, 9:45 am, Raffael Cavallaro
> <raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
>> On 2010-11-22 08:12:27 -0500, MarkHanif...@gmail.com said:
>>
>> > All opinions are biased.
>>
>> All opinions show some bias. Not all opinions represent what is usually
>> called a "conflict of interest." Since JH makes his living selling
>> tools and training for certain languages, he has a severe conflict of
>> interest wrt asessing the value of various other languages. If these
>> other languages are just as good or better than those he makes his
>> living from, it would be very damaging to his livlihood for him to
>> admit this fact. As a result, he is a completely unreliable source on
>> the question.
>>
>>
> And you don't think that Jon Harrop could write a book about Haskell if
> he honestly came to think that it were a superior all-aroung language?
Until he writes one, it is useless to speculate about what he could or
could not do.
There are some pretty good books on Haskell, lots of excellent
resources online, and the online community is very supportive.
Writing a book which adds significant value to that would not be a
trivial undertaking.
Best,
Tamas
namekuseijin
> On Mon, 22 Nov 2010 08:14:40 -0800 (PST), toby
>
> >This is a good (if familiar) observation. Teaching children (or young
> >people with little exposure to computers) how to program in various
> >paradigms could produce interesting primary evidence. Pity that this
> >isn't examined widely and systematically. We could learn something
> >about how to teach programming and design languages this way, don't
> >you agree?
>
> I do.
>
> A study such as that would be more useful than how to teach languages
> - it could be useful in teaching other stuff as well.
yes, pity most children are (used to be) taught Basic first.
Also, with a study like this, it's likely some children would be
taught some lame language and others would be taught some "industrial
strength" language and still others would be taught some esoteric
language. I'm not sure it'd prove as much as we are hoping for -- as
they are all Turing equivalent and the kids would be able to
eventually do the task asked for in any of them -- but I'm sure some
of those children would be mentally hurt for all their life. Poor
pioneers :p
JH, nice to have you back! :)
markha...@gmail.com
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> On 2010-11-22 08:12:27 -0500, MarkHanif...@gmail.com said:
>
> > All opinions are biased.
>
> All opinions show some bias. Not all opinions represent what is usually
> called a "conflict of interest."
>
Maybe, but in the case of regulars on newsgroups like c.l.l, there are
"conflicts of interest" that either don't or don't indirectly have to
do with profiting off the popularity or perception of a particular
programming language.
Harrop is annoying is the same way that "MatzLisp" guy is annoying on
c.l.l.
toby
> On 22 nov, 14:47, Howard Brazee <how...@brazee.net> wrote:
>
> > On Mon, 22 Nov 2010 08:14:40 -0800 (PST), toby
>
> > <t...@telegraphics.com.au> wrote:
> > >This is a good (if familiar) observation. Teaching children (or young
> > >people with little exposure to computers) how to program in various
> > >paradigms could produce interesting primary evidence. Pity that this
> > >isn't examined widely and systematically. We could learn something
> > >about how to teach programming and design languages this way, don't
> > >you agree?
>
> > I do.
>
> > A study such as that would be more useful than how to teach languages
> > - it could be useful in teaching other stuff as well.
>
> yes, pity most children are (used to be) taught Basic first.
>
> Also, with a study like this, it's likely some children would be
> taught some lame language and others would be taught some "industrial
> strength" language and still others would be taught some esoteric
> language.
This is not worse than the status quo, which does exactly that, but
without paying attention to outcomes.
What I am proposing is doing it systematically, with observation. Then
we can learn something.
Raffael Cavallaro
> And you don't think that [JH] could write a book about Haskell
> if he honestly came to think that it were a superior all-aroung
> language?
Until he actually does, he has a financial interest in trash-talking
Haskell. This makes anything he says about Haskell suspect.
> The fact that he *didn't* mindlessly reject [musical note lang] in favor of
> [Irish Ship Of The Desert] when [musical note lang] came out (despite
> the fact that at the time his company
> was deeply (exclusively?) invested in [Irish Ship Of The Desert] and
> arguably had a vested
> interest in having [musical note lang] fail to gain support) suggests
> that he is able
> to fairly evaluate the merits of other languages.
No, it suggests that he saw that supporting the Irish Ship Of The
Desert meant going up against Microsoft, so he jumped to the MS
supported variant of the Donut Dromedary.
You miss the fundamental point; having a financial interest in the
outcome of a debate makes anything that person says an advertisement
for his financial interests, not a fair assessment.
> Doubtless he has
> biases, but there is no reason to think that they are any greater than
> the bias of any programmer who has invested substantial amounts of
> time in becoming fluent in a particular language.
Just the opposite. A person who makes his living by being paid to
program in a language he has developed some expertise in (rather than
selling books on it and training for it) has no financial interest in
seeing others develop expertise in it - they would just represent
competition. By contrast, one who sells training and books for a
language profits directly when others take an interest in that
language. Their financial interests are in fact opposite.
JH profits when people take an interest in languages he sells training
for; a working lisp programmer sees additional *competition* when
someone else develops expertise in common lisp.
> But an advocate isn't a judge. Nobody is handing down binding
> decisions here - they are just advocating their positions.
Now you're arguing our point; JH is an *advocate* with a clear conflict
of interest which prevents him from presenting anything but the most
one sided, and therefore largely useless, assessment. His writing
should be seen as a paid advertisement, not as a fair treatment of
programming languages.
Keith H Duggar
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> On 2010-11-22 11:25:34 -0500, scattered said:
>
> > And you don't think that [JH] could write a book about Haskell
> > if he honestly came to think that it were a superior all-aroung
> > language?
>
> Until he actually does, he has a financial interest in trash-talking
> Haskell. This makes anything he says about Haskell suspect.
>
> > The fact that he *didn't* mindlessly reject [musical note lang] in favor of
> > [Irish Ship Of The Desert] when [musical note lang] came out (despite
> > the fact that at the time his company
> > was deeply (exclusively?) invested in [Irish Ship Of The Desert] and
> > arguably had a vested
> > interest in having [musical note lang] fail to gain support) suggests
> > that he is able
> > to fairly evaluate the merits of other languages.
>
> No, it suggests that he saw that supporting the Irish Ship Of The
> Desert meant going up against Microsoft, so he jumped to the MS
> supported variant of the Donut Dromedary.
>
> You miss the fundamental point; having a financial interest in the
> outcome of a debate makes anything that person says an advertisement
> for his financial interests, not a fair assessment.
There is a well-known name for such illogical reasoning: ad hominem.
When a person poses an /argument/, nothing personal outside of the
/argument/ is relevant. Thus, your claim that "anything that person
says ..." is not only obvious hyperbole it is also illogical.
It is a common refuge of those who cannot support their position
with fact and logic. On more than one occasion Jon Harrop has all
but crushed Ertugrul in this very forum with /source code/; that
is as objective as it gets.
KHD
Raffael Cavallaro
> There is a well-known name for such illogical reasoning: ad hominem.
You don't understand ad hominem:
"The ad hominem is a classic logical fallacy,[2] but it is not always
fallacious. For in some instances, questions of personal conduct,
character, motives, etc., are legitimate and relevant to the issue.[3]"
Source: <http://en.wikipedia.org/wiki/Ad_hominem>
Sometimes the person's conduct and motives *are relevant* to the point
under discussion. Financial conflict of interest is a perfect example
where it *is* legitimate and relevant to explore a person's motives and
conduct outside of the debate.
In this case, JH's conduct outside of the debate (i.e., the fact that
he earns his living by selling tools and training for a particular set
of languages) and his motives (i.e., he is therefore financially
motivated to present these languages in the best possible light and to
trash-talk other languages), render his arguments in the debate
inherently suspect.
Keith H Duggar
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> On 2010-11-23 10:08:12 -0500, Keith H Duggar said:
> > > On 2010-11-22 11:25:34 -0500, scattered said:
> > >
> > > > And you don't think that [JH] could write a book about Haskell
> > > > if he honestly came to think that it were a superior all-aroung
> > > > language?
> > >
> > > Until he actually does, he has a financial interest in trash-talking
> > > Haskell. This makes anything he says about Haskell suspect.
> > >
> > > > The fact that he *didn't* mindlessly reject [musical note lang] in favor of
> > > > [Irish Ship Of The Desert] when [musical note lang] came out (despite
> > > > the fact that at the time his company
> > > > was deeply (exclusively?) invested in [Irish Ship Of The Desert] and
> > > > arguably had a vested
> > > > interest in having [musical note lang] fail to gain support) suggests
> > > > that he is able
> > > > to fairly evaluate the merits of other languages.
> > >
> > > No, it suggests that he saw that supporting the Irish Ship Of The
> > > Desert meant going up against Microsoft, so he jumped to the MS
> > > supported variant of the Donut Dromedary.
> > >
> > > You miss the fundamental point; having a financial interest in the
> > > outcome of a debate makes anything that person says an advertisement
> > > for his financial interests, not a fair assessment.
> >
> > /argument/ is relevant. Thus, your claim that "anything that person
> > says ..." is not only obvious hyperbole it is also illogical.
> >
> > It is a common refuge of those who cannot support their position
> > with fact and logic. On more than one occasion Jon Harrop has all
> > but crushed Ertugrul in this very forum with /source code/; that
> > is as objective as it gets.
>
>
> "The ad hominem is a classic logical fallacy,[2] but it is not always
> fallacious. For in some instances, questions of personal conduct,
> character, motives, etc., are legitimate and relevant to the issue.[3]"
>
> Source: <http://en.wikipedia.org/wiki/Ad_hominem>
>
> Sometimes the person's conduct and motives *are relevant* to the point
> under discussion. Financial conflict of interest is a perfect example
> where it *is* legitimate and relevant to explore a person's motives and
> conduct outside of the debate.
>
> In this case, JH's conduct outside of the debate (i.e., the fact that
> he earns his living by selling tools and training for a particular set
> of languages) and his motives (i.e., he is therefore financially
> motivated to present these languages in the best possible light and to
> trash-talk other languages), render his arguments in the debate
> inherently suspect.
You don't understand the implications of your own words:
"having a financial interest in the outcome of a debate makes
anything that person says an advertisement for his financial
interests, not a fair assessment."
is substantially different from
"render his arguments in the debate inherently suspect."
Do you understand how? Hint, see my comment regarding "hyperbole"
and also consider the relationship between the qualifier "anything"
and universal quantification.
I think if you think a bit more carefully you will come to see how
your original statement was indeed fallacious ad hominem. (And that
specific example remains so regardless of which common approach to
informal logic you take ie whether you choose one that is more or
less sympathetic to ad hominem in general.)
KHD
Ertugrul Söylemez
> It is a common refuge of those who cannot support their position with
> fact and logic. On more than one occasion Jon Harrop has all but
> crushed Ertugrul in this very forum with /source code/; that is as
> objective as it gets.
Since Jon has financial reasons to invest time doing this and I don't,
this is nowhere near "crushing" or "objective". It's simply
meaningless. If someone pays me for writing proof code or coming up
with challenges, then I will, and I assure you, I would give him a hard
time, since I'm an experienced Haskell programmer, who uses it for many
different, practical purposes in the real world outside of academia.
And I stated explicitly many times that (without being paid) I don't
feel like wasting time proving my point to Jon, who would just come up
with new arbitrary arguments and challenges anyway, as he does all the
time. Jon doesn't and cannot acknowledge valid arguments, so it would
be an ongoing, pointless cycle.
After all, he was the only one posing stupid challenges on me at all,
deliberately constructing problems to be easy to solve in his languages.
When I would challenge him, the picture would change, but I think, this
is stupid and infantile enough not to do it. In fact, I've even done it
once and proved my point that way (which, as always, he didn't
acknowledge, but I don't care anymore).
Raffael Cavallaro
> You don't understand the implications of your own words:
>
> "having a financial interest in the outcome of a debate makes
> anything that person says an advertisement for his financial
> interests, not a fair assessment."
>
> is substantially different from
>
> "render his arguments in the debate inherently suspect."
They are substantially the same, your jesuitical nit-picking
notwithstanding; JH is an untrustworthy source on matters relating to
the languages he sells training for.
toby
And furthermore, he has cooties.
--T
Benjamin L. Russell
> To summarise: which notation do you prefer: "!" and "seq"/"$!"/"$!!"
> everywhere, or (delay) and (force) wherever you do really need it?
That would depend on the context. A couple of years ago, I attended a
Shibuya.lisp conference in Shibuya, Tokyo, where Shiro Kawai, the
developer of the Gauche Scheme implementation of R5RS Scheme, mentioned
that succinctness is crucial to maintaining and expanding upon code in
the long run. He added that the details of his own code become
equivalent to those written by a stranger six months after the code has
been written, simply because he writes too much code to remember all the
details, and that he uses certain shortcuts, such as replacing the
keyword "lambda" by the Greek lambda symbol, and making use of SRFI's,
to reduce the length of the overall program so that when a client asks
him to expand upon his own code to add a feature six or more months
after he has written the code, he can decipher his own code more
efficiently. He added that although each change individually may not
reduce the length of the overall program significantly, all such
shortcuts put together can reduce the length significantly.
In this context, in the long run, I would actually prefer such shortcuts
the ones that you have given to the spelled-out equivalents. While more
cryptic at first, they serve to reduce the length of the code, which can
significantly reduce deciphering time if the code needs to be maintained
or expanded upon by the programmer more than six months after it has
been written.
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^
Elena
> On 11 out, 08:49, Oleg Parashchenko <ole...@gmail.com> wrote:
>
>
>
> > Hello,
>
> > I'd like to try the idea that Scheme can be considered as a new
> > portable assembler. We could code something in Scheme and then compile
> > it to PHP or Python or Java or whatever.
>
> > Thanks!
>
> > My current approach is to take an existing Scheme implementation and
> > hijack into its backend. At this moment Scheme code is converted to
> > some representation with a minimal set of bytecodes, and it should be
> > quite easy to compile this representation to a target language. After
> > some research, the main candidates are Gambit, Chicken and CPSCM:
>
>
> > If there is an interest in this work, I could publish progress
> > reports.
>
> > --
> > Oleg Parashchenko olpa@http://uucode.com/http://uucode.com/blog/ XML, TeX, Python, Mac, Chess
>
> it may be assembler, too bad scheme libs are scattered around written
> in far too many different flavors of assembler...
>
> It warms my heart though to realize that Scheme's usual small size and
> footprint has allowed for many quality implementations targetting many
> different backends, be it x86 assembly, C, javascript or .NET. Take
> python and you have a slow c bytecode interpreter and a slow
> bytecode .NET compiler. Take haskell and its so friggin' huge and
> complex that its got its very own scary monolithic gcc. When you
> think of it, Scheme is the one true high-level language with many
> quality perfomant backends -- CL has a few scary compilers for native
> code, but not one to java, .NET or javascript that I know of...
Take R5RS Scheme and you get a language which doesn't allow you to get
things done.
Scheme is as far from Assembly as one language can be. Assembly
exists to get things done, R5RS Scheme does not even allows you load
native libraries of the underlying operating-system, does it? It's
easy to stay small and clean when you don't have to dirty your hands
with such crap as real-world applications development.
Raffael Cavallaro
> And furthermore, he has cooties.
Once again, not all ad hominem arguments are ad hominem fallacies.
Financial conflict of interest is a prime example of a perfectly valid
ad hominem argument.
People who parse patterns but not semantics are apt to fall into the
error of believing that "ad hominem" automatically means "logically
invalid." This is not the case.
namekuseijin
assembly in the sense that it's what other languages could compile
to. Like many are targetting javascript, the de facto assembly of the
web...
In any case, the original poster was advocating the opposite: to code
in Scheme and compile it to more common backends, such as PHP or
javascript... I misunderstood his point. But the flamewars that
followed were far more entertaining anyway... :)
Mario S. Mommer
Raffael Cavallaro <raffaelc...@pas.despam.s.il.vous.plait.mac.com>
writes:
> On 2010-11-24 16:19:49 -0500, toby said:
>
>> And furthermore, he has cooties.
>
> Once again, not all ad hominem arguments are ad hominem
> fallacies. Financial conflict of interest is a prime example of a
> perfectly valid ad hominem argument.
It has limited validity. People are way more complicated than the
simplistic "follow your own selfish egoistic interests to the letter
without taking prisoners" model of human behavior that seems
(unfortunately) so prevalent nowadays.
> People who parse patterns but not semantics are apt to fall into the
> error of believing that "ad hominem" automatically means "logically
> invalid." This is not the case.
In the realm of pure logic, ad hominems are logically invalid,
period. However, if the question cannot be resolved by its own merits,
simple logic has little to say, and you may include additional
information in a sort-of Bayesian fashion.
Saying that a conflict of interest means that nothing this person says
makes any sense at all is in a way an admission that the subject of
discussion is not very amenable to rational argument.
toby
wrote:
> pjotr <peter.kourza...@gmail.com> writes:
> > To summarise: which notation do you prefer: "!" and "seq"/"$!"/"$!!"
> > everywhere, or (delay) and (force) wherever you do really need it?
>
> That would depend on the context. A couple of years ago, I attended a
> Shibuya.lisp conference in Shibuya, Tokyo, where Shiro Kawai, the
> developer of the Gauche Scheme implementation of R5RS Scheme, mentioned
> that succinctness is crucial to maintaining and expanding upon code in
> the long run. He added that the details of his own code become
> equivalent to those written by a stranger six months after the code has
> been written, simply because he writes too much code to remember all the
> details, and that he uses certain shortcuts, such as replacing the
> keyword "lambda" by the Greek lambda symbol, and making use of SRFI's,
> to reduce the length of the overall program so that when a client asks
> him to expand upon his own code to add a feature six or more months
> after he has written the code, he can decipher his own code more
> efficiently. He added that although each change individually may not
> reduce the length of the overall program significantly, all such
> shortcuts put together can reduce the length significantly.
I refer to this as "cognitive load" (because it sounds cool). I'm
constantly grimacing over ways that co-workers and others pad their
code with unnecessary symbols, operations, spacing and punctuation*
with plain disregard for the incremental load imposed upon the reader
by every symbol and divagation. "The guy who might have to read and
understand this later - could be YOU".
Edsger Dijkstra observed that a line of code is a liability, not an
asset. People will argue until the end of time about what syntax or
variable name is personally most readable, though.
> In this context, in the long run, I would actually prefer such shortcuts
> the ones that you have given to the spelled-out equivalents. While more
> cryptic at first, they serve to reduce the length of the code, which can
> significantly reduce deciphering time if the code needs to be maintained
> or expanded upon by the programmer more than six months after it has
> been written.
>
> -- Benjamin L. Russell
--Toby
* - I never do this, of course.
> --
> Benjamin L. Russell / DekuDekuplex at Yahoo dot comhttp://dekudekuplex.wordpress.com/
namekuseijin
> Raffael Cavallaro <raffaelcavall...@pas.despam.s.il.vous.plait.mac.com>
I have to say I'm always amazed how ad hominens can generate quite
strong responses to the point of making a lot of new faces (or mail
accounts) suddenly appear... ;)
Benjamin L. Russell
> I have to say I'm always amazed how ad hominens can generate quite
> strong responses to the point of making a lot of new faces (or mail
> accounts) suddenly appear... ;)
Actually, I had just noticed that aspect as well. Is it just me, or
does anybody else also think it rather curious how some of the new
accounts all seem to share the same style of argument?
Granted, I don't have anything the issue of arguing a point itself.
However, it just seems rather unusual that many of the new faces all
seem to share the same style of reasoning....
When I was a student at my college, one of the students once told me a
secret about how a computer program ran by a professor for a course in
introduction to systems programming checked to ensure that the students
who were submitting homework assignments worked independently: the
program counted the number of occurrences of each type of structure
(for-loop, while-loop, if-then statement,etc.), and compared the counts
for the types of structures among assignments between different
students. The method was so effective that it was able to pinpoint one
program among approximately thirty that was handed in by a student who
had based his assignment on another program for the same assignment two
years earlier, also among approximately thirty.
A style of reasoning is like a fingerprint; it identifies the person
making the argument. Of course, two people could have a very similar
style of argument. However, the odds of this happening are less likely
in a single thread. The odds of this happening are even less likely for
three people in the thread. The odds of this happening are even less
likely for three *new* people in the same thread at the same time....
-- Benjamin L. Russell
Benjamin L. Russell
> When I was a student at my college, one of the students once told me a
> secret about how a computer program ran by a professor for a course in
> introduction to systems programming checked to ensure that the students
> who were submitting homework assignments worked independently: the
> program counted the number of occurrences of each type of structure
> (for-loop, while-loop, if-then statement,etc.), and compared the counts
> for the types of structures among assignments between different
> students.
Minor typo corrections:
1) "computer program ran by" -> "computer program run by"
2) "if-then statement,etc." -> "if-then statement, etc." (missing
period)
Incidentally, regarding the programming assignment, the student who was
caught by the structural similarity checking program reportedly received
an e-mail message from the professor asking to explain the similarity.
He never replied to that message, and subsequently received a grade of 0
for that assignment.
Raffael Cavallaro
> In the realm of pure logic, ad hominems are logically invalid,
> period.
We don't live in the realm of pure logic (whatever that would mean -
pretty sure no human beings exist in the realm of pure logic, so there
is no homo hominis to make an ad hominem argument against in the land
of pure logic...)
Here in the real world, no amount of the rigid application of pure
logic is going to substitute for the very necessary social skill of
inferring the motives of a participant to a debate.
Again, not all ad hominem arguments are ad hominem fallacies. JH has
repeatedly trumpeted the virtues of languages whose adoption by others
brings him financial gain, and repeatedly made pejorative statements
about other languages in newsgroups for these other langauges, in a
clear attempt to drum up clients for his training consultancy.
Pure logic alone won't help you here; the ordinary human social skill
of inferring a person's motives does.
pjotr
on personal preferences of the spectator. I am sure that not everybody
that likes Scheme would approve of the code written by Shiro Kawai.
Not that I don't do such things myself though;-)
So, we probably need a way to get different DSL "views" on the same
source-code (in core Scheme), e.g., lambda-calculus view, lazy Haskell view,
typed ML view etc.