Re: Scheme as a virtual machine?
Keith H Duggar wrote: > 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). Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
"Jon Harrop" wrote: > "Ertugrul Söylemez" wrote in message > news:20101014052650.510e8...@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. 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 Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
namekuseijin wrote:
> On 14 out, 00:26, Ertugrul Söylemez 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
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
namekuseijin wrote:
> On 13 out, 21:01, Ertugrul Söylemez wrote:
> > 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.
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.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
namekuseijin wrote: > 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: toy list processing problem: collect similar terms
Ertugrul Söylemez wrote: > In Haskell the solution looks like this: > > [...] And before anyone starts to rant, I didn't pay attention to where I'm X-posting this stuff. Sorry for that. But on the other hand you could say that I'm giving the Perl people (apparently the only people feeling the urge to rant anyway) the chance to come up with a more elegant solution. =) Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: toy list processing problem: collect similar terms
Xah Lee wrote: > here's a interesting toy list processing problem. > > I have a list of lists, where each sublist is labelled by a number. I > need to collect together the contents of all sublists sharing the same > label. So if I have the list > > ((0 a b) (1 c d) (2 e f) (3 g h) (1 i j) (2 k l) (4 m n) (2 o p) (4 q > r) (5 s t)) > > where the first element of each sublist is the label, I need to > produce: > > output: > ((a b) (c d i j) (e f k l o p) (g h) (m n q r) (s t)) > > [...] > > anyone care to give a solution in Python, Perl, javascript, or other > lang? am guessing the scheme solution can be much improved... perhaps > using some lib but that seems to show scheme is pretty weak if the lib > is non-standard. In Haskell the solution looks like this: import qualified Data.Map as M import qualified Data.Set as S import Data.Map (Map) import Data.Set (Set) collect :: (Ord a, Ord k) => [Map k (Set a)] -> Map k (Set a) collect = M.unionsWith S.union Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ -- http://mail.python.org/mailman/listinfo/python-list
Experiment: Church lists in Python
Hello there Pythoners, It was almost a week ago, when I got bored and thought, Python is quite a boring language, so I'd need to do some evil functional programming again. I thought, I'd share the result. ;) This time, I added a Church style representation for lists [1] to Python. The problem they solve: What do you do, if you've got only scalar values, functions and function application, but you need lists? Here is the solution: Represent lists as higher order functions: def empty(): return lambda f, z: z def cons(x, xs): return lambda f, z: f(x, xs(f, z)) def fold(f, z, xs): return xs(f, z) The empty() function returns an empty list and the cons() function returns the list in its second argument with the element in its first argument prepended, so cons(x, xs) is equivalent to the list [x] + xs. The 'fold' function is actually superfluous, but it makes much clearer what you're doing, when using this type of lists. It's the right-associative version of the 'reduce' function. All other list operations can be defined in terms of these three functions. I've done that for you [2] (mostly). If Python implements closures efficiently, this list representation is actually very fast for list folding, i.e. consuming an entire list to construct a value (which may be anything, including lists or functions). However, it's slow for extracting individual elements, because this operation must be a fold, too, as folding is the only way to access the elements of a list. An interesting property of this representation is that it gets along without any impure functions, i.e. all functions are completely free of side effects. Unless you use an impure fold function, everything is perfectly purely functional. Have fun. =) Greets, Ertugrul. [1] http://en.wikipedia.org/wiki/Church_encoding#Higher-order-function, a representation of a list as a higher order function. [2] http://ertes.de/python/fun/chlists.py, a little library of Python functions implementing Church style lists using higher order functions. The way the 'range' function is defined, was an experiment: how to emulate partial application in Python. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ -- http://mail.python.org/mailman/listinfo/python-list
