Julia: モジュールとインポートエイリアシング

私は数分前にあなたが次のことができることに気づきました：

import ArgParse
ap = ArgParse

ap.add_argument(...)

ただし、構文糖衣として「importas」表記を使用するとよいと思います。

私がここにいてそれについて考えている間、 @ JeffreySarnoffのフォーラム投稿で言及されているように、同じインポート行に複数の特定の関数をインポートする方法があると便利です。 問題を検索しても、そのような要求はまだ明らかになりませんでした。

何かのようなもの

# from the forum post
import Module.(export1,export2,export3)
# or
import Module.[export1,export2,export3]
# or maybe
import Module.{export1,export2,export3}

これとは別の問題ですが、関連しています。 したほうがいい

1. この問題を更新する、または
2. 新しい問題を作成する

（私はそのような機能の有用性は物議を醸すものではないと思います...）

編集：これはimport Module: export1, export2, export3で動作するようになりました

例えばもサポートするべきだと思います

import ArgParse.add_argument as addarg

インポート時にモジュールメンバーの名前を変更できるようにします。

名前が変更された関数名がディスパッチにどのように参加するのか疑問に思っていますか？

基本的には、 const foo = Base.barに相当するエイリアスのように機能する必要があります。

基本的にはエイリアスのように機能する必要があり、const foo =と同等です。
Base.bar。

関数をインポートするときは、それを使用するか、オーバーライドする予定です。 与えられた
上記、

Base.barをfooとしてインポートします

fooをBase.barとして使用することは間違いありませんが、fooを定義するとオーバーライドすることもできます
Base.bar？ それが必要ですか？

これは古い問題ですが、0.2に近づいているので、これを再検討する時が来たと思います。

コードを書くとき、私はいつもimport NumericExtensions as neを書きたいと思っていたので、これはサポートされていないことを自分自身に思い出させてしまいました。

これを実装するのはそれほど難しいことではないと思います。私の意見では、これは書くよりもはるかに優れています。

import NumericExtensions
const ne = NumericExtensions

+1

+1

これはまだ関係がありますか？ 個人的には、モジュールのエイリアシングのために追加のfoo = Fooを実行するだけでもかまいませんが、エイリアシングシュガーをサポートするためのコンセンサスがあったようです。 十分に強く感じている人は、自分でPRをしなければならないかもしれません。
ただし、 x as yは、＃1470で説明したconvert(y,x)構文の最強の候補の1つであることに注意してください。 2つを明確にするのはそれほど難しいことではないようですが、注意するだけです。

この機能の価値は、元の名前のインポートを回避できることです。

+1
この機能があれば素晴らしいと思います。

+1

新しいキーワードasを導入するのではなく、次のように=>演算子を使用するのはどうでしょうか。

import Tlahuixcalpantecuhtli => Venus: xxxxxxxxx => x9, yyyyyyyy => y8, zzz

これにより、同じ構文でモジュールと変数のサブセットのエイリアシングが直交して可能になります。

わからない、それは私には本当に醜いようだ。

import Tlahuixcalpantecuhtli as Venus: xxxxxxxxx as x9, yyyyyyyy as y8, zzz

それはもっといいですか？ 私はそれがはるかに読みにくいと思います。

私は個人的に、 asは=>よりも自明であると感じています。これは、いくつものことを意味する可能性があるようです。

完全な開示：Pythonバイアス。

asよりも$ =>構文の方が好きです。

私はナッシュ均衡で立ち往生している自転車小屋が好きです。

モジュールの内部シンボルを再バインドするのはなぜですか？ あなたが本当にそれをするべきではないので、その醜い。

Haskellのインポート構文が好きです。 Pythonの名前空間はJuliaのモジュールよりもきめ細かいと思います。 ジュリアのモジュールは、ハスケルのモジュールよりも精神的に感じられるので、インスピレーションを得るためにそこを探す必要があるかもしれません。

私は@ssfrrに同意しますasキーワードははるかに自明であり、Python / Haskellユーザーにはよく知られています。 読みやすさで@StefanKarpinskiの問題を解決するには、Pythonのようなアプローチも役立ちます。

from Tlahuixcalpantecuhtli as Venus import xxxxxxxxx as x9, yyyyyyyy as y8, zzz

REPLと話しているような気がします。 しかし、私はこの種の提案が実行可能ではないことを知っています。

from Tlahuixcalpantecuhtli as Venus import xxxxxxxxx as x9, yyyyyyyy as y8, zzz

これは、Pythonで最も嫌いな構文上の選択肢の1つです。 意味を少し変えるには、最初のキーワードとすべての順序を変更して、行全体を根本的に再配置する必要があります。 それは他の輸入品とは完全に異なって見え、ほとんど同じことをするという事実を覆い隠しています。 これはひどい構文設計であるimoであり、表面的には英語に似ていることに重きを置いています。

