nimat TECH
nim - 暇つぶし2ch185:デフォルトの名無しさん
[ここ壊れてます] .net
nimってIDEやデバッガは近いうちに計画されてるの?
vscodeでもいいんだけど、ちゃんとしたデバッガは欲しいな
条件付きブレークポイントやコンテナの中身が見れる程度でいいんだが

186:デフォルトの名無しさん
22/09/11 19:50:17.68 6Wt0j/hc.net
>>185
vscodeのプラグイン
nimsaem.nimvscode + webfreak.debug ではだめか?

187:デフォルトの名無しさん
22/09/11 22:55:03.70 EVjHVTpm.net
やっぱりその組み合わせか
どうにも使いづらいんだよねぇ
言語仕様は理想に近いんでもっと流行ってほしいんだが、これまでの情勢からあまり期待できなさそうだな

188:デフォルトの名無しさん
22/09/12 01:44:56.16 I2SXXYSG.net
>>184
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcast

189:デフォルトの名無しさん
22/09/12 01:47:29.58 I2SXXYSG.net
>>184
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcastしてるの?
そうでないならcast使うのはやめたほうがいいよ。

190:デフォルトの名無しさん
22/09/12 02:10:20.86 I2SXXYSG.net
>>184
seqやstringのデータ構造を理解しcastが何をしているか理解すれば納得できると思うよ
URLリンク(github.com)
URLリンク(github.com)
そもそもseq[uint16]からstringへcastしてる時点でもうデタラメなんだよ。

191:デフォルトの名無しさん
22/09/12 02:17:45.60 I2SXXYSG.net
>>185
NimにGDBでデバッグできるようにするプラグインが付属していて
gdbでブレークポイントをおいたり変数の中身を表示したりできます。
URLリンク(internet-of-tomohiro.netlify.app)

192:デフォルトの名無しさん
22/09/12 20:00:29.06 YXdRRv20.net
>>181 >>183
var u16 = newString(16)
for n in 0..7: u16[n * 2] = cast[char](65 + n); u16[n * 2 + 1] = '\0'
u16[14] = '\0'
echo u16 # -> A B C D E F G
echo convert(u16, "utf-8", "utf-16") # -> ABCDEFG

193:デフォルトの名無しさん
22/09/12 22:26:15.30 I2SXXYSG.net
>>192
castは極力使わないほうがいいのでビット演算使ってu16の値をcharに変換したほうがいいよ。
お手本コードを投稿しようとしたらcloudflareが悪意あるコードと勘違いしてブロックされた

