How I feel about Scheme’s performance. I came across this post written earlier today, How fast is Scheme? Well…. which states: I don’t know much about Scheme […] but it seems that the Scheme compilers produce quite sluggish code, at least looking through the grainy, distorted lens that is the Computer Language Benchmarks Game. That seems to make enough sense to me. For one-off heavily numerical te
Scheme Implementation Choices (last updated September 2008) (what is this?) MIT Scheme Scheme 48 RScheme MzScheme Guile Bigloo Chicken Gambit Gauche Scm version 7.7.90.+ 1.3 0.7.3.4-b3u 360 1.8.1 2.8c 2.5 4.0 beta 20 0.8.8 5e3 null-combination true false false true false false true false true true r5rs-letrec false true false false true true false true false false case-sensitive false false true f
Gaucheの拡張モジュールdyncompをリリースしました。このライブラリを使うと、Gaucheのコードの中でCの関数が定義できるようになります(PerlのInline::Cみたいなモジュールです)。 メリットとして、以下のものがあります。 Schemeのコードの中に埋め込めるのでメンテナンスが簡単 コンパイラとしてTiny C Compilerを使っているのでコンパイル速度も速い Cといってもgauche.cgen.ciseを使ったS式表現なので、C風の構文アレルギーの方でも安心して使える デメリットとしては、以下のものがあります。 現状Linuxでしか動かない*1 読めないヘッダファイルがある(GCCの機能に依存しているものとか) 構文がSchemeに似ているのでコードを書いていると混乱する 以下はマンデルブロ集合の計算でベンチマークをとった結果です (CPUはPentiumM 2.
PLT Scheme の新しいバージョンからリストが immutable になる (set-car! とか append! とかが使えなくなる) ことは随分前にアナウンスされていて知ってはいたんですが、何の対策もしないままリリースを迎えてしまいました (バージョン 4 のアナウンスメント)。 個人的には、連想リストをよく使うので key, value ペアの value を変更するのに set-cdr! は必須だったんです。 とは言え、開発陣の長年の経験から「コンスに対するミューテーションは悪」というテーゼが導かれたわけで、ユーザーとしては大人しく従わなければなりません。 もちろんいくつか対処方法があっての事です。例えば box というコンテナを value の位置に置き、その中にデータを置いて再設定 (set-box!) する、という方法が有力な代替案です。 ただ、box は何となく面倒
Gauche には extended-pair というものがあります。普段使っている分には気づきませんが実は裏で extended-pair はひっそりと活躍をしています。 早速触ってみましょう。以下のようなコードを書いて exp.scm と名付けました。 (define-macro (import-only module . syms) `(begin ,@(map (lambda (sym) `(define ,sym (with-module ,module ,sym))) syms))) (import-only gauche.internal extended-pair? extended-cons pair-attribute-get pair-attribute-set! pair-attributes) (let1 p '(1 2 3 4) (write p) (print
Eli Barzilayが投稿したPLT Scheme v4.0の和訳です。今回のメジャーバージョンアップの変更点まとめです。 PLT Scheme version 4.0を公開しました。こちらからどうぞ。 http://plt-scheme.org/ このメジャーバージョンアップには、version 372からたくさんの改善があるので、ぜひアップグレードしていただけたらと思います。 PLT Scheme 言語について改善したこと。モジュールの構文の改善、関数のオプショナル引数&キーワード引数のサポート向上、構造体型のより完全な構文、リストの内包表記とイテレートのための新しい構文、より完全で一貫したリスト操作のセット、より完全な文字列操作のセット、より合理的なハッシュテーブル操作。 ドキュメントを、まとめ直し、書き直しました。新しいチュートリアルと概観が用意され、SchemeおよびPLT
Ypsilon Scheme System, the implementation of R6RS Scheme for real-time applications is now available at:http://code.google.com/p/ypsilon/ Version 0.9.5 beta release: * It implements mostly concurrent mark & sweep garbage collector to achieve minimal gc pause time and best performance on multi-core CPU. * Runs as a stand-alone interpreter on Linux(x86), Mac OS X(x86), Windows Vista(x86). * Backtrac
R6RSは実用的な仕様がたくさん入っていて良いのですが getenv がなくて CGI プログラムが書けません。と文句を言うだけではもったいないのでSRFI(Scheme Requests for Implementation)に仕様を提案しようと決意。 shiroさんにアドバイス頂き 既存の実装を調査(Scheme/getenv/調査) セマンティクスは Java を参考に 書いてみました。 いやあ難しい。ダメ出しつっこみをよろしくお願いします。 title Gets the value of the specified environment variable. author Taro Minowa(Higepon) Abstract This SRFI specifies the procedure getenv, gets the value of the specified en
木構造が与えられる。 := ( ...) という構造。 これから、子→親の対応を表すalistを作る手続きを書け、というもの。 http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3a%e3%83%aa%e3%82%b9%e3%83%88%e5%87%a6%e7%90%86#H-ne4pu7 この問題をやってみた (use util.match) (define *tree* '(Root (Spine (Neck (Head)) (RClavicle (RUpperArm (RLowerArm (RHand)))) (LClavicle (LUpperArm (LLowerArm (LHand))))) (RHip (RUpperLeg (RLowerLeg (RFoot)))) (LHip (LUpperLeg (LLowerLeg
Peter Norvig 氏の Solving Every Sudoku Puzzle というエッセイで、数独の解き方が Python を使って示されています。 ちょうど SRFI-42 (eager comprehension) というライブラリを使ってみたいなと思っていたところに見つけたので、ジェネレータ式というものが多用されているこの Python コードは恰好の題材でした。 ということで、原文の流れに沿いながら Scheme に訳していきたいと思います。 まず用語を紹介しておきます。 9x9マスの縦の列を column、横の列(行)を row と言うのは自明と思いますが、3x3 のまとまりは block、そして各マスを square と呼んでいます。 さらに、row、column、block それぞれ9マスずつのまとまりを unit、1つの square が所属する unit 内の
posted by Matthew Flatt PLT Scheme is now 13 years old. The initial version was little more than glue code between a few open-source libraries, which seemed to offer the quickest solution to our modest goals. Modest success leads to bigger goals, however, and then continued success leads to ever more ambitious goals. Before you know it, a mass of users, co-developers, libraries, and documentation
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く