：+1： asの場合、：-1： fromの場合

import a => b: c => d, e => fは、私には少しPerl風に感じます。

私はナッシュ均衡について聞いたことがなく、それについて読んだ後、これがそれを構成するとは思わない。 しかし、面白いことに、このバイクシェッドは1時間に10の応答がありますが、非常に重要な（しかしより難しい）と私を襲う＃6984の提案は、コメントなしで4時間になりました！

as対=>に関しては、どちらも現在の状況よりも優れた改善になるでしょう。

＃6984の良い点@BobPortmann 。

=>はこれに最適だと思います、FWIW。

しかし、面白いことに、このバイクシェッドは1時間に10の応答がありますが、非常に重要な（しかしより難しい）と私を襲う＃6984の提案は、コメントなしで4時間になりました！

パーキンソンの元々の例えでは、この問題は自転車小屋であり、＃6984は原子炉です。

:)

私はこの鍋をかき混ぜるのは嫌いですが、私はasが好きだと思います。 =>は少し曖昧であり、これが辞書と構文を共有するのは奇妙です。 たぶん=だけが理にかなっています： import Foo: x = y 、これから行うconst x = Foo.yと同様です。

他に何もないとしても、Haskellドキュメントのその表は本当に役に立ちます。 私はよく（特にジュリアを最初に学んだとき）、いつimport / using / requireを使用するか、またはいつimport Mod.thingを使用するかについて混乱しました。 import Mod: thing 。 私は実際にインポートのコロン構文の説明を探していましたが、見つかりませんでした。

@jakebolewski Haskellの構文はかなり近いようです。JuliaのusingはHaskellの（修飾されていない） importと同等であり、JuliaのimportはHaskellのimport qualifiedと同等です。

出発点として、これが現在利用可能なインポート/使用構文の良い要約であることをよりよく知っている誰かが確認できますか？ 関数xとy Modがあり、エクスポートされていない関数pとqもあるとします。

import Modは、 Mod.x 、 Mod.y 、 Mod.p 、およびMod.q $をもたらします。 インポートされた関数はすべてメソッド拡張に使用できます

using Modは、 x 、 y 、 Mod.x 、 Mod.y 、 Mod.p 、およびMod.q $をもたらします。 xとyはメソッド拡張には使用できませんが、 Mod.*は使用できます。

import Mod.x, Mod.pは、 x 、 p 、 Mod.x 、 Mod.y 、 Mod.p 、およびMod.q $をもたらします。 これらはすべてメソッド拡張に使用できます。

import Mod: x, pはimport Mod.x, Mod.pと同じです

using Mod.x, Mod.pは、 x 、 p 、 Mod.x 、 Mod.y 、 Mod.p 、およびMod.q $をもたらします。 xとpはメソッド拡張には使用できませんが、 Mod.*は使用できます。

using Mod: x, pはusing Mod.x, Mod.pと同じです

私が知る限り、 using Modは、 Modによってエクスポートされるものを気にする唯一の使用法です。

モジュールのドキュメントにこの要約があると非常に便利です。 誰かがこれを確認できるので、PRを準備できますか？

最も論争の少ないバージョンは次のようです。

import Tlahuixcalpantecuhtli as Venus: xxxxxxxxx as x9, yyyyyyyy as y8, zzz

かっこいいです。 ただし、割り当てバージョンは興味深いものであり、テストしてみます。

import Venus = Tlahuixcalpantecuhtli: x9 = xxxxxxxxx, y8 = yyyyyyyy, zzz

嫌いだろうと思っていたのですが、実は結構いいです。 このモジュールで紹介されている名前が最初に来て、最も目立つのが好きです。多くの点で、それが最も重要なことです。

@jakebolewski ：モジュールの内部シンボルを再バインドするのはなぜですか？ あなたが本当にそれをするべきではないので、その醜い。

2つの異なるモジュールから名前が衝突するバインディングをインポートしたい場合があります。これにより、それが可能になります。 それらを完全に修飾することもできますが、エイリアシングをサポートしている場合は、これもサポートすることをお勧めします。

いくつかの適切に配置された改行は、IMOをより読みやすくします。

import Tlahuixcalpantecuhtli as Venus:
    xxxxxxxxx as x9, 
    yyyyyyyy as y8,
    zzz

また

import Venus = Tlahuixcalpantecuhtli: 
    x9 = xxxxxxxxx, 
    y8 = yyyyyyyy, 
    zzz

私は割り当てバージョンを非常に強く好むことがわかりました。 結局のところ、インポートは割り当ての一形態です。

