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.
>
>

Reply via email to