アカウント名:
パスワード:
細かいことを言えば、Linux と Hurd はいずれも GNU libc を使う (ことが多い) ので、似てるのかなあ、と。
どのアプリが動くか、ということは、カーネルとは あまり関係ないような気がします。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
期待はあるのですが・・・ (スコア:1)
見えるのでしょうか。
自分はUnix素人の癖に(しかも「ぱすかりゃー」)
なぜかHurdを使いたくて堪らないという問題人間
なのですが、現状pascalが動くOSというとUnix系
ではLinux系しか無い状況ですので、Linux系の
アプリが動くのか気にはなります。
#最悪プリプロセッサを作る、という手はアリ。
#GNU-Cって関数のネストを許すからほぼ1対1で
#C++pascalは変換可能なはずなんだよな・・・
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
> ではLinux系しか無い状況ですので
そーなんですか?
Free Pascal Compiler
http://www.freepascal.org/
には、Linux, FreeBSD, DOS, Win32, OS/2, BeOS, SunOS (Solaris), QNX and Classic Amigaで動くとありますが。
Re:期待はあるのですが・・・ (スコア:2, 参考になる)
1.0.4からサポートをはじめて1.1で正式対応という話ですから・・・・(今は1.0.6・・・でしたよね?)
ぜんぜん関係ないですが、FreePascalは同名で引数の違う手続(関数)の宣言を許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります。他に選択肢は事実上ないんですが(大笑い)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
まあ、そういうことが出来ないのは、元祖(だよね)Pascalのほうの「落ち度」ですからねえ(^^;
#Delphiしてると、宣言の順序とかinterface節の存在そのものとかにも、結構むかついてきます。
#ああいうガチガチコンパイル系の言語は、Javaみたいに順序依存性を極力廃するのが、いらん気遣いが不要になって楽だと思う。
Re:期待はあるのですが・・・ (スコア:1)
>
>まあ、そういうことが出来ないのは、元祖(だよね)Pascalのほうの「落ち度」ですからねえ(^^;
「落ち度」ですか…
それをいうならシンボル名の長さに制限のあった当時のリンカ等の落ち度(というか限界)だと思うのですが。
過去の技術の限界に配慮しろとは思いませんが、こう簡単に「落ち度」なんて決め付けてしまうと「わかってんのかコイツ」みたいな印象を持ってしまいます。
うじゃうじゃ
Re:期待はあるのですが・・・ (スコア:2, 参考になる)
>みたいな印象を持ってしまいます。
劣った技術は、優れた代替技術が出てくれば、さっさと捨てるが吉でしょう。
つまり、
>許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります
過去はさておき今は、納得しましょう、むしろ積極的に肯定しましょう、と言いたいのです。
それとも逆に引数Overloadの弊害について語りたかったのでしょうか?
それならOKですが、でもそういう雰囲気ではないですよね。
>それをいうならシンボル名の長さに制限のあった当時のリンカ等の落ち度(というか限界)だと思うのですが。
ところでリンカに話を持っていくのは微妙に違うと思いますよ。
コンパイラが、名前のマッピングをすればいいんですから。
たとえば作成された関数に1番から順に通し番号でも振ればいい。
でも、限界といっても、8bit時代でも「いろいろな」長さ限界を持つ幾つか(も)のコンパイラ/リンカが
たしかありましたよね。つまり限界といってもそれはべつに原理的にドコに限界があるというはっきりしたものが
あるわけではなく、「たまたまその実装が」という感じですよね。
ということは少なくとも、一等賞の奴(^^;以外は、もっと良く実装することは可能だったはずなのに、ということになります。
#そんなこと言い出したら、俺だって8bit時代のCにOOPもどきをやらせたかったです。ええ(T_T)
…マッピング? (スコア:1)
でも新しいのが出てきたからと尊敬の念も捨てるのは吉ではありませんよ。
> ところでリンカに話を持っていくのは微妙に違うと思いますよ。
> コンパイラが、名前のマッピングをすればいいんですから。
> たとえば作成された関数に1番から順に通し番号でも振ればいい。
これってマッピングって言うんですか? それにどうやってすべての環境で発番を管理するんですか。
シグニチャ(関数名と引数の形)をハッシュコードにしちゃえばいいかもしれませんけど、かぶらないとも限りませんよね。
ところで私は Pascal も Delphi もちょいちょいと使っていただけなのであまりよく知らなかったんですけど、Pascal って同じ名前の関数を作れるんですね。Cよりもいいとこがあるじゃないですか。
どんな言語もたどる道 (スコア:1)
>つまり、
>>許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります
>過去はさておき今は、納得しましょう、むしろ積極的に肯定しましょう、と言いたいのです。
その点については否定した覚えは無いし、否定するつもりもありません。
とはいっても安易に過去の資産の継承を否定してしまうと、オープンソースのような考え方も否定してしまうことになってしまいますが。
少なくとも、同じ名前の手続きを持てることが悪いといってるわけじゃありません。
使いつづけられ資産を蓄積したプログラム言語が、それゆえに古臭くなり限界が見えてくるのはPascalに限らずどんな言語でも避けられないようなことなのにPascalであることが落ち度であるような表現は不当じゃないかと書いたのです。
JavaやC#だっていつかは同じ道をたどるのだろうし。(すでにたどってる?)
古い処理系を捨ててしまえば済む問題なら
>>許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります
なんて話は出てくる必要はないですよね。
こういう嘆きが出てきたということはAverageさんにとってはまだ過去のPascalを捨てきれない事情があるということなのではないでしょうか。
>ところでリンカに話を持っていくのは微妙に違うと思いますよ。
>コンパイラが、名前のマッピングをすればいいんですから。
>たとえば作成された関数に1番から順に通し番号でも振ればいい。
本来の古典的なPascalならP-codeインタプリンタという閉じた環境の話なのでそういう方向性もあったでしょうが、現実にはCなどとの連携を考慮して一般的な命名規則を採用するという当時としてはより実用的な実装を採用しただけの話です。
>つまり限界といってもそれはべつに原理的にドコに限界があるというはっきりしたものが
>あるわけではなく、「たまたまその実装が」という感じですよね。
んでもPascalの場合はある程度環境(ハードウェア)を選ばずに動作することも目指していたわけで、実装がいまよりもずっとハードに依存していたことを考えるとそういう妥協は現実的選択だと思うのですが。
うじゃうじゃ
Re:…マッピング? (スコア:1)
尊敬の念とやらについては今回俺は言及も思考もしておりませんのでご了承を。
てゆーか、「落ち度」と書いたから「(非)尊敬」、ですか?
そういう感情論はアッチ(ってドコだ?)でお願いしたいものですが…
対象はあくまで技術的なものなのですから、"博物館に行ってくださいね"、という種類の敬意なら
払う事にしばしば意味がありますが、それだけのことですね。現場に残って欲しくはないです。
改良すればまだまだ現役という美辞もありますが、屋上屋を架すという諺も意識する必要があります。
捨てる勇気とも言いますね。きちんとした代替物が有る「なら」以前の劣ったものはおおいに無理なく捨てられるわけです。
#今日もまた過去のソースへの敬意(違)に逆らえなくて辛かったのでG7
>これってマッピングって言うんですか?それにどうやってすべての環境で発番を管理するんですか。
「全ての」環境は不要かと。そんなMSみたいな(GUIDだっけ?)贅沢は申しません。
「自分の」環境を記録したファイルかなんかを後生大事に持ち歩けばいいかな、と思っています。 #嫌だろうな(^^;
意味付けは違いますが、なんとなくSmalltalkのImageファイルのノリを連想してます。
>ところで私は Pascal も Delphi もちょいちょいと使っていただけなのであまりよく知らなかったんですけど、Pascal って
>同じ名前の関数を作れるんですね。Cよりもいいとこがあるじゃないですか。
ん。てゆーか、あれはDelphi(しかもver4あたり以降)の言語仕様だったような。
でFreePascalはたしかDelphi似が売り文句でしたよね。
余談:
個人的には、引数Overloadが絶対必要か?と詰め寄られたら、ちょっと目をそらすかも知れません(笑)。
どっちかってーと、SmalltalkでいうKeywordMessageみたいなもののほうが、ずっと重要かつ有用じゃないかと思っています。
名前つき引数とかと違って静的に処理できるんで、然るべきParserを作れば済むし、#名前つきだって静的に処理できないわけじゃないが、記号にあんまり多義性を持たせたくないですし…
読みやすさは引数をカンマでしか区切れない言語より数段マシだと思いますし。#書きやすさは…どうだべか?
Re:どんな言語もたどる道 (スコア:1)
記述フォーマット(この場合は言語)の陳腐化、というのは、
ソースを持つという考え方に対して「常に」ネックになりますね。
逆にいえば、そのネックとは上手に付き合っていかざるを得ないわけです。
あくまでネックなので、いつまでもいつまでも同じソース(&それの継承物)を引きずるのは
段段メリットよりデメリットのほうが多くなるでしょうね。
#これは、言語について言えば「言語の発達」というものが終わってしまわない限り、続く事でしょうね。
どこかで捨てる勇気が必要になるでしょうね。
勿論蛮勇では駄目で、代替物を準備してから捨てるべきなのですが、
逆にいえば代替物を用意しようと努力することもまた重要だし。
結局、どこからならば「安易」といえるのか?という程度問題になるのでしょうね。
また、単にあるソフトのある版の(^^;ソースが自由配布されるだけじゃなくて、
それが「新陳代謝」していくこともまたOpenSourceの醍醐味&メリットだと思います。
で、その変化がたまたまある時点で大きくなる…所謂乗り換え…という事が起きる(ことを肯定する)のは
別にOpenSourceと相反する考え方では、ないでしょうね。
過去の版が有る状況での話ではないですが、Squeakの思い出話(?)に
我々の誰もがCでVMを書きたいとは思わなかった [dti.ne.jp]というのが有りました。
あーゆーノリ、じゃないかな。
>使いつづけられ資産を蓄積したプログラム言語が、それゆえに古臭くなり限界が見えてくるのはPascalに限らずどんな
>言語でも避けられないようなことなのにPascalであることが落ち度であるような表現は不当じゃないかと書いたのです
「Pascalはその落ち度を持っている」と言ったツモリであり、
「その落ち度を持っているのはその言語がPascalだからだ」という差別論を展開したツモリは無いのですけど?
>JavaやC#だっていつかは同じ道をたどるのだろうし。(すでにたどってる?)
PascalにはPascalの、JavaにはJavaの、「落ち度」が有ります。
そしてそれらは、大抵「別々です」。あんまり重なりません。(重なるのも有るけど。)
俺(や任意の誰か)が、それぞれの言語についてそれぞれの時点でそれぞれ「落ち度」に気付いてそれぞれ語れば
それで良いだけのことです。
>こういう嘆きが出てきたということはAverageさんにとってはまだ過去のPascalを捨てきれない事情があるということ
「捨てきれない事情が有るから捨てられません」という話があることを論拠として
「捨てたいよね。捨てようよ。」という話を不当と呼ぶ、
のも不当なのではないですか?(^^;
事情のことを言い出したら、きりが無いのですけどね。地球上には無数の事情があるんですから。
>んでもPascalの場合はある程度環境(ハードウェア)を選ばずに動作することも目指していたわけで、実装がいまよりも
>ずっとハードに依存していたことを考えるとそういう妥協は現実的選択だと思うのですが。
まああの時点ではそんなもんかもですね。
逆にいえば後世までそれを引きずった実装は許し難いものが有りますが。
例えば今でも思い出すたびムカツク(笑)のですが、Delphi ver1のString型は、最大長さが256byteでした。
Win3.1時代でのあの制限はマヂ辛かったです。16bit時代なら文字列だってせめて65534byteにしてくれよ(T_T)。
Re:どんな言語もたどる道 (スコア:1)
>「Pascalはその落ち度を持っている」と言ったツモリであり、
>「その落ち度を持っているのはその言語がPascalだからだ」という差別論を展開したツモリは無いのですけど?
了解。「落ち度」という言葉に過剰反応してしまいました。
>「捨てきれない事情が有るから捨てられません」という話があることを論拠として
>「捨てたいよね。捨てようよ。」という話を不当と呼ぶ、
>のも不当なのではないですか?(^^;
そうですね。それには気付いてなかったです。
>今でも思い出すたびムカツク(笑)のですが、Delphi ver1のString型は、最大長さが256byteでした。
うああああっ。
いつのバージョンか忘れましたが、VBの配列サイズ制限でむかついた記憶が。(笑)
うじゃうじゃ
Re:期待はあるのですが・・・ (スコア:1)
これ、ワタシ逆に気持ち悪くてダメですね(大笑い)。
それに順序依存性がないのも気持ち悪いです(さらに倍)。
便利だし、絶対使っちゃうんですけど、自分は極力forwordっぽい宣言ってのが生理的に気持ち悪いです。
だから、今のObjectPascalよりOberonの方が気持ち良かったりします。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
あ。そういうことですか。ならば(俺も同じ意見かどうかはさておき(^^;)ナットクです。
>それに順序依存性がないのも気持ち悪いです(さらに倍)。
とりあえず俺が思うに、「OOP言語で」依存性が有ると、めちゃ辛いです。
(rubyみたいに一見宣言なものも実は実行である、という言語なら話は別ですが、
あれは逆にシンボルの評価(ってゆーか)がLazyに行われるんで、そもそも困りません。)
一般に手続き同士の「相互(循環)呼出」を、これといった対策なしに使うと、えらいことになりますが、
一般にObject同士の「相互(循環)参照」はなんぼでも有りです。やりまくりです。
この辺の違いが、「OOP言語では」順序の概念を捨てたくなる理由なんじゃないかと思います。
本質的に順序というものとの相性が宜しくない。
単に便利のためだけじゃなくて、必然としてそうある(べき)なんだと思います。
なので、純粋Pascalに対しては、あんまり文句はありませんが、
OOPを導入したタイプの奴には、不満を感じてしまいます。ちなみにC++も全く同じ。
>便利だし、絶対使っちゃうんですけど、自分は極力forwordっぽい宣言ってのが生理的に気持ち悪いです。
「宣言の」順序依存性が無くなれば、そもそもforward宣言は不要になるはず、ですよね。
1passで終わらないのは不愉快だという面もあります(^^;が、まあ重要な利益との引き換えなので…
#逆に、1passに拘って、言語として使い難くなっちゃうほうが、辛いなあ。
>だから、今のObjectPascalよりOberonの方が気持ち良かったりします。
なんか面白い言語らしいですね>Oberon
Re:期待はあるのですが・・・ (スコア:1)
ソレはオブジェクト指向だから、つーよりも、むしろ作法モードが順序依存無しモードに入るからじゃないですか?つまり使っている人間のせいじゃないですか?
私は(好みの性で)極力、forwardっぽい宣言をしないように作ってしまいます。ObjectPascalでもね。<この態度はどうか。
それと、現在はスコープと継承を同時にクラスにしょわせていますけど、本来OOPで重要なのは継承で、スコープ制御はまた別のメカニズムで行う方が自分としては好ましい気がしてます。だもんで、デリゲーション的なメカニズムの方が未来があるようなきがしますねー。(例の「オブジェクト指向は間違っていた!」のアレです)
それはそれとして、Oberonがいいなーと思うのは、pascalってwhile - doは文を囲むのにbegin-endがいるのに、repeat untilはイラン、とか仕様的に凸凹が見えるところが軒並み修正されてますので。
言語仕様的にはCLUとかOberonとかの方が好みにあいますねー。特にCLUはなかなか変態的で楽しい言語です。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
・・・冗談はさて置き、GNU-Cのネスト可能な関数というのは
独自拡張ですか?
C++なら関数オブジェクトにすれば、独自拡張に頼らずに
ネストした関数が作れますよ。
Re:期待はあるのですが・・・ (スコア:1)
今、Javaの中間コードに落とすアプリがあるんですよねー。
JITが効くから使うならこっちかなー。
>・・・冗談はさて置き、GNU-Cのネスト可能な関数というのは独自拡張ですか?
でしょう。
pascalコンパイラをサポートするのに必要だから、入れといたヨ、というハナシです。C派には微妙に迷惑な気も・・・
>C++なら関数オブジェクトにすれば、独自拡張に頼らずに
ネストした関数が作れますよ。
使っている用語がパスカリャーなんで微妙にずれているかもですが、ソレだとpascalのオブジェクトと同じなので微妙に使いたい所と違うです。関数のネスティングって手続きがめったやたらに長くなって、でも括りだして外に書くと引数が長くなるー、という時に手続きの中で関数を定義したりするです。このばーい、親の関数で定義した変数にもアクセス出来るんで・・・
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:0)
OS そのものの違いはよくわからないでありますっ!
Re:期待はあるのですが・・・ (スコア:0)
細かいことを言えば、Linux と Hurd はいずれも GNU libc を使う (ことが多い) ので、似てるのかなあ、と。
どのアプリが動くか、ということは、カーネルとは あまり関係ないような気がします。
Re:期待はあるのですが・・・ (スコア:0)
Re:期待はあるのですが・・・ (スコア:0)