モジュールのドキュメントにこの要約があると非常に便利です。 誰かがこれを確認できるので、PRを準備できますか？

@ brk00 、頑張って！

@kmsquire 、今日はそれに取り組みます！

しかし、その前に、私はそれをよく理解していることを確認したいと思います。 @ssfrrの例では、REPLを使用していて、 using Modと入力するとします。 インポートされた関数xおよびyは、メソッド拡張には使用できません。 つまり、別のx関数とy関数を宣言すると、一度インポートしたModのメソッドにアクセスできなくなり、新しいメソッドにのみアクセスできるようになりますか？

これは、関数をインポートせずに拡張しようとするとどうなるかです。

julia> module Mod

       export x, y

       x() = "x"
       y() = "y"
       p() = "p"
       q() = "q"

       end

julia> using Mod

julia> x()
"x"

julia> p()
ERROR: p not defined

julia> x(n) = n
ERROR: error in method definition: function Mod.x must be explicitly imported to be extended

次のようなメソッドを追加できます。

julia> import Mod: x # or import Mod.x

julia> x(n) = n
x (generic function with 2 methods)

julia> methods(x)
# 2 methods for generic function "x":
x() at none:5
x(n) at none:1

さて、私は名前解決の振る舞いに混乱しました：

julia> module Mod

       export x, y

       x() = "x"
       y() = "y"
       p() = "p"
       q() = "q"

       end

julia> using Mod

julia> x(n) = n
x (generic function with 1 method)

using Modでインポートした関数を使用する前に、新しい関数をxに割り当てても、エラーは発生しません。 しかし、たとえば、新しい割り当ての前にx()を呼び出すと（例で行ったように）、実際にエラーが発生します。

ああ、面白い！ 私はそれについて知りませんでした。 usingの後に名前空間を示すために、たまたまxを呼び出しました。

たぶん、コア開発者の1人が光を当てることができます。 xが呼び出され、オーバーロードの試行時にエラーがトリガーされるとどうなりますか？

上記の@carlobaldassiによって提案されたエイリアシングは、実際には非常に便利です。

importがモジュールオブジェクトを返すだけで、 constの有無にかかわらず、割り当てを使用して直接エイリアス化できるかどうか疑問に思っています。 例えば

const Shortname = import ModuleWithLongName

それ以外の

import ModuleWithLongName
const Shortname = ModuleWithLongName

これには、新しい構文は必要ありません。既存の構文要素の組み合わせだけが必要です。 現在、 importは「ステートメント」であり、純粋に副作用のために呼び出され、価値がないことを認識しています。 パーサーがこれを許可しない場合は、 import("Module")または同様のものをお勧めします。

モジュールをエイリアスするオプションは良いかもしれないと思いますが、誰も言及していないという欠点もあると思います。それはコードをかなり曖昧にする可能性があります。 コードリーダーの観点からは、モジュールのわかりやすい名前を1つだけ持つと便利です。

しかし、調べるのはかなり簡単ですか？ 短縮形は、 numpyのnpのような人気のあるパッケージでも標準化される可能性があります。

標準化されたnpよりもnumpyを好み、$ numpyよりもArraysを好みます。 numpyは、1950年代のダンスの動きと致命的な疫病の間のクロスのように聞こえます。

簡単に書くことができます：

Base.require("ArgParse")
const ap = Main.ArgParse

これには1.0の構文は必要ありません

このための構文が必要だと思います。 はい、 requireとconstの割り当てができるので、それがなくても生きることができますが、 requireを使用するのはかなり醜く、便利な構文がないため、名前を変更できません。彼らが望む/必要とするように。

参照https://github.com/fredrikekre/ImportMacros.jl

constの簡単なトリックは、マクロのエイリアスを作成する必要がある場合には不十分です。これが私のやり方であり、理解するのに時間がかかりました。

julia> macro foo(a, b, c)                                  
           a, b, c                                         
       end                                                 
<strong i="8">@foo</strong> (macro with 1 method)                                 

julia> macro f(args...)                                    
           Expr(:macrocall, Symbol("@foo"), args...) |> esc
       end                                                 
<strong i="9">@f</strong> (macro with 1 method)                                   

julia> <strong i="10">@f</strong> 1 2 3                                            
(1,2,3)                                                    

ImportMacros.jlで私は実装しています：

• <strong i="15">@from</strong> Foo.Bar use foo as f
• <strong i="18">@from</strong> Foo.Bar use <strong i="19">@foo</strong> as @f

参照： https ：//github.com/fredrikekre/ImportMacros.jl/pull/3

@ Ismael-VC

試す

<strong i="7">@eval</strong> const $(Symbol("@foo")) = $(Symbol("@bar"))