194:デフォルトの名無しさん
22/09/12 22:30:11.19 I2SXXYSG.net
こんな感じです
let c=65u16 + n
u16[n * 2] = char(c and 0xff'u16)
u16[n * 2 + 1] = char(c shr 8)

195:デフォルトの名無しさん
22/09/13 11:55:15.89 gs7UQvs1.net
>>179
これ観ろ
URLリンク(khchen.github.io)

196:デフォルトの名無しさん
22/09/13 12:06:13.19 0kBS+x4w.net
言語仕様としてはモダンな言語の中で1番わかりやすいし
Rustで書くほどでもない軽いスクリプトとかならNimで良いんだけど流行らんなあ
やはり個人開発者の言語が流行ることはもうないのか

197:デフォルトの名無しさん
22/09/13 15:06:32.01 EXK746Ox.net
>>192 >>195
ありがとうございました

198:デフォルトの名無しさん
22/09/13 16:00:02.06 EXK746Ox.net
アク禁?

199:デフォルトの名無しさん
22/09/13 16:03:11.36 EXK746Ox.net
var ws = newWideCString(8) # ws.len == 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
# ws.len == 8
ws[7] = Utf16Char(0) # ws.len == 7
echo ws # ABCDEFG
と比べて

200:デフォルトの名無しさん
22/09/13 16:05:36.05 EXK746Ox.net
なぜ拒否られる?

201:デフォルトの名無しさん
22/09/13 16:06:26.54 EXK746Ox.net
驚き最小の法則ですね
var s = newString(8) # s.len == 8
for n in 0..7: s[n] = char(65 + n)
# s.len == 8
s[7] = '\0' # s.len == 8
echo s # ABCDEFG

202:デフォルトの名無しさん
22/09/13 16:07:15.32 EXK746Ox.net
判った char だけダメなんね

203:デフォルトの名無しさん
22/09/13 16:09:20.44 EXK746Ox.net
驚き最小の法則
var ws = newWideCString(8)
echo ws.len # -> 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
echo ws.len # -> 8
ws[7] = Utf16Char(0)
echo ws.len # -> 7
echo ws # ABCDEFG
と比べて
var s = newString(8)
echo s.len # -> 8
for n in 0..7: s[n] = char(65 + n)
echo s.len # -> 8
s[7] = '\0'
echo s.len # -> 8
echo s # ABCDEFG

204:デフォルトの名無しさん
22/09/13 16:11:32.87 EXK746Ox.net
インド人もびっくり

205:デフォルトの名無しさん
22/09/13 19:05:39.59 ketgm+4i.net
Win土人
Nim土人

206:デフォルトの名無しさん
22/09/16 10:37:25.88 8/QLgRNp.net
proc testfunc(x: cint): cint {.exportc, cdecl, dynlib.} =
return x
と描かれたソースを
nim c --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されて
import ctypes
ctypes.cdll.LoadLibrary('./hoge.dll').testfunc(123)
と実行出来たのですが
nim cpp --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されているはずなのに
LoadLibrary のところで
FileNotFoundError: Could not find module '(fullpath)\hoge.dll' (or one of its dependencies).
Try using the full path with constructor syntax.
と言われてしまいます
多分 or one of its dependencies が引っ掛かっているのではないかと思うのですが
何が足りないのでしょう? stdc++ の shared library ?

207:デフォルトの名無しさん
22/09/16 10:57:11.84 8/QLgRNp.net
libstdc++-6.dll
をコピーしてみましたがだめでした

208:デフォルトの名無しさん
22/09/16 11:30:30.18 lbCTEBn9.net
nimpy
nimodule

209:デフォルトの名無しさん
22/09/16 13:53:03.44 kdRP0PjD.net
>>206
objdumpっていうプログラムを使えばどのdllを使っているか見れるよ。
使い方忘れたからググってね。
Nimをインストールしたときにgccもインストールしてればそのときにobjdumpも一緒にインストールされる。
他にも依存しているdllを見れるツールは色々あるけど

210:デフォルトの名無しさん
[ここ壊れてます] .net
>>209
windows用にもobjdumpあんの?

211:デフォルトの名無しさん
22/09/16 16:24:53.42 8/QLgRNp.net
windows で nim 入れるときに一緒に入った mingw64 の中に objdump がありました

212:デフォルトの名無しさん
22/09/16 16:34:58.81 8/QLgRNp.net
>>209
objdump -p hoge.dll | findstr "dll"
で出て来たのが
libgcc_s_seh-1.dll
libstdc++-6.dll
kernel32.dll
msvcrt.dll
でした
libstdc++-6.dll
だけではなく
libgcc_s_seh-1.dll
も必要でした
無事動作しましたありがとう

213:デフォルトの名無しさん
22/09/18 09:51:11.78 KpBP36NG.net
>>203
URLリンク(github.com)

214:デフォルトの名無しさん
22/09/22 10:36:47.71 u9/ouAZs.net
import nimpy
import nimpy/py_lib as lib
initPyLibIfNeeded()
let wx = pyImport("wx")
let app = wx.App()
let frm = wx.Frame(nil, -1, "Hello, work!")
discard frm.Show()
discard app.MainLoop()
簡単杉感嘆

215:デフォルトの名無しさん
22/09/22 15:46:35.23 zq3yyQIu.net
こんなのや
URLリンク(github.com)
こんなのも
URLリンク(github.com)

216:デフォルトの名無しさん
22/09/23 15:49:32.66 9eaiNZZz.net
セルフホスティングくらいでけるのか?

217:デフォルトの名無しさん
22/09/23 16:54:42.46 COcKyTVz.net
>>216
セルフホストってどういう意味で言ってるかは知らないけど
Nim forum自体がNimで実装されてるよ。
URLリンク(github.com)

218:デフォルトの名無しさん
22/09/23 20:37:31.28 vOu7CdIL.net
プログラミング言語でセルフホスティングっていったらコンパイラが自身の言語で実装できることだろうよ
しかしできたとしてトランスパイラをセルフホスティングと呼んでいいのか

219:デフォルトの名無しさん
22/09/23 22:00:58.25 U9mPo3hK.net
出力がC言語か機械語かの違いぐらいだしトランスパイラだとしても普通にセルフホスティングって呼ぶよ

220:デフォルトの名無しさん
22/09/23 22:27:48.78 COcKyTVz.net
URLリンク(github.com)
ここにNim言語のコンパイラがあるけどソースコードはNim言語で書かれている。
gccなどのCコンパイラとgitがあればソースコードからビルドできる。
ソースコードからビルドするときはまず古いバージョンのNimコンパイラをC言語に変換したものをダウンロードしてCコンパイラでビルドする。
それでビルドしたNimコンパイラで最新のNimコンパイラをビルドする。

221:デフォルトの名無しさん
22/09/24 20:13:52.60 7pBAspe1.net
わりとどうでもいいな

222:デフォルトの名無しさん
22/09/25 02:56:32.67 z6wPsTgH.net
Cコンパイラは一般的にC言語で実装されているが、どうやってCコンパイラをビルドするのか
あらかじめビルド済みのCコンパイラを持ってきてビルドする
ではそのビルド済みのCコンパイラはどうやってビルドされたというのか

223:デフォルトの名無しさん
22/09/25 08:27:58.95 bk7Mey46.net
たぶん世界で最初のC言語はアセンブリかB言語かフォートランか何か別の言語で書かれていたんじゃないの?

224:デフォルトの名無しさん
22/09/26 14:35:28.98 heiSJ5NK.net
BigBangは未だ仮説だ

225:デフォルトの名無しさん
22/09/28 12:46:44.72 bM9/UxvQ.net
toSeq(0..360|24).map(rad)
と描くと
Error: type mismatch: got <SteppedSlice>
と言われて怒られたので
toSeq(0..360).filter(x => x mod 24 == 0).map(rad)
で描き治したら一応動く訳だが
0..360|24
観たいに描く方法は?

226:デフォルトの名無しさん
22/09/28 13:40:07.41 tqdPdMIm.net
iterator `|`(x: HSlice; y: int): int =
みたいな演算子のイテレータを定義すればいいじゃん。

227:デフォルトの名無しさん
22/09/28 17:12:46.81 XnHyDYU1.net
nim 1.6.8 出た

228:デフォルトの名無しさん
22/09/29 21:45:04.30 9HIV6ABQ.net
ウィ

229:デフォルトの名無しさん
[ここ壊れてます] .net
>>226
iterator items(s: SteppedSlice): int =
var c = s.a
while c <= s.b:
yield c
c += s.step

を定義したらイケました
有賀豚

230:デフォルトの名無しさん
[ここ壊れてます] .net
ニンニン

231:デフォルトの名無しさん
22/10/22 14:42:48.48 Q+2x5vm1.net
本日のNimConf2022期待age

232:デフォルトの名無しさん
22/11/02 12:51:11.01 VT3BATxp.net
1,2ヶ月くらい前に
Nim言語のマニュアル日本語訳がOSDNのページにアップされていて
これで5年後には結構人気が出るかもと喜んでいたら
突然ページが消滅してショックだった
キャッシュを探したけど発見できないので
コピー持ってる人がいたらどこかにアップしてもらえらばありがたいです
(ライセンス上問題が無ければですが)

233:デフォルトの名無しさん
22/11/02 22:26:34.03 AEY2Eek1.net
古いキャッシュならInternet Archiveにあった
URLリンク(web.archive.org)URLリンク(nim-lang-081.osdn.jp)
URLリンク(web.archive.org)URLリンク(nim-lang-081.osdn.jp)
まあキャッシュ古すぎて更新追いついてないけど

234:デフォルトの名無しさん
22/11/02 22:33:40.08 AEY2Eek1.net
URLリンク(ja.osdn.net)
このひとがオーナーになってるプロジェクトの1つみたいだけど、Twitterのアカウントも消えちゃってるね
プライベートが忙しくなったのかな

235:デフォルトの名無しさん
22/11/03 15:08:48.38 lETVCa2o.net
Last Update: 2022-09-21 01:12
Nim プログラミング言語 - 非公式日本語版 (翻訳活動終了)に関する活動はすべて終了しました。リポジトリの再公開予定はありません。
理由はよう判らん
githubにfork無かったかな

236:デフォルトの名無しさん
22/11/04 07:27:29.10 7DKhUjkg.net
日本語訳マニュアルの代わりになるかどうかはわからんけど
amazonで日本語のNim言語の書籍が売られてるよ。

237:デフォルトの名無しさん
22/11/05 00:35:21.38 mvfmSa9B.net
当時高校生の描いたやつか
CやC++との連携について
一行しか描かれてなかったな

238:デフォルトの名無しさん
22/11/06 13:47:02.47 4CeLTSQg.net
c2nim にがっかり感なんだけど
こんなもん?
それとも使い方間違ってる?
期待し過ぎ?

239:デフォルトの名無しさん
22/11/06 16:29:46.57 zKDylNc8.net
単純化した具体例がないとなんとも

240:デフォルトの名無しさん
22/11/06 16:42:07.10 06z0Icrt.net
わかっているのかもしれないけど、c2nimはどんなC言語のコードもNim言語に変換するものではない。C言語ライブラリをNim言語から使うためのバインディングをCのヘッダーファイルから生成するツールみたいなものだ。
c2nimに似たことができるこんなツールもあるよ。
URLリンク(github.com)

241:デフォルトの名無しさん
22/11/07 12:40:52.04 1sAmX+SP.net
>>233
全く使えないキャッシュだな

242:デフォルトの名無しさん
22/11/07 12:44:41.58 1sAmX+SP.net
>>232
3年前の nim 1.4.0だけど Nim日本語マニュアル
URLリンク(github.com)

243:デフォルトの名無しさん
22/11/07 13:21:56.37 V8od12Ai.net
ダメだこりゃ
みんなでzigに移動しよう

244:デフォルトの名無しさん
22/11/07 14:15:04.63 xn4jxoWB.net
いーんだよ グリーンだよ

245:デフォルトの名無しさん
22/11/08 12:57:20.87 CnIxTlte.net
template hoge(fuga: string): string =
fmt"{fuga}"
観たいなときに fuga が undeclared になるんだけどなんで?

246:デフォルトの名無しさん
22/11/08 13:05:00.14 CnIxTlte.net
>>240
なるほど良さげ
Sounds great, what's the catch?
Futhark is currently in an alpha state.
It currently doesn't support C++, and it doesn't understand things like function-style macros.
It might also mess up on definition types I haven't seen yet in the small handful of libraries I've tested it against.
All of these things are things I hope to get fixed up.

247:デフォルトの名無しさん
22/11/08 13:15:11.71 CnIxTlte.net
>>245 自己レス
出来ました本当にありがとうございました
template hoge(fuga: string): string =
block:
let injectedfuga {.inject.} = fuga
fmt"{injected_fuga}"
URLリンク(qiita.com)

248:デフォルトの名無しさん
22/11/08 18:53:20.46 nCLZIP1Q.net
>>247
それは公式ドキュメントのここに書いてあるじゃないですか。
URLリンク(nim-lang.org)

249:デフォルトの名無しさん
22/11/08 19:07:14.22 2BJbmpY0.net
Pythonスレでテンプレになってる内容をNim用に変更したので
次スレからはテンプレにしてください
-----ここから
Nimの★ソースコードをそのまま5ちゃんに貼るとインデントが崩れてチヌ★
【【【複数の連続半角スペースはなにもなかったことにされる&タブは普通には入れられない】】】掲示板の仕様なので、
プログラム文は↓等の、いわゆるコードうp用サイトに貼ってこいください。
URLリンク(glot.io)    結構使える。
URLリンク(play.nim-lang.org)   本家。
URLリンク(ideone.com)      デフォ設定はC用のため、言語選択ボタン押下がピコ手間かも。
URLリンク(pastebin.com)     まずまずシンプル。
-----ここまで

250:デフォルトの名無しさん
22/11/09 22:27:24.03 5vHWfdFN.net
判り初めた my Revolution

251:デフォルトの名無しさん
22/11/10 13:14:50.85 JZ2iIpp8.net
試してみた
本家 URLリンク(play.nim-lang.org)
スッキリ URLリンク(glot.io)
ダメぽよ(実行時エラー?) URLリンク(ideone.com) (たまに死ぬよねこのサイト)
貼るだけ? URLリンク(pastebin.com)
ideoneがダメなのはバージョンの問題?

252:デフォルトの名無しさん
22/11/10 13:25:08.92 JZ2iIpp8.net
これで逝けました
URLリンク(ideone.com)
pragmaのNimNodeを指定出来なかったらしい
ideone の Nim は (nim 0.19.4)

253:デフォルトの名無しさん
22/11/10 14:16:57.58 JDmtuJFO.net
URLリンク(wandbox.org)

254:デフォルトの名無しさん
22/11/10 15:04:27.30 JDmtuJFO.net
↑のWandboxでも最新の安定版Nimを使えるしコードを共有できる。

255:デフォルトの名無しさん
22/11/10 15:55:36.21 hnXF7Xx/.net
ここまでのまとめ
URLリンク(glot.io)    結構使える
URLリンク(wandbox.org) 最新のNim使える
URLリンク(play.nim-lang.org)  本家
URLリンク(pastebin.com)      ソース貼り付けのみ

256:デフォルトの名無しさん
22/11/10 16:23:45.65 j+QMfGd1.net
やっぱオフサイドスタイルはクソかよ。

257:デフォルトの名無しさん
22/11/10 16:52:41.86 JZ2iIpp8.net
>>253
wandboxだと(っていうかそれ以外でもかもだけど)
実行ボタンの上に
$ nim c ./prog.nim
って表示されてて c を cpp に変更したくても出来ない
左上の「コンパイルオプション」らしい枠に cpp を入れると
$ nim c ./prog.nim cpp
になったわ

258:デフォルトの名無しさん
22/11/10 20:00:36.53 JDmtuJFO.net
>>257
確かにwandboxだとnim cppでコンパイルできないっぽいね
もしかしたらgithubのwandboxリポジトリに要望を出せば対応してくれるかもしれない。もしくは自分で機能を実装してpull requestを出すか

259:デフォルトの名無しさん
22/11/11 10:16:18.33 8dOB0zbX.net
ここは未完成なのかな
日本語マニュアルっぽいけど
URLリンク(2vg.github.io)

260:デフォルトの名無しさん
22/11/12 14:40:51.16 OIoQvXCU.net
自分で育てる感覚楽しいですね

261:デフォルトの名無しさん
22/11/15 13:26:12.68 QGmQMBHU.net
type
Hoge* = object
fuga*: int
としないで
type
HogeObj* = object
fuga*: int
Hoge* = ref HogeObj
とするのは必須?習慣?
前者のデメリットは DeepCopy だというのは判るのですが
毎回後者を使った方が良い?

262:デフォルトの名無しさん
22/11/16 09:07:52.80 qCq9+PtI.net
{.byref.} じゃね?

263:sage
22/11/16 13:30:51.35 4BSq9VuL.net
横からだが
>>262 のbyrefと >>261 は完全に等価?

264:デフォルトの名無しさん
22/11/16 15:57:06.50 z+sJwdsY.net
proc 読んだとき ref のフリをする fake が 259

265:デフォルトの名無しさん
22/11/16 18:16:18.08 kOxph/zs.net
ref objectは一つのオブジェクトを複数のオブジェクトから参照したいときや継承使ってオブジェクト指向なコードを書くときに必要となる。
それ以外の場合はrefのついていないobjectのほうが速くなることが多い。
ref型は常にヒープに確保されポインタ経由でアクセスされるけどobjectだとスタックに確保できるしポインタで間接的に参照する必要もない。
object型のseqだとメモリ上に連続して確保されるけどref object型のseqにするとメモリ上に連続して確保されるとは限らないからキャッシュミスが起きやすくなる。
ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるからコピーのコストが問題になることがあんまりないと思うよ。
C++で言えばobjectはstructをそのまま使っている感じでref objectはstructをstd::shared_ptrごしに使っている感じ。

266:デフォルトの名無しさん
22/11/17 09:41:27.60 V4QZv0Fq.net
proc incx(i: int): int =
let j = i
{.emit: "++j;".}
result = j
echo incx(5)
URLリンク(glot.io)
let で定義された変数も書き換え可能なんですね素敵ですね

267:デフォルトの名無しさん
22/11/17 09:41:55.68 V4QZv0Fq.net
>>262-263
全く別物

268:デフォルトの名無しさん
22/11/17 09:45:16.34 V4QZv0Fq.net
>それ以外の場合はrefのついていないobjectのほうが速くなることが多い。
これはどうかなぁ
遅くなることの方が多いと思うが

269:デフォルトの名無しさん
22/11/17 10:53:32.89 hYmfXxMP.net
>>268
どうしてrefのついてないobjectのほうが遅くなる場合が多いの?

270:デフォルトの名無しさん
22/11/17 14:28:18.19 hYmfXxMP.net
>>266
emit pragma使っているんだからNimの安全性は無効になる。
rustでunsafeを使うようなもの。

271:デフォルトの名無しさん
22/11/17 15:18:49.83 fBlcqeZM.net
>>265
>ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるから
ってことは {.byref.} 描く必要無い?

272:デフォルトの名無しさん
22/11/17 17:33:28.89 7oSKGzG8.net
>>271
自動でやるのは関数の引数にオブジェとを渡した時だから
それ以外にコピーが頻繁に発生しないなら
byrefいらないんじゃね?

273:デフォルトの名無しさん
22/11/17 18:51:38.00 hYmfXxMP.net
>>271
URLリンク(nim-lang.org)

var parameters are never necessary for efficient parameter passing. Since non-var parameters cannot be modified the compiler is always free to pass arguments by reference if it considers it can speed up execution.
って書いてあります。

274:デフォルトの名無しさん
22/11/17 19:03:15.70 hYmfXxMP.net
>>271
URLリンク(nim-lang.org)
Nim manualではbyref pragmaがForeign function interfaceの章の下にある。
つまりbyref pragmaはC/C++の関数に引数をポインタ渡ししなきゃいけないときに使うもの。
それ以外のときに使う必要性はほぼ無いってこと。

275:デフォルトの名無しさん
22/11/17 21:39:23.14 ArWNCDPA.net
>>268
そんな速度差気付くことある?

276:デフォルトの名無しさん
22/11/18 05:58:57.10 AmxJEdx7.net
君らスタックの消費は気にならんのけ?

277:デフォルトの名無しさん
22/11/18 06:16:37.43 IYaGyAsl.net
>>276
10kバイト以上のでかいobjectをたくさん使うとかならスタックを使わないようにref objectにしてヒープに確保してもいいと思う。
けどそんなにでかいobject型のローカル変数をたくさん使うことってあんまりないきがするけど。

278:デフォルトの名無しさん
22/11/18 09:39:59.23 IJuokuF8.net
たとえば
URLリンク(qiita.com)
>オブジェクトの宣言にはref objectを使います。
>Nimでは関数の引数に入れられた変数の容量に応じてコンパイラが自動で値渡し/参照渡しを調節しますが、
>これは挙動の予測が付かずバグの原因になりえます。
>ref objectでオブジェクトを宣言していれば必ず参照渡しになるので、
>アプリケーション開発ではこちらに統一しましょう。

みたいなことが

279:デフォルトの名無しさん
22/11/18 10:17:44.40 IJuokuF8.net
問題無い訳ではないとも
URLリンク(flat-leon.)はてぶろ.com/entry/nim_arg_pass
バージョンや記事の年代に気を付けないといかんのかね

280:デフォルトの名無しさん
22/11/18 11:42:20.25 IJuokuF8.net
古いけどここの議論は判り易い
URLリンク(forum.nim-lang.org)

281:デフォルトの名無しさん
22/11/18 11:48:22.19 ygRIcUIa.net
>>273
それは var の説明であって ref の説明ではないですね

282:デフォルトの名無しさん
22/11/18 12:02:19.50 IYaGyAsl.net
>>278
>>281
refのついた型またはvar引数は常に引数を参照渡し(ポインタのコピー)する。
refやvarがついてない場合は引数のサイズにあわせてコピー渡しか参照渡しになるが、どちらにせよプロシージャ内で引数を変更するのは禁止

283:デフォルトの名無しさん
22/11/18 12:10:00.28 IYaGyAsl.net
だからデフォルトの引数の渡し方でそれがコピー渡しになろうが参照渡しになろうがそれで挙動が変わったりバグの温床になることはない。
ただしaddrとかemit, Assembler statementなどのNimが安全性を保証してない機能を使う場合は例外だ。

284:デフォルトの名無しさん
22/11/18 12:24:09.04 IJuokuF8.net
参照とか reference とか同じ名前だから混同してるのかも知れないが
Nim の参照型と C++ の参照型は全く別物
C++ の引数で使う参照型 & は Nim では var の方が近い
Nim の ref は C++ ではポインタ * と思った方が良い
Nim では
GC で管理されるポインタが ref
GC で管理されないポインタが ptr

285:デフォルトの名無しさん
22/11/18 17:46:16.11 PNsYUFFf.net
これ使うか使わないかでも全然違うのよね --gc:arc

286:デフォルトの名無しさん
22/11/18 18:35:09.65 yVVkBIHa.net
最近は --mm:arc

287:デフォルトの名無しさん
22/11/19 16:28:59.40 F8GIHVyH.net
--mm:orc 推奨

288:デフォルトの名無しさん
22/11/19 17:55:05.22 lavOlnrp.net
Nim2では--mm:orcがデフォルトになるらしいぞ。
みんな知ってると思うけど--mm:arcだともし循環参照があったときにメモリリークするぞ。

289:デフォルトの名無しさん
22/11/19 19:05:39.54 7QNjN12J.net
Nim2なんて10年以上先

290:デフォルトの名無しさん
22/11/20 10:26:07.81 MUgzJmMj.net
>>278 のリンク先なんか
「Nimでアプリケーション開発をするための設計のベストプラクティス」
みたいにイキってるけど
信用していいの?

291:デフォルトの名無しさん
22/11/20 11:36:46.79 h2bm0L4T.net
object type 全部 ref 付けろ教のひと
たまにいるよね
迷惑

292:デフォルトの名無しさん
22/11/21 13:35:10.22 LzW8OiBh.net
割と実用になるわね
URLリンク(pastebin.com)

293:デフォルトの名無しさん
22/11/22 09:38:49.09 E0zMoWY7.net
理由を示さないお作法は無視していい

294:デフォルトの名無しさん
22/11/24 09:24:22.39 qRYWlPaY.net
なんでもかんでもref付けろと
しつこく強要してる人は
あたまおかしい
大抵は{.byref.}で用足りる

295:デフォルトの名無しさん
22/11/24 15:02:15.10 7i9tpoXw.net
{.byref.}はnimからC/C++の関数を使うときに引数をポインタで渡しているときに使うもの。
それ以外では使う意味はないよ。
Nimはちゃんと最適な方法で引数を渡すから必要でもないのに{.byref.}とかvarとかつける必要はない。

296:デフォルトの名無しさん
22/11/24 18:37:53.45 m+x+kPsJ.net
var も ref も byref も全部別物だと何度言えば判るんだ?

297:デフォルトの名無しさん
22/11/24 18:42:50.52 RL/H9YUN.net
>>296
みんなが必ず遭遇する問題なので
短くまとめて次スレからテンプレにするのが良い
以下 >>296 のテンプレが続く

298:デフォルトの名無しさん
22/11/25 09:06:20.12 PV2ZG9bu.net
{.byref.}をrefと間違うのは判らんでもないし同情するが
{.byref.}をvarと間違う香具師は初めて観た

299:デフォルトの名無しさん
22/11/25 16:53:59.56 s0hi6gQd.net
nim 1.6.10 出た
1.6.98 まで行くのかw

300:デフォルトの名無しさん
22/11/27 12:26:56.31 IMKjsn3J.net
regexどれ使えば良いの?

301:デフォルトの名無しさん
22/11/27 16:05:43.13 /+GS7DyS.net
>>300
好きなのでいいんじゃ ?

302:デフォルトの名無しさん
22/11/27 17:37:23.28 1IfwvG7/.net
>>300
Nimでは正規表現よりPEGのほうがおすすめらしい。
URLリンク(nim-lang.org)
PEG (Parsing expression grammar) is a simple deterministic grammar, that can be directly used for parsing. The current implementation has been designed as a more powerful replacement for regular expressions. UTF-8 is supported.

303:デフォルトの名無しさん
22/11/28 05:25:04.28 T/4+TPza.net
300

304:デフォルトの名無しさん
22/11/29 12:04:17.71 +WMggzr1.net
pythonのStringIOとかBytesIOみたいなのは無い?

305:デフォルトの名無しさん
22/11/29 14:03:26.53 lz77OQ93.net
>>304
FileStreamとStringStream かも
URLリンク(nim-lang.org)

306:デフォルトの名無しさん
22/12/02 09:32:24.76 ef8lBYgh.net
URLリンク(nim-lang.org) を観ると
FileStream = ref FileStreamObj ← 判る
FileStreamObj = object of Stream ← 判らん
StringStream = ref StringStreamObj ← 判る
StringStreamObj = object of StreamObj ← 判る
Stream = ref StreamObj ← 判る
StreamObj = object of RootObj ← 判る
なんで
FileStreamObj = object of StreamObj
になっていないのでしょう?
意図を知りたいです

307:デフォルトの名無しさん
22/12/02 09:38:11.16 ef8lBYgh.net
URLリンク(github.com)
lib/pure/streams.nim の type を観ても
FileStream のだけ
FileStream* = ref FileStreamObj
FileStreamObj* = object of Stream
でした

308:デフォルトの名無しさん
22/12/02 17:15:15.76 Ojlf0I9F.net
命名の推測で「WHY?」という話なら、ofキーワードの後に来るのが、必ずxxxObjという規約ではないから。
目的としてxxxObjでないのは、それを扱いやすくするためでStringStreamやStreamはそのまま宣言したり
引数に渡したり、戻り値の型として記述して使用するのに対してxxxObjは普通にライブラリの使用者は
めったに直接的に使用しない。(ライブラリの設計者・実装者は普通に使う)
例を言えば、MemMapFileStream、ReadSocketStreamなども利用者は直接的に使用するが、いずれも
ストリーム系だがobject of の後にくるものは違う。
例えば、利用者はプロセスの出力をStreamで使用するなら、このようなprocを使う
proc outputStream*(p: Process): Stream
これを、クライアントプログラムの実装者が受け取る変数の定義でStreamObjと書いていたらおかしい。
APIドキュメントには、「最も使用される一般名称にはそのままの名前を付ける」としか書いてないが
Nimに限らず一般的に、1つか少数の抽象名と数多くの具象名は一般名称でプレ・サフィックスは付けない
URLリンク(nim-lang.org)
When naming types that come in value, pointer, and reference varieties, use a regular name for the variety that is to be used the most, and add a "Obj", "Ref", or "Ptr" suffix for the other varieties. If there is no single variety that will be used the most, add the suffixes to the pointer variants only. The same applies to C/C++ wrappers.
似た話にxxxRefがあるがこちらはref objectに単に付けるが、型名をあまり使用しない場合で、なおかつ
ref objectであることを強調する場合が多い。
StringTabeRef* = ref StringTabeObj
var tbl = newStringTable(...)

309:デフォルトの名無しさん
22/12/02 18:20:09.03 hfqW6J8Y.net
URLリンク(play.nim-lang.org)
継承するときに基の型についてるrefは無視されるようなので
objectかref objectのどちらから継承しているかは重要ではないようだ。

310:デフォルトの名無しさん
22/12/03 14:54:39.83 H3EtATlx.net
>>309
なるほど!

311:デフォルトの名無しさん
22/12/08 15:32:48.39 0CftMozc.net
template とか macro とか使うと
流れる様にさらさら描けて気持ち良いわコレ

312:デフォルトの名無しさん
22/12/12 07:08:32.93 pbYUfvW7.net
templateとmacroを上手くに使えるようになりてえなあ☹

313:デフォルトの名無しさん
22/12/13 09:48:40.02 xx5dSLzS.net
こんな感じのmacroを書いていろんなコードを与えてみよう。
コンパイル時にecho x.treeReprの出力が表示される。
それを読めばNimのコードはAST(抽象構文木)になることが理解できると思う。
これがNimのmacroを理解する第一歩だと思う。
import std/macros
macro test(x: untyped): untyped =
 echo x.treeRepr
test:
 echo "test"
後はこれを読めばok
URLリンク(nim-lang.org)
URLリンク(nim-lang.org)

314:デフォルトの名無しさん
22/12/14 10:22:41.84 LLXuibjV.net
macro は AST 知ってると有利だね
あと head と body を受け取るタイプのと
node を受け取るのと
static type を受け取るのとか
区別して理解しないと
自分が何やってるのか判らなくなる

315:デフォルトの名無しさん
22/12/14 15:44:32.71 SCwOJhsV.net
へぇ、それはクソ仕様だね

316:デフォルトの名無しさん
22/12/14 21:28:27.69 XhtdH9iq.net
node造る関数も直交性が無いな

317:デフォルトの名無しさん
22/12/17 10:10:45.75 a3CJqZUP.net
直交性という言葉を知ってるオジサン・・・
C/C++言語の#def, #include→別言語(直交性100%)、錆びのprintln!→実は別言語(直交性100%)
むしろこれは言語が習得で異なる仕様の言語を2つ覚えないといけない、敷居を高くする欠点

318:デフォルトの名無しさん
22/12/17 10:46:30.65 2DPGsS1m.net
NimNodeはseqに近い方法で扱えるようにmacrosモジュールにプロシージャが定義されているのはいいことでは。

319:デフォルトの名無しさん
22/12/17 12:04:27.61 OfpYIbSc.net
untyped は obsoleted

320:デフォルトの名無しさん
22/12/17 18:07:52.62 GzYo/1Xm.net
今はNimNodeじゃなく、quote do:で書くのが良いよな。どうしてもNimNodeじゃなきゃ書けないマクロもあるだろうけどね

321:デフォルトの名無しさん
22/12/17 19:18:25.81 2DPGsS1m.net
>>320
URLリンク(nim-lang.org)
URLリンク(github.com)
URLリンク(github.com)

322:デフォルトの名無しさん
22/12/22 07:38:06.92 Fm5nn8iV.net
最初のrelease candidate for Nim v2.0が公開されました。
URLリンク(nim-lang.org)

323:デフォルトの名無しさん
22/12/22 10:51:20.76 Y6cO6Ymu.net
ペース早いよなあ

324:デフォルトの名無しさん
22/12/22 10:52:43.57 N8bfJDIh.net
nim-2.0 RC1 がリリースされた
URLリンク(nim-lang.org)
来年1月か2月には正式2.0になるのかも

325:デフォルトの名無しさん
22/12/23 02:05:06.61 PNJSSvHF.net
もう2.0かよ(´・ω・`)公開してるライブラリ大丈夫かな

326:デフォルトの名無しさん
22/12/23 20:17:33.78 244A80LW.net
バージョンが大きく変わって大丈夫と思う方が
無理がある

327:デフォルトの名無しさん
23/01/04 23:27:44.60 ADP0p8ohV
だいぶマニアックなスレですね

328:デフォルトの名無しさん
23/01/16 16:24:59.02 MsfEWWA2.net
あっという間に2月

329:デフォルトの名無しさん
23/01/23 22:52:56.91 NHwV5soq.net
書き込みが1ヶ月に1回しかないスレ w

330:デフォルトの名無しさん
23/01/26 03:28:17.45 To7TXanK.net
Nim言語を使っていても特につまづくことがないから話題があんまりないんだよね。

331:デフォルトの名無しさん
23/01/26 18:39:32.28 MzjwjnoQ.net
使用者の絶対数が少なすぎ

332:デフォルトの名無しさん
23/02/01 01:23:34.72 p1uaZW7X.net
てすと

333:
23/03/01 09:22:10.73 68s28u+f.net
!omikuji

334:デフォルトの名無しさん
23/03/01 12:20:14.81 q8rzgPd8.net
初心者はys3mとかrs3mで十分
Ziicubeでys3m出た
1割引き価格後の値段
679円 マグネット
1151円 Maglev
1623円 Boall-Core
URLリンク(www.ziicube.com)

335:デフォルトの名無しさん
23/03/01 12:20:39.02 q8rzgPd8.net
>>334
誤爆

336:デフォルトの名無しさん
23/03/05 11:11:16.11 /Qd0pRlS.net
WinnyとNimってネーミングセンス似てるね

337:デフォルトの名無しさん
23/03/05 19:55:40.66 gl/xkADq.net
>>336
Nimは元々Nimrodっていう名前だったんだけどその由来は
URLリンク(forum.nim-lang.org)

338:デフォルトの名無しさん
23/03/06 14:19:57.93 diWxUEyJ.net
URLリンク(www.cosme.net)

339:デフォルトの名無しさん
23/04/03 17:59:13.21 dNC7VYHk.net
この言語ってRustみたいにプログラマに押し付けるmutなんて使ってないのに、なんでいわゆるMove操作が勝手に出来るの?
説明しろください!

340:デフォルトの名無しさん
23/04/03 18:32:57.47 3grB/pQG.net
>>339
こちらの資料には目をとおされましたか?
URLリンク(nim-lang.org)

341:デフォルトの名無しさん
23/04/09 09:29:43.33 Dm0aM9sg.net
Nim良いよね
Rustは宣伝がうざいだけだが
Nimは判ってる人の間でまったり進化してくれ

342:デフォルトの名無しさん
23/05/04 21:15:01.62 wwnsNcS0.net
公式読めばだいたいのことはわかるから特にここでも議論は出ないよね
唯一日本語の書籍がもう一冊くらい欲しいなあくらい

343:デフォルトの名無しさん
23/05/06 09:24:18.50 u7gslL5e.net
importとincludeの違いってなに?

344:デフォルトの名無しさん
23/05/07 06:11:02.39 uVIPnqNg.net
>>343
URLリンク(qiita.com)
URLリンク(qiita.com)

345:デフォルトの名無しさん
23/06/28 19:11:48.73 cQY5DEV3.net
Nim言語 1.6.14 リリース
URLリンク(nim-lang.org)

346:デフォルトの名無しさん
23/07/02 18:18:52.72 4yDce2PB.net
夜遅くにすいません。
SyntaxHilighter用のNim Brushってどっかにありませんか?

347:デフォルトの名無しさん
23/07/02 18:34:57.51 DcMb4mOQ.net
>>346
話の内容が全然理解できないけど。。。

348:デフォルトの名無しさん
23/07/02 21:16:17.65 w86HyNV3.net
>>347
ごめんなさい。
SyntaxHighlighter でした。

349:デフォルトの名無しさん
23/07/02 21:56:05.97 DcMb4mOQ.net
>>348
SyntaxHighlighter っていうのがよくわからないけど
VSCode拡張とかのこと?

350:デフォルトの名無しさん
23/07/03 07:33:58.97 VgAxDpje.net
>>349
えぇエ~それぐらいネットで調べ「てく」ださいよ~~。
伝えるのめんど「い」し、説明上手くないからネッ-トで調べた方が絶対%絶対%にわかると思うんですよね。
お願いしますよ~~

351:デフォルトの名無しさん
23/07/03 10:05:16.82 erf1sDFe.net
>>350
うわぁ~
怖い

引っ込んでます

352:デフォルトの名無しさん
23/07/03 12:35:43.48 VgAxDpje.net
>>351
恐がらせてごめん。

353:デフォルトの名無しさん
23/07/04 04:16:26.79 YbUZ4vjn.net
Nim言語はコンパイル時にreadFileとwriteFileを使えるんだけどコンパイル時にファイルを読み書きできるプログラミング言語ってあまりないんじゃないか?
staticExecていうコンパイル時にコマンドを実行できるプロシージャもあるし。

354:デフォルトの名無しさん
23/07/07 02:08:00.59 B1cwSpdy.net
どっかで既出かもしれんけど、結局VSCの拡張は何入れれば安牌?

355:デフォルトの名無しさん
23/08/01 18:27:12.50 JtUN40O9.net
URLリンク(github.com)

356:デフォルトの名無しさん
23/08/02 00:52:58.78 4aCNkU8+.net
Nim 2.0がリリースされました。
URLリンク(nim-lang.org)

357:デフォルトの名無しさん
23/08/26 23:20:45.36 6K2VICrE.net
初めてお邪魔します
下のスレッドでフィボナッチ数列(回帰関数)のベンチマークをやったのですが
Nim 2.0がダントツの速さでした
原因が分かる方、教えていただけますでしょうか、よろしくお願いいたします
Qiita 3 - キータぞ、来たぞ、キータだぞー
スレリンク(tech板:368番)-371
スレリンク(tech板:373番)-375
上記スレ、fibonacci(44)の計算、抜粋
Nim(44はコマンドライン引数)
URLリンク(wandbox.org)
>Time= 0.240s Result=701408733
C/gcc(44はソース直書き)
URLリンク(wandbox.org)
> Time: 0.89583 seconds
C/clang(44はソース直書き)
URLリンク(wandbox.org)
>Time=1.58712s Result=701408733

358:デフォルトの名無しさん
23/08/27 00:54:05.78 M561FwxM.net
>>357
Nimでコンパイルするときに'--listcmd'オプションを与えるとNimがgccを呼び出すときにどんな引数を渡しているか表示されるようになります。
もしかすると凄く最適化されるようなオプションを渡しているのかもしれません。

359:デフォルトの名無しさん
23/08/27 01:58:10.81 CxwZcjGE.net
>>358
早速の回答ありがとうございます
wandboxのspeedだとO3が見られたので、nim.cfgに gcc.options.speed = "-O2" を追加してついでに-d:ltoも外しました
Nim 2.0.0 + gcc 12.2.0(-O2) --verbosity:2 --listcmd --passL:-s (strip symbols)
URLリンク(wandbox.org)
>CC: prog.nim: /opt/wandbox/gcc-12.2.0/bin/gcc -c -w -fmax-errors=3 -O2 -I...
>Hint: /opt/wandbox/gcc-12.2.0/bin/gcc ... -lm -lm -lrt -s -ldl [Link]
>Hint: mm: orc; opt: speed; options: -d:danger
>Time= 0.274s Result=701408733
>Time= 0.252s Result=701408733
>Time= 0.251s Result=701408733
>Time= 0.250s Result=701408733
>Time= 0.250s Result=701408733
今度は確実に LTO無し gcc -O2 になりましたが、実効速度はダントツに速いままでした
何か気が付く点がありましたらまた今度教えてください (私の方は今日は限界です...)

360:デフォルトの名無しさん
23/08/27 17:22:00.42 P6KX7G/o.net
>>359
Nim言語が高速なのはC言語コードを吐き出した時に
再帰処理をgotoループに置き換えている可能性があります
その場合C言語のオプションをいくら変更してもあまり意味はない
です
確認はコマンドライン引数に --nimcache:.cache を加えて
コンパイルして.cacheフォルダ内のC言語ファイルを確認すれば
わかるはず
nim c --nimcache:.cache -d:release ...
-d:relsese の部分は -d:danger で 置き換え可能で
dangerのほうが高速です
詳細はここ
URLリンク(nim-lang.org)
コンパイル型言語のベンチを取る時は再帰処理コードは
避けた方が良いと思います

361:デフォルトの名無しさん
23/08/27 17:25:13.06 P6KX7G/o.net
>>360 追記
末尾再帰になっている可能性もありかな

362:デフォルトの名無しさん
23/08/27 22:36:37.59 M561FwxM.net
Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
gccは再帰関数をループに置き換えているかもしれないからその確認をしたかったら-S -masm=intelを付けてアセンブリコードを出力させて読んでみよう。

363:デフォルトの名無しさん
23/08/28 06:30:35.88 eKgmQu1D.net
>>360
変換キャッシュの見方、ありがとうございます

>再帰処理をgotoループに置き換えている可能性があります
確認したところ、置き換わっていませんでした

>コンパイル型言語のベンチを取る時は再帰処理コードは
>避けた方が良いと思います
↑ここ詳しくお願いします

>再帰処理をgotoループに置き換えている
↑こうなっていませんでしたが、これ前提での話だったのですか?

再帰fibonacciは個別の言語コンパイラ(更にバージョン)の
最適化ベンチマークには持って来いに見えますので

364:デフォルトの名無しさん
23/08/28 06:40:36.37 eKgmQu1D.net
>>362
>Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
その通りでした

確かめたところ二つの再帰関数コールがそのまま残っていて、
その他はNimのトランスパイル過程でのノイズがあるだけです

gccがノイズを消すために最適化を頑張った結果、Cより速くなったのですかね

365:デフォルトの名無しさん
23/08/28 06:47:48.48 eKgmQu1D.net
何気にNim + gcc HEADにしてみたら、更に速かったです

Nim 2.0.0 + gcc 12.2.0 -O2 (44はコマンドライン引数)
URLリンク(wandbox.org)
>Time= 0.250s Result=701408733

これ↑がこう↓

Nim 2.0.0 + gcc HEAD 14.0.0 -O2 (44はコマンドライン引数)
URLリンク(wandbox.org)
>Time= 0.197s Result=701408733

参考値再掲(>>357)
C/gcc -O2 (44はソース直書き)
URLリンク(wandbox.org)
> Time: 0.89583 seconds

C/clang -O2 (44はソース直書き)
URLリンク(wandbox.org)
>Time=1.58712s Result=701408733


gccの最適化が凄すぎて意味わからないですが、ありがたく享受する事にします

366:デフォルトの名無しさん
23/09/06 06:10:42.54 8VjD58re.net
レバテックωωω
Rust in
Nim out
ωωωωωω

367:デフォルトの名無しさん
23/11/15 08:06:37.71 6Kiw7POr.net
>>353
F#が、 F# Dataってライブラリで、コンパイル時に
ファイルの読み取りは、やってたけれど、あまり見かけないね。

368:デフォルトの名無しさん
23/11/28 09:23:46.10 XbNpNPYt.net
happyxってdjungoの上位互換なれねーかな
URLリンク(hapticx.github.io)

369:デフォルトの名無しさん
23/12/06 09:31:30.20 oM0gjrfW.net
>>367
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか?
Nimの実験的特徴 バージョン1.5.1
URLリンク(nim-lang.github.io)
第二プログラミング言語として Rust はオススメしません Nim をやるのです
URLリンク(wolfbash.hateblo.jp)

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ!」と言うとても大事な事を Nim は我々に教えてくれます

370:デフォルトの名無しさん
23/12/06 20:32:47.84 7Cu2FhSW.net
Nim って python を強調し過ぎてるのはミスリードだと思うな
python と相性が良いってのは事実だけど Nim の特徴のほんの一部でしかない

371:デフォルトの名無しさん
23/12/08 21:38:37.62 xBCOoZoU.net
>>370
Python使える人が多いからNimを広めるためにNim言語はpythonと同じだという人は多い。
文法がpythonに近いだけで中身は静的型言語だからpythonよりC++とかRustに近いと思う。
pythonしか知らない人がNimのオーバーロードとかGenericsとかobjectとref objectの違いとかちゃんと理解して使えるのかどうか心配になる。

372:デフォルトの名無しさん
23/12/10 11:41:19.18 1MxEINjf.net
「文法がpythonに近い」が事実じゃないんだよな
観た目が似てるだけであって文法が似てる訳じゃない
全然別物

373:デフォルトの名無しさん
23/12/10 17:02:37.56 S5Hrhavn.net
そういう意味では構文で結構損してそう
オフサイドルールが気に入らない人にとってはそもそも検討に値しないし
Python好きな人ならそこは気にならないだろうけど、別に移行しやすくもない

374:デフォルトの名無しさん
23/12/11 04:52:12.28 E9pPgJ3z.net
>>373
でも静的型言語でオフサイドルールの言語はNimとcrystal以外あまりないのでは。
オフサイドルールが好きで型システムがちゃんとしていて高速に動くプログラムを書きたい人にはぴったり。

375:デフォルトの名無しさん
23/12/11 06:10:19.79 dU0p99Eo.net
型で安全性を静的に担保したいと考える人が、同時にインデントで意味が変わってしまうオフサイドを好むってのはちぐはぐさを感じる

376:デフォルトの名無しさん
23/12/11 06:46:36.74 Oijs0Efp.net
HaskellとデフォルトF#もオフサイドルールありですね。どうせインデントするんだしって使ってやれってくらいの感じなのかね?

あとは、インデントに意味はないけれど、goが標準のフォーマッタでインデント入れてくるね。

377:デフォルトの名無しさん
23/12/11 06:54:57.74 n3cFiyWX.net
Python登場当時だと{}前後のどこで改行するか論争みたいなのがあったりして確かに括弧書くのが面倒な空気はあったんだよな
それがGo/Rustの世代だと言語標準のフォーマッタが勝手にやってくれるってなって
めんどくさくないっていうオフサイドのメリットはなくなってしまった
そうすると自動フォーマットしづらいとかコピペしづらいとかデメリットばかり目立つことになってしまう

378:デフォルトの名無しさん
23/12/12 04:50:08.02 X9wYEqIf.net
ブロック毎に'{}'や行末に';'があるとソースコードが少し汚く見えるし
無いとすっきりして読みやすいと思うけどね。

379:デフォルトの名無しさん
23/12/12 05:58:22.17 6YpoyKxr.net
そんなの単なる慣れ

380:デフォルトの名無しさん
23/12/12 08:04:30.17 BxX9TTWN.net
まぁ人によるんじゃない
自分は{}がある方がブロックの識別性が良くて読みやすい
オフサイドは特にネストしたブロックの戻りが何段戻ったか見づらいんだよな

381:デフォルトの名無しさん
23/12/12 08:08:33.42 BYtUbVYs.net
カッコありなら、lisp系が好き。
悩む事が減る。

382:デフォルトの名無しさん
23/12/12 13:00:45.46 GxOznL1S.net
>>378
セミコロンはオフサイドルールじゃなくてもRuby/Go/Kotlin/Swiftのように無しできるから関係ないよね
それにセミコロンをタイプするのは面倒だとは思うが慣れると読む時のノイズにはならない
自然言語の文章で句点やピリオド+改行がノイズにならないのと同じこと

383:デフォルトの名無しさん
23/12/12 19:48:14.86 X9wYEqIf.net
CやC++を10年以上使っていたけど';'や'{}'が無いほうがすっくりして読みやすいと思うから慣れでどうにかなるものでは無いと思う。
こういうのは個人差があるのかもしれないが

384:デフォルトの名無しさん
23/12/12 19:54:02.65 X9wYEqIf.net
URLリンク(github.com)
このVimのプラグインを使うと同じインデント間のカーソル移動、異なるインデント間のカーソル移動が簡単にできるからお勧めです。

385:デフォルトの名無しさん
23/12/12 22:53:30.64 wCEkJKJx.net
>>383
CやC++やっててそんなこと言うやつ初めて聞いたぞ
本当に日々コード書いてる?

386:デフォルトの名無しさん
23/12/12 23:44:06.92 CyOM3fCk.net
そりゃ仕事で使える言語でオフサイドルールなのってPythonくらいだし
ほんとはオフサイドがいいけどC/C++の仕事してるって人くらいいるでしょ

387:デフォルトの名無しさん
23/12/13 00:18:56.36 YitMt0Fm.net
>>386
{}や;がノイズになるかどうかと
オフサイドがいいかどうかの話は別だよ

388:デフォルトの名無しさん
23/12/13 04:42:50.35 /pcasGi0.net
>>385
今はC/C++殆ど書いてないけど以前はほぼ毎日使ってたよ。
{}や;に慣れてもやっぱり余計な文字が少ない方がすっきりして読みやすいと思うのだが、そういう人は少数派なんかな?

389:デフォルトの名無しさん
23/12/13 05:36:33.39 R3z2LBuJ.net
主観で読みやすいかどうか力説しても結論でるわけない
オフサイドは誤ってインデントずれても気付かないままになってしまうのが問題

390:デフォルトの名無しさん
23/12/13 06:48:31.89 RhfHz66O.net
>>388
まぁ実際オフサイド採用の新規言語ってあまり出てこないし
少数派なんじゃないかな

391:デフォルトの名無しさん
23/12/13 07:21:31.19 vQeZuGNk.net
f#みたいに、使う側が選択できれば、解決なんじゃない?

392:デフォルトの名無しさん
23/12/13 07:35:42.19 q/L8o2wk.net
やれやれお前らCOBOLを知らんのか

393:デフォルトの名無しさん
23/12/13 11:38:44.64 rzHxkjlX.net
>>388
どちらの方がすっきりして読みやすいかと
{}や;が思考ノイズになるかどうかは別だよ

前者はそれなりにいる
後者はツチノコレベルで稀有

394:デフォルトの名無しさん
23/12/14 19:26:43.32 xAMEKx/6.net
エディタの色設定で{};を薄い色にすればいいだけやん

395:デフォルトの名無しさん
23/12/15 03:05:56.17 /ClHmJDY.net
{}がノイズになるようなら:や=はもちろんのことblock:なんて発狂ものだろうからNimは無理やろな

396:デフォルトの名無しさん
23/12/15 05:55:25.21 12rLPAnL.net
思考ノイズって
エロい事連想してるって意味だよな?

397:デフォルトの名無しさん
23/12/15 06:50:06.26 4QMbv0z8.net
Nimってオフサイドルール以外の所は目立った欠点の無い言語なんかな。
それに実際にオフサイドルールでコードを書いていて困ったことないし。
インデントがずれても困るという人はインデントの幅をスペース4個とか広めにすればいいのでは

398:デフォルトの名無しさん
23/12/15 17:55:10.13 BxRUp1+8.net
オフサイドルールは欠点だらけ

Pythonを例にすると
- カットペーストは命がけ
- ネット等で共有しにくい
- テキストエディタやIDEの支援が激弱
- dedentは手動タイピング必須
- 改行のために追加の()や\が結局必要
- インデントだけでは可読性が低いから余計な:が必要
- 空行の数まで厳密に意識する必要もある
- lambdaのone expression縛りのように言語の成長を阻害しやすい
- “explicit is better than implicit”と言いながらブロックはimplicit

399:デフォルトの名無しさん
23/12/15 18:18:19.69 b3hxnew5.net
次は、良い点を挙げてみて!

400:デフォルトの名無しさん
23/12/15 18:24:50.43 pkr2dCwK.net
>>399
プログラミング初心者を釣れる
以上

401:デフォルトの名無しさん
23/12/15 20:46:34.27 4QMbv0z8.net
Vim使ってるけどコピペは問題無くできるしインデントの深さもブロックごと'>'で調整できる。
vim-indentwiseでブロック毎カーソル移動可能。
スペース一個分だけでインデントするとかしない限りブロックの開始、終わりは前後の行のインデントの位置の違いでわかる。
vim-indentwiseでカーソル移動すればブロックの範囲も簡単にわかる。
以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。
Nim書いていて改行のために追加の()や\が必要になることはほぼ無い
空行の数を厳密に意識する必要もない。
Nimを実際に書いたことあるの?

402:デフォルトの名無しさん
23/12/15 21:02:40.08 4QMbv0z8.net
URLリンク(wandbox.org)
NimのAnonymous proceduresでは複数行書けるし
こうしてコードを共有できてる。

403:デフォルトの名無しさん
23/12/15 22:17:03.24 kBMLRaUx.net
>>402
でもアロー関数にすると()を追加するなどしないと1行しか書けなくなる
これもオフサイドルールのせい
しかもこんな明らかなバグでも修正しようともしない
言語の成長を阻害するとはこういうこと

404:デフォルトの名無しさん
23/12/15 22:29:33.41 kBMLRaUx.net
>>401
論点理解せずにvim使いなら誰でも知ってる基本を必死に解説されても困るわ
>以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。
{}や;が無くて読みづらいとか書きづらいとか誰もそんなこと言ってないだろ?
勝手に脳内変換するなや
ついでに言うとセミコロン無い方が書きやすいのは当たり前のこと
だから新しい言語の多くがセミコロンレスを採用してる(オフサイドは採用しないけど)

405:デフォルトの名無しさん
23/12/15 23:45:28.85 4QMbv0z8.net
>>403
アロー関数ってNimのsugarモジュールにある`=>`マクロのこと?
あくまでこの=>は二項演算子だから両辺は式になっていないといけない。
オフサイドルールに関係無く二項演算子の両辺に文を直接書けず式を置かないといけないのは殆どのプログラミング言語で同じじゃない?
複数文を書きたければanonymous procedureで書けばよいし。
オフサイドルールじゃない言語で無名関数に複数文を書くときは必ず{}で囲む必要があるし。
どうしてこれが言語の成長を阻害していることになるの?
明らかなバグなのに修正しようとしないって言うけどGithubのNimのリポジトリにそういうissueある?
無名関数を書くときはdo notationというのもあるよ。
URLリンク(nim-lang.org)

406:デフォルトの名無しさん
23/12/16 08:47:38.44 yzC0WAGQ.net
「vimを使えばいい」とか「無名関数を使えばいい」などと列挙されても
他の言語はそんな特別なケアなしに使えるわけでな…
このあたりがいまいち広まらない原因なんじゃない?

407:デフォルトの名無しさん
23/12/16 08:53:10.18 mPzLcjX0.net
以前インデントの代わりに{}を使える機能があったようだ。
URLリンク(github.com)
URLリンク(forum.nim-lang.org)
けれども殆ど使われなかったのと、{}があるとgrammarとparserが発展するのが難しくなるので削除されたらしい。
URLリンク(forum.nim-lang.org)

408:デフォルトの名無しさん
23/12/16 09:38:42.94 mPzLcjX0.net
>>406
現代では高機能なテキストエディタやIDEが使えるから
それを使うことを前提にプログラミング言語をデザインしたらいいんじゃね?
って話は聞いたことがある。
sugarの`=>`マクロはNim言語のanonymous procedureを特定の条件下で簡単に書けるよう作られたもので完全にanonymous procedureを置き換えられるものでない。
sugarモジュール自体がシンタックスシュガーのようなものを提供するマクロなどを集めたものだし。
制限とか気にせずにanonymous procedureを書きたかったら=>を使わずに書くしかない。

409:デフォルトの名無しさん
23/12/16 09:56:43.39 yzC0WAGQ.net
>>408
そのへんがまさに省略記法の悪い点が出てる感じするな
省略するってことはソースコードの情報量は減っていて、それはタダではない
「OOのときにはXXを使う」みたいな規則がたくさん発生するというコストがあるんだよね
これはセミコロンレスもそうで、時々変なエッジケースが発生したりする

410:デフォルトの名無しさん
23/12/16 16:45:38.17 kvk3r8Lt.net
オフサイドルールと違ってセミコロンレス(optional semicolon)は多くの言語で妥当なトレードオフ
オフサイドルールが妥当なトレードオフとして成立してるのはHaskell系の言語くらい

411:デフォルトの名無しさん
23/12/16 20:00:00.36 USjLXMUH.net
なんかどうでもいいことをいつまでも
うじうじと
気に入らないなら使わなきゃいいだけ
気に入ったら使えばいいだけ

412:デフォルトの名無しさん
23/12/17 07:10:31.29 clYlz397.net
>>411
気に入っていても:
  ある日突然:
    気に入らなくなる事ってあるよね?
気に入らなくても:
  ちょっとしたきっかけで:
    すごく気に入ってしまうことも
    あるよね?

そういう時はどうすればいいの?

413:デフォルトの名無しさん
23/12/17 12:19:34.98 WUPd6f5k.net
>>412
>    すごく気に入ってしまうことも
>    あるよね?
Error: invalid indentation

414:デフォルトの名無しさん
23/12/17 18:41:59.56 F9NekDqG.net
Nimはよく考えずに機能追加して既にC++並みに複雑化してる
目新しさだけで飛びつくと後悔するぞ

415:デフォルトの名無しさん
23/12/18 02:13:02.65 DdCrjTir.net
そうなの? じゃあもうC++でいいじゃん

416:デフォルトの名無しさん
23/12/18 08:55:26.31 DG+uqCiP.net
例えば最近実装している変更についてもちゃんとここに理由とか書いてあるよ。
URLリンク(github.com)
このあたりをよく読めばちゃんと考えて機能を実装していることがわかるよ。
URLリンク(github.com)
URLリンク(github.com)
Discord/Nimのinternalチャンネルをときどき読んでるけど
開発者は論文読んだり他のプログラミング言語の機能を調査しているようだよ。
URLリンク(en.cppreference.com)

URLリンク(nim-lang.org)
を読み比べてみればわかると思うけどC++のほうがはるかに複雑だよ。

417:デフォルトの名無しさん
23/12/18 20:40:29.88 DG+uqCiP.net
Nim言語がどのような考えで設計されたか知りたい人はNimのblogを読むといいよ。
URLリンク(nim-lang.org)
URLリンク(nim-lang.org)

418:デフォルトの名無しさん
23/12/18 20:49:37.54 CbnA3O4k.net
Nimの現状を知りたい人はこれを読むといい
URLリンク(forum.nim-lang.org)

419:デフォルトの名無しさん
23/12/19 00:16:35.74 mrSFrPG8.net
議論をよく読めば何やらちゃんと考えて実装しているらしいのはC++も同じなんだよなあ

420:デフォルトの名無しさん
23/12/19 08:00:58.06 w9OEXcqM.net
>>419
単純に >>414 への反論なだけじゃない?

421:デフォルトの名無しさん
23/12/20 12:37:14.01 Cvw2c2UZ.net
バグ修正版のNim 2.0.2と1.6.18がリリースされました。
URLリンク(nim-lang.org)

422:デフォルトの名無しさん
23/12/23 09:16:16.92 VfEmk1mn.net
寂しいスポンサーページだな😢
URLリンク(nim-lang.org)
こりゃnimが普及しないのも当然か
rustとは大違い
URLリンク(foundation.rust-lang.org)

423:デフォルトの名無しさん
23/12/23 10:35:51.40 M8dtHAyN.net
でもRustは誰も使ってないじゃん

424:デフォルトの名無しさん
23/12/23 11:58:51.47 BXldyzev.net
Rust言語はトヨタ自動車が採用してると
どこかで読んだ

425:デフォルトの名無しさん
23/12/23 13:41:38.19 fLdoaHTJ.net
>>423
誰も使ってないは草

426:デフォルトの名無しさん
23/12/23 13:46:35.58 6J3b/0Sr.net
Nimと書き間違えたんだと思うが

427:デフォルトの名無しさん
23/12/23 18:13:17.30 A6gu1Hml.net
Nimを使っている組織のリスト
URLリンク(github.com)

428:デフォルトの名無しさん
23/12/27 19:41:58.29 g/RhhP+m.net
プログラムをビルドするためにC++だったらCMake、Rustだったらcargo.tomlにTOMLを使う。
Nimだったらconfig.nimsも.nimbleファイルもNim言語で書ける。
一つの言語でコンパイル言語としてもスクリプト言語としても使えて便利。
Nimはマクロやconstなどをコンパイル時に実行するためにVM使ってるんだけど、そのVMを使ってNimをスクリプト言語のように実行できるらしい。

429:デフォルトの名無しさん
23/12/27 19:50:00.04 J2C6aYvl.net
rustも複雑なことをしようと思ったらbuild.rsに書けるけど、それはそうとして依存関係をプログラム言語で書きたいかと言われると

430:デフォルトの名無しさん
23/12/27 20:16:43.40 E4kPlntL.net
あれもこれもできて便利!みたいなのはぱっと見良さそうでも
大規模・多人数・長期開発になると負債になりがちではある

431:デフォルトの名無しさん
23/12/27 20:24:29.72 qErwbOrg.net
happyxが起爆剤にならないかなぁ、、🙏

432:デフォルトの名無しさん
23/12/27 23:05:07.37 LUGQIuRd.net
zigなら全部zigで書ける(便乗)

433:デフォルトの名無しさん
23/12/27 23:27:30.38 7WiLoZ1Z.net
一体なにがエレガントなんだろうなこの言語って

434:デフォルトの名無しさん
23/12/27 23:34:47.36 qmMlPacq.net
まあアイコンはエレガントなんじゃない?王冠だし

435:デフォルトの名無しさん
23/12/27 23:51:57.04 Ra91RrOg.net
procとmethodとfuncを使い分けつつ{.global.}や{.async.}なとの{.pragma.}とmacroでぐちゃぐちゃにかき混ぜられるのが超エレガントw
他の言語では類を見ない

436:デフォルトの名無しさん
23/12/28 22:46:05.11 u+MANgUc.net
エレガントすぎてついていけないわ

437:デフォルトの名無しさん
23/12/28 23:18:44.60 u+MANgUc.net
エレガントすぎてついていけないわ

438:デフォルトの名無しさん
24/02/20 19:40:26.76 iQdtjO/s.net
新年の記念 保守

439:デフォルトの名無しさん
24/06/17 22:36:28.67 y0rZbngO.net
URLリンク(nim-lang.org)
Nim version 2.0.6がリリースされました。

440:デフォルトの名無しさん
24/10/04 21:03:40.29 jm0g8/rX.net
URLリンク(github.com)
から派生させた、Atkin Sieveベンチマーク
計算本体だけの計測に改め、更に桁を増やし、途中計算がオーバーフローしないように関係変数はすべて64bit
UPPER_BOUND: 500_000_000
Zig 1912ms
g++ 1916ms
Nim 1920ms gcc
Nim 1969ms clang
clang++ 2151ms
Rust 2411ms overflow-checks = false
Rust 2430ms overflow-checks = true
Zigが速かったので他は色々と変更した
Zigの変更は最小限なので再現検証をする場合は各自のZig計測値を基準にしてください

441:デフォルトの名無しさん
24/10/04 21:11:00.73 jm0g8/rX.net
特にデータ構造で
Nim seq[bool]
Rust Vec<bool>
は遅いので直ぐに取り換えてください
C++のvector<bool>は最適化がされていますが、最終的に別のものにしました

442:デフォルトの名無しさん
24/10/04 21:12:20.19 jm0g8/rX.net
>>440は取り換えた後の計測値です


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch