To expand on why that is a little more, user-defined code can do anything it wants, including lie about, e.g. whether a function is applicable to arguments or not, whether one type is a subtype of another or not, what the type of something is, etc. These things are so basic to how Julia works that if we allow the user to lie about them, it's very likely that everything will completely break.
On Wed, Jan 6, 2016 at 11:00 AM, Stefan Karpinski <[email protected]> wrote: > If we allow many of these to be user-defined, they will break a lot of > things. See #1974 <https://github.com/JuliaLang/julia/issues/1974> for > example. > > On Wed, Jan 6, 2016 at 10:53 AM, Ismael VC <[email protected]> > wrote: > >> Thanks for your answer Tim, what do you think about wrapping the builtins >> in julia functions, does it makes sense? >> >> Rename builtins with a trailing underscore, and map them to julia generic >> functions >> >> applicable(args...) = _applicable(args...) >> apply_type(args...) = _apply_type(args...) >> arrayref(args...) = _arrayref(args...) >> arrayset(args...) = _arrayset(args...) >> arraysize(args...) = _arraysize(args...) >> fieldtype(args...) = _fieldtype(args...) >> getfield(args...) = _getfield(args...) >> invoke(args...) = _invoke(args...) >> is(args...) = _is(args...) >> isa(args...) = _isa(args...) >> isdefined(args...) = _isdefined(args...) >> issubtype(args...) = _issubtype(args...) >> kwcall(args...) = _kwcall(args...) >> nfields(args...) = _nfields(args...) >> setfield!(args...) = _setfield!(args...) >> svec(args...) = _svec(args...) >> throw(args...) = _throw(args...) >> tuple(args...) = _tuple(args...) >> typeassert(args...) = _typeassert(args...) >> typeof(args...) = _typeof(args...) >> >> This would allow to extend things like getfield and setfield!, throw, >> etc. I think. >> >> >> Ismael Venegas Castelló >> >> *Data Analyst* >> >> Cel. 044 55 6434 0229 >> >> [email protected] >> >> Cerro San Francisco 357, C.P. 04200 >> >> Campestre Churubusco, Coyoacán >> >> Ciudad de México >> >> <http://t.sidekickopen35.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XX43Mx_82W1p1tN-8q-fZWW3LPXXH56dKBHf5NSPJF02?t=https%3A%2F%2Frichit.com.mx%2F&si=4656540167962624&pi=8cd666ab-5464-4924-dee0-05beca79ab1e> >> >> <https://www.facebook.com/richitsolution> >> <http://t.sidekickopen35.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XX43Mx_82W1p1tN-8q-fZWW3LPXXH56dKBHf5NSPJF02?t=https%3A%2F%2Ftwitter.com%2Frichitsolution&si=4656540167962624&pi=8cd666ab-5464-4924-dee0-05beca79ab1e> >> <[email protected]> >> >> Tel. 6718 1818 >> richit.com.mx >> >> 2016-01-06 8:42 GMT-06:00 Tim Holy <[email protected]>: >> >>> On Wednesday, January 06, 2016 06:06:17 AM Ismael Venegas Castelló wrote: >>> > could we >>> > switch to arrays instead of keep using svecs once julia defines the >>> array >>> > type? >>> >>> Won't work. svecs are used all over the C code, because the C code is >>> the core >>> from which you bootstrap. Moreover, you don't "throw away" the C code >>> once >>> more of julia is up and running---it's still used to manipulate ASTs, >>> compute >>> type intersection and subtyping, perform method dispatch, perform >>> codegen, >>> etc. >>> >>> If you tried to "switch" to arrays, you'd have to implement everything >>> twice, >>> effectively. >>> >>> --Tim >>> >>> > >>> > El martes, 5 de enero de 2016, 9:09:08 (UTC-6), Matt Bauman escribió: >>> > > On Tuesday, January 5, 2016 at 3:23:14 AM UTC-5, Ismael Venegas >>> Castelló >>> > > >>> > > wrote: >>> > >> Why force `methods` to work with anything? >>> > > >>> > > Because you can call anything: >>> > > >>> > > julia> call(x::Char) = x+1 >>> > > call (generic function with 1038 methods) >>> > > >>> > > julia> 'c'() >>> > > 'd' >>> > > >>> > > julia> methods('c') >>> > > >>> > > 1-element Array{Any,1}: >>> > > call(x::Char) at none:1 >>> > > >>> > > There's been a much stronger push for documenting the external >>> interfaces, >>> > > but there's more and more internal developer documentation these >>> days, too >>> > > ( http://docs.julialang.org/en/latest/devdocs/julia/). It's getting >>> > > better. >>> > > >>> > > I believe flisp.boot is a generated file. >>> > > >>> > > Builtins are simply functions (and types) that are written in C; >>> necessary >>> > > for bootstrapping. You can find the mapping between their Julia >>> names and >>> > > the C definitions here: >>> > > >>> https://github.com/JuliaLang/julia/blob/baf174f5c252a438006c6f23ed7097fbab >>> > > 004025/src/builtins.c#L1202-L1284.> >>> > > Search for their C names to find their definitions. They accept any >>> > > >>> > > number of Any arguments within their function definitions, but those >>> that >>> > > require a certain number of arguments have error checking within the >>> C >>> > > function. >>> > > >>> > > Also note that anonymous functions have the type `Function`, too. >>> The >>> > > introspection utility you want is `isgeneric`. I imagine lots of >>> this >>> > > will >>> > > change with the jb/functions branch, where all functions are generic. >>> >>> >> >