これは醜いですが、マクロをローカルで定義するよりも短く、おそらくより明確です

@TotalVerbよろしくお願いします！

Julia + ImportMacrosに欠けている機能は、モジュールと、そのようなモジュールから可変数のオブジェクトをエイリアスし、エイリアスなしで他のオブジェクトをインポートすることの両方をエイリアスすることだけのようです。

• <strong i="9">@from</strong> Foo.Bar as B use foo as f, <strong i="10">@bar</strong> as <strong i="11">@b</strong>, baz

またはfromなし：

• import Foo.Bar as B: foo as f, <strong i="17">@bar</strong> as <strong i="18">@b</strong>, baz
• import B = Foo.Bar: f = foo, <strong i="21">@b</strong> = <strong i="22">@bar</strong>, baz

最後のものはマクロでは不可能のようです：

julia> parse("<strong i="26">@from</strong> Foo.Bar as B use foo as f, <strong i="27">@bar</strong> as <strong i="28">@b</strong>, baz")
:(<strong i="29">@from</strong> Foo.Bar as B use foo as (f,@bar(as,(@b(),baz))))

julia> parse("<strong i="30">@import</strong> Foo.Bar as B: foo as f, <strong i="31">@bar</strong> as <strong i="32">@b</strong>, baz")
:(<strong i="33">@import</strong> Foo.Bar as B:foo as (f,@bar(as,(@b(),baz))))

julia> parse("<strong i="34">@import</strong> B = Foo.Bar: f = foo, <strong i="35">@b</strong> = <strong i="36">@bar</strong>, baz")
ERROR: ParseError("unexpected \"=\"")
 in #parse#310(::Bool, ::Bool, ::Function, ::String, ::Int64) at .\parse.jl:184
 in (::Base.#kw##parse)(::Array{Any,1}, ::Base.#parse, ::String, ::Int64) at .\<missing>:0
 in #parse#311(::Bool, ::Function, ::String) at .\parse.jl:194
 in parse(::String) at .\parse.jl:194

提案された構文はすべてエラーまたはまったくナンセンスであるため、これを実際に1.0で決定する必要はありません。

元のモジュールが再定義された場合、たとえばREPLのreload("...")によって、モジュールエイリアスはどうなりますか？ const M = MyModuleアプローチでは、 Mはリロード後も古いモジュールを参照するため、 MyModule MyModule.nameでのみアクセスできますが、アクセスできません。 M.name 。

その場合、エイリアス構文はconst M = Moduleのシンタックスシュガー以上である必要がありますが、代わりにMが常にMyModuleと同じものを参照するようにしてください。

これにより、開発中にモジュールをimport継続できるため、REPLワークフローも簡素化されますが、毎回（ const以外の）エイリアスを再確立することなく、より短いエイリアスを介してモジュールを参照できます。 reload 。

現在、 reloadは削除されているため、この懸念は適用されなくなりました。

これはincludeにも当てはまりますか、それとも何かが足りませんか？ 一般に、モジュールが再定義されると、 import edモジュール名は新しい定義を参照し、割り当てによって定義されたエイリアスは古い定義を参照します。

いいえ、それは心配する必要はありません。 インポートされた名前は、通常のimportを含め、モジュールが再定義されたときに変更されることはありません。 変更されたのは、再度インポートした場合にインポートされるモジュールです。 インポートされたものは常に単なるバインディングでした。

わかりました、多分私は自分自身を明確に表現しなかったので、ここに例があります：あなたが内容でファイルtest.jlを作成するならば

module Tst
f() = 1
end

ロードしてTstをインポートし、 Tstのエイリアスを定義すれば、すべて問題ありません。

julia> include("test.jl")
Tst

julia> import Tst

julia> const Tst2 = Tst
Tst

julia> Tst.f()
1

julia> Tst2.f()
1

test.jlをに変更した場合

module Tst
f() = 2
end

そして、REPLでincludeを再実行すると、モジュールとそのエイリアスの動作が異なります。

julia> include("test.jl")
WARNING: replacing module Tst
Tst

julia> Tst.f()
2

julia> Tst2.f()
1

なぜそうなるのかはわかりますが、 import Tst as Tst2のようなエイリアスを作成する場合はそうならないはずです。

私はこれを0.6.2でテストしましたが、現時点では0.7でテストできないので、これがまだ当てはまるかどうかは今はしません。

あなたはそれをまったくインポートしていません。 含めるモジュールは、スコープですでに定義されています。 importはノーオペレーションです。

本当ですが、これは重要ではありません。 重要なのは、架空のimport Tst as Tst2のようなことをするとどうなるかということです。 その場合、このステートメントはノーオペレーションではありませんが、エイリアスを作成します。

このエイリアスがconst Tst2 = Tstのように機能する場合、モジュールTstを再定義すると、エイリアスは古いバージョンのモジュールを指すようになります。 これはどのような場合でも望ましくありません。 エイリアスが新しいバージョンのTstも指すようにするか、ユーザーにエイリアスの再確立を強制する必要があります。 ただし、後者の場合、再確立せずに古いエイリアスを使用すると、古いモジュールを指す代わりにエラーがスローされます。

それが完全にポイントです。 この問題は、モジュール定義ではなくimportに関数を追加することに関するものです。 importは動作せず、削除するとコードにimportまたはusingがなくなるため、この問題とは関係ありません。 モジュールがimportと同じスコープで定義されないように変更してください。

import Tst as Tst2は、その名前にバインドされているものに関してはimport Tstと同じように機能します。これは常にバインドであり、必要な魔法ではありません。 これは、モジュールを定義するときにエイリアスを追加することではありません。

言い換えれば、あなたのコードは基本的に、

a = Ref(1) # include
a = a # import
b = a # alias
a = Ref(2) # include again

また、 aはa = aにまったくバインドされていないため、 b = aの動作について文句を言うのは意味がありません。 悪い例では、インポートと同じスコープでモジュールを定義することの副作用（つまり、同じスコープでa = aとa = Ref(...) ）が表示されます。

わかりました。状況によっては、割り当てによって定義されたエイリアスが期待どおりに機能しない場合があることを指摘したいと思います。 多分私は悪い例を選びました。 これは、モジュールエイリアスを作成する構文（ importに関連するかどうかに関係なく）にとって重要かもしれないと思いましたが、現時点では、これはとにかく仮説です。 騒音でごめんなさい。

この問題は長い間存在していましたが、いくつかの拡張機能についてはまだ議論する必要がありますが、

import LongPackage as longpkg

それ自体はかなり合理的なようです。

バンプ。 今のところ、最善の解決策はどのようなものか疑問に思っていますか？ これが私がしていることです：

import LinearAlgebra
const linalg = LinearAlgebra

より良い解決策があれば私を訂正してください！

それが現在の基準です。

〜構文はどうですか？ 影響はわかりませんが、見た目は素晴らしいです。 また、〜は近似の記号として使用されます。

import LongPackage ~ lp

@JeffreySarnoffがStefanを引用

@StefanKarpinski

これは、Pythonで最も嫌いな構文上の選択肢の1つです。 意味を少し変えるには、最初のキーワードとすべての順序を変更して、行全体を根本的に再配置する必要があります。 それは他の輸入品とは完全に異なって見え、ほとんど同じことをするという事実を覆い隠しています。 これはひどい構文設計であるimoであり、表面的には英語に似ていることに重きを置いています。

この場合、〜はPython構文の英語のような側面とは何の関係もありません。 〜を見ると、近似の数学的概念を認識しているだけだと思います。 10.001〜10。

ですから、そういう意味では、実は結構いいと思います。

import LongPackage ~ lp
import HugePackage ~ hp
import MassivePackage ~ mp
import GiantPackage ~ gp

:-)

わかりました-Pythonを忘れてください-私はそのコメントを削除して

lp imports LongPlayingRecords
hp imports HewlettPackard
mp imports MilitaryPolice
gp imports PariForNumberTheory

私はもともとそれが好きではありませんでしたが、多くの人が自然にこれをasで書きたいと思っているようです。 これは明確な構文コンテキストであるため、キーワードなどとして予約する必要はありません。

人々にそれが何を意味するのかを知らせるために_試みる_プログラミング言語！？！

@JeffreySarnoff

Pythonよりも優れたものにしようとするプログラミング言語!!!

@neilpanchal Juliaは間違いなく、多くの点でPythonよりも優れていることを試みる言語です。 一方で、Pythonが何かを正しく理解したPythonとは_異なる_ことは、明らかにその方法から外れることはありません。 Juliaは、Pythonの左右の構文規則を借用しています。

Python asを採用してください。 彼らはそれを正しく理解しました。

julia> LightGraphsをlgとしてインポート
エラー：構文：式の終わりの後に追加のトークン「as」

Pythonから離れたasを支持するもう1つの$ 0.02コメント。 fwiw、ジュリアを定期的に使用しているので、これが恋しいです。 Pythonの場合とは異なり、Clojure（例を参照）の場合と同様に、パッケージスコープの名前空間（曖昧さ回避に適しています）を簡略化して、ライブラリを明示的に使用する方がはるかに便利です。 using （つまり、ワイルドカードのインポート）がimport Gadlfy as gfに構文上の砂糖を持たないようにすることを好むので、 const gf =行を追加しないでください（私が現在行っていること）便利になります。

as構文をサポートするさらに別のコメント：heart：将来のJuliaリリースで本当に難しいことを願っています。

私もこれが起こることを望みます。 特にそれは重大な変化ではないので（そうですか？）。

これはいつか実装されると思いますが（時間を作ることができれば自分で試してみます）、それまでの間、 ImportMacrosパッケージには、ここで要求された機能のほとんどすべてが含まれています（ドキュメントはありませんが） ：

<strong i="8">@import</strong> ModuleA as ma
<strong i="9">@using</strong> ModuleB as mb
<strong i="10">@from</strong> ModuleC use long_function_name as func
<strong i="11">@from</strong> Module use <strong i="12">@macroname</strong> as <strong i="13">@alias</strong>

ImportMacros .jlについて知りませんでした、指摘してくれてありがとう。 この機能がパッケージに含まれている場合、基本言語で使用することはそれほど重要ではないと思います。

私はまだこれが言語で持っているのは良いことだと思います。

インポートはIMOであり、マクロでラップしたり、パッケージの依存関係を追加したりするのではなく、ほぼ_常に_基本言語の規則に従う必要があります。 import ... constは、（特に）2つのステップのプロセスをより簡潔にするために基本言語が拡張されていない場合でも、フォールバックするのに適しています。

特に、見るのは少し醜いです

using ImportMacros
<strong i="6">@using</strong> OtherPackage as ...
<strong i="7">@using</strong> ThirdPackage as ...

非マクロusingが突き出ているからです。

importがモジュール/関数/実際にスコープにもたらすものを返すのはどうですか？
その後、あなたは書くことができます
lg = import LightGraphs
baz = import foo.bar
baz, kit, kat = import foo : bar1, bar2, bar3
変更が必要なのはインポート機能だけです

@DhruvaSambraniのソリューションは、Juliaの全体的な「すべてが表現である」アプローチに適合しているため、私は本当に気に入っています。

唯一のことは、一貫性を保つために、インポート式は、フルネームをスコープに入れるという副作用を実行する必要があるということです（おそらく災害ではありません）。 フルネームをインポートしないように特殊なケースにすることもできますが、特殊なケースはグロスです。

OCaml（最高のモジュールを備えた言語！）では、次のようなことができます。

module LG = LightGraphs

ここでの重要な違いは、OCamlプログラムでコンパイルされるすべてのモジュールの修飾名が自動的にスコープ内にあることです。

もちろん、 import LightGraphs as LGを使用することには、「誰もが」Pythonからすでに知っているという利点がありますが、私の個人的な好みは、文字通り割り当てであるものに割り当て構文を再利用する方がよいということです。

または、より広範な変更は、タイプとして「名前空間」を導入することです（すでに行われている場合はidk）。 次に、 importは、モジュールなどを名前空間に展開して、名前空間を返すことができます。 ただし、 import mod_nameを実行するだけでは、グローバルスコープでmod_name名前空間を使用できないため、これによりすべてのJuliaコードが破損します。 インポートが先行する割り当てなしで使用されるときに、何らかの方法でmod_name名前空間をグローバルで使用できるようにすることができれば、それは問題ではありません。

または、新しい関数import_as_ns(mod_name) :: Namespaceを追加するだけです。これは、単一の名前空間ですべての関数/モジュールなどを返す純粋関数になります。

それはジュリアの全体的な「すべてが表現である」アプローチに適合します

ただし、 importとusingは、副作用のためにのみ使用され、トップレベルでのみ使用されるため、特別です。

ちなみに、この問題は長い間開かれていることを考えると、トリアージはそれを再検討して決定することをいとわないのではないかと思います。 以来、私は閉鎖を提唱します

1. import Foo; const Bar = Fooは、ユーザーが名前空間のFooを気にしない場合に、完璧なソリューションを提供します。
2. ImportMacros.jlが残りを処理する必要があります。
3. どちらも、特別な構文を保証するために実際のコードで非常に頻繁に使用されているようです。

結局のところ、私はまだこれを見逃していると言います（そして私は自分のコードでImportMacrosも使用しています）。

私はあなたが書いているコーヒーのスタイルがこれの必要性（または欲求）に影響を与えると思います。 MLや科学的なコードを書いているとき、私はそれをあまり見逃していないことに気づきます。 長い名前のパッケージを多数使用する他のコードを書いたときは、ImportMacrosを最もよく使用していることがわかりました。

ImportMacrosで十分です。 私はそれがそれほどきれいに見えないというコメントに同意します。

また、エディターでオートフォーマッターを使用してインポートを並べ替えることができる日も楽しみにしています...しかし、 @usingをどうすればよいかわからない可能性があります...

@kmsquireにも同意します。これはそれほど大きな問題ではなく、ImportMacrosで十分なはずです。 ただし、どのような方法でも、二度と出てこないように文書化する必要があります。

まだm=import Module砂糖が欲しいのですが😅

私のメッセージがこれが大したことではないことを意味することを意図していませんでした。

私はまだこのための構文を好みます。

ImportMacrosで十分です。 私はそれがそれほどきれいに見えないというコメントに同意します。

同意します。 また、次の場合：

using ImportMacros
<strong i="8">@using</strong> OtherPackage as ...

初心者やプログラミング初心者に言語を提示するときに、特定のスクリプトがこの矛盾から始まる理由を説明するのは少し面倒です。これは、流れを複雑にし、教育の焦点を変えるためです。

どちらも、特別な構文を保証するために実際のコードで非常に頻繁に使用されているようです

人々が実際のコードでImportMacrosをあまり使用しない理由は、トレードオフが原因である可能性があります。 たとえば、私はほぼ毎回import ... as ...を使用しますが、それを行うために最初に別のパッケージをインポートする必要がない可能性があります。 追加の依存関係だけでなく、「感触」の点でも影響があります（そして、コードが洗練されたように見えるのが好きな人もいます（特にPythonやJulia）🤷‍♂️、そしてこのusing/@usingはかなり「スクリプトの導入に対するハッキーな雰囲気）。

そうですね、「ImportMacrosで十分です」。 本当に使いたい人のために。 しかし、それは重要な問題ではなく、人々はそれなしで働くことができます。 それにもかかわらず、私は通常、言語の構文が固執するのはこれらの小さなことであると強く信じています。したがって、このモンスタースレッドはそのサポートをベースに追加します。

import ... as ...は間違いなく価値のある糖衣構文であり、理解と説明が非常に簡単で、パッケージの名前がかなり長い傾向があるJuliaなどの言語で特に役立ちます（明らかに、これは重要です）人々がusing ...をやりたくないという仮定の下でのみ）。

そして、Pythonが最初にそれを実装したという事実は、実際には関係がないはずです。 ジュリアは、他の言語から距離を置いたり、独自のアイデンティティを強調したりする前に、最高の構文を使用するように努める必要があります。

このための構文と人気のあるモジュールに関する規則（私はそれが常にimport numpy as npとimport matplotlib.pyplot as pltである方法を考えています）も、 using SuchAndSuchを実行してexportに依存する代わりに簡潔な代替手段を提供します

@DominiqueMakowski ：

初心者やプログラミング初心者に言語を提示して、特定のスクリプトがこの矛盾で始まる理由を説明する

なぜそれが矛盾だと思うのか理解できません。それは単に名前空間管理であり、これは一般的なプログラミングの通常の部分です。

また、モジュールの名前変更は、Juliaの初心者が最初に遭遇するものではない場合があります。

ユースケースがないと言っているわけではありませんが、独自のキーワードを正当化することはまれかもしれません。 現時点では、 using ImportMacrosを検索すると、Githubで10未満の一意の結果が得られます。

私はimport ... as ...をほぼ毎回使用しますが、それを行うために最初に別のパッケージをインポートする必要はないでしょう。

これにより、両方の方法が削減されます。 ImportMacrosや追加の記号（ import LongFoo; const Foo = LongFoo ）などのligthweightパッケージを使用する（非常に小さな）コストがメリットに値しない場合、メリットはそれほど大きくない可能性があります。 。

ジュリアは、他の言語から距離を置いたり、独自のアイデンティティを強調したりする前に、最高の構文を使用するように努める必要があります。

これがこの議論の動機であるとあなたが考える理由はわかりません。

constの割り当てがうまく機能しない場合は、 asを使用したい場合があります。

julia> using Distributed

julia> import Future; const future = Future
Future

julia> Future === Distributed.Future # oops, this is what we wanted
false

julia> Future === future # not what we wanted `Future` to mean
true

はい、これを回避することはできますが、厄介です。 それはしばしば便利で、時には必要であり、 import FooBar as FBは一般的に合意された「最も意外な」構文であることを考えると、それは私たちがやるべきことのように思えます。 この必要なのは、誰かがそれを実装するPRを作成することだけです。

新しいJuliaユーザーはこちら。
私は主にRのバックグラウンドを持ち、Pythonも使用しています。 usingのような読み込みメカニズムがもたらすパッケージの共通名前空間については悪い経験があります。 衝突のリスクは1つですが、読みやすさの観点からすると、各メソッドのモジュールについて常に考えるという精神的な負担になります。

この構文の追加がどれほど複雑かわかりませんか？ それは初心者のために実行可能ですか？

おそらくそれほど簡単ではありません。 これには、Schemeで記述されたパーサーコードをハッキングし、変更をASTを介して配線し、一部のCコードにも影響を与える可能性があります。

これは、複数のモジュールでの関数名の競合を回避するための優れた機能です。

たるみについての議論から、私はいくつかの考えを追加します

これにより、関数名の選択や正しい関数へのメソッドの適切な追加に注意を払わなくなるのではないかと思います。 たとえば、

numpy.sin
sympy.sin

異なる関数は、数値入力と記号入力の両方で機能させたい場合に、関数の2つのバージョンを実装する必要がある確実な方法です。 利便性のためにそのような名前空間がジュリアでも普及した場合、多くのコードの再利用を逃す可能性がありますか？ つまり、Lyndonがhttps://www.oxinabox.net/2020/02/09/whycompositionaljulia.htmlに掲載したように、これによって「人々が一緒に働くことを奨励する」ことが少なくなるのではないかと心配しています。

@baggepinnenこれはその点で何も変わらないと思います。

Juliaでは、異なるモジュールに実装されたメソッドは、両方のメソッドを同じ名前空間にインポートすることによってマージされません。

julia> module Foo
           export sin
           sin(s::String) = uppercase(s)
       end
Main.Foo

julia> sin(1)
0.8414709848078965

julia> using .Foo
WARNING: using Foo.sin in module Main conflicts with an existing identifier.

julia> sin("wat")
ERROR: MethodError: no method matching sin(::String)
Closest candidates are:
  sin(::BigFloat) at mpfr.jl:727
  sin(::Missing) at math.jl:1197
  sin(::Complex{Float16}) at math.jl:1145
  ...
Stacktrace:
 [1] top-level scope at REPL[4]:1
 [2] run_repl(::REPL.AbstractREPL, ::Any) at /build/julia/src/julia-1.5.1/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:288

julia> Foo.sin("wat")
"WAT"

これを機能させるには、元の関数にディスパッチを明示的に追加する必要があります。

julia> Base.sin(s::String) = Foo.sin(s)

julia> sin("wat")
"WAT"

私の知る限り、モジュールのエイリアシングによって関数のディスパッチ方法を変更する方法はありません。

そして正直なところ、同じ名前のいくつかの関数は別々の名前空間に存在する必要があります。 数値ライブラリのfind_delta関数は、ファイル差分ライブラリのfind_deltaとは関係のないことを実行します。 コードが非常に多形になり、壊れた入力で実行する方法が見つかると、JavaScriptの領域に入り、誰もそれを望んでいません。

@ninjaaron上記の懸念事項のニュアンスを伝えることができなかった可能性があります。 私は、この変更によって、ライブラリを実装するときに人々が選択する戦略以外のものが変わることには関心がありません。
Foo実装している人が次のような警告に遭遇しました

julia> using .Foo
WARNING: using Foo.sin in module Main conflicts with an existing identifier.

単にimport .Foo.sin as sin2を選択するか、彼が本当にBase.sinの新しいディスパッチを提供したいかどうかを考えることができます。 私の言いたいことは、それらを単純に異なる関数と見なすことが非常に簡単になると、実際には同じ関数の異なるメソッドである必要がある場合でも、これが広すぎる可能性があるということです。 同じ名前の異なる機能を扱うのが少し厄介な現在の状況には、人々が互いに話し合い、それが本当に同じ機能であるかどうかを判断するために最善を尽くすという素晴らしい副作用があります。 私は、同じ名前で異なる機能を持つ可能性に異議を唱えているわけではありません。もちろん、これは非常に便利です。 私の懸念が重要であるかどうかさえわかりませんが、それが考慮されていることを確認するためにそれを持ち上げる価値があると考えました。

@baggepinnenそれは理にかなっています、そしてそれを持ち出すことに害はありません。 モジュールのエイリアシングはライブラリユーザーにのみ影響するため、これがライブラリを作成する人々に大きな違いをもたらすとは思いません。 モジュールのエイリアシングが簡単になると、名前の競合について_不平を言う_ユーザーが少なくなる可能性があると思いますが、それがAPIに多大な影響を与えるとしたら驚きます。

ライブラリを作成するとき、私は通常、Baseの関数にディスパッチを追加するのか、それとも個別に保持するのかをかなり意識しています。 他のほとんどの図書館の著者もそうだと思います。

@ninjaaron現在のコンベンションがディスパッチに特定の実装を使用している場合

numpy.sin
sympy.sin

ユーザー/開発者向けの追加オプションとしてimport numpy.sin as np_sinを使用しても、現在のコードベースに影響を与えることはありません。
唯一の懸念は、公開機能/インターフェースにのみ影響を与えることです。