any chance putting in 'Symbol' with a preferred use warning to (depr..)
'symbol'?
On Thursday, August 20, 2015 at 11:21:41 AM UTC-4, Stefan Karpinski wrote:
>
> Yes. In old languages, there's no longer any hope of fixing the
> inconsistencies.
>
> On Thursday, August 20, 2015, Sisyphuss >
> wro
+1 respellings and renamings that follow from this thread
If you know, please provide us with those words/names/symbols in v0.4 today
that have capitalizations, spellings, or patternings that are inconsistent
with the way very similar role/intent/use/purpose is expressed in better
reviewed, mor
Yes, but I think that window will rapidly be shutting for Julia.
It is becoming a victim of it's own success, so many people are seeing the
advantages of Julia, even now, while there
are still a few warts (which hopefully will get addressed quickly during
ArrayMegeddon in 0.5).
This has already
Yes. In old languages, there's no longer any hope of fixing the
inconsistencies.
On Thursday, August 20, 2015, Sisyphuss wrote:
> This is the characteristic of a young language, isn't it?
>
>
> On Tuesday, August 18, 2015 at 6:02:36 PM UTC+2, Matt Bauman wrote:
>>
>> On Tuesday, August 18, 2015
This is the characteristic of a young language, isn't it?
On Tuesday, August 18, 2015 at 6:02:36 PM UTC+2, Matt Bauman wrote:
>
> On Tuesday, August 18, 2015 at 11:29:00 AM UTC-4, Sisyphuss wrote:
>>
>> My point is these inconsistent rules are very confusing. The experience
>> gained in one type
I'm always available to advocate for consonant symmetry and autodydactic
expressiveness on Julia's behalf. The consensual upwelling that let the
broader decision deserves respect. That motive intent was to finalize one
important tailoring of Julia's experience -- the experiences we each have.
On Tuesday, August 18, 2015 at 12:02:36 PM UTC-4, Matt Bauman wrote:
>
> `float` is an interesting case as it's regularly used to generically mean:
> convert to a floating point number *OR* a complex number with floating
> point components, so that's why it's still here but `int` isn't.
>
float
On Tuesday, August 18, 2015 at 11:29:00 AM UTC-4, Sisyphuss wrote:
>
> My point is these inconsistent rules are very confusing. The experience
> gained in one type cannot be extrapolated to another.
>
I think most people here will agree with you. The discussion on how to
spell conversion and/
My point is these inconsistent rules are very confusing. The experience
gained in one type cannot be extrapolated to another.
Again, think about `sparse()`. What will we use when we implement the
`SparseMatrixRSC`?
On Tuesday, August 18, 2015 at 2:26:12 PM UTC+2, Yichao Yu wrote:
>
> On Tue,
On Tue, Aug 18, 2015 at 6:04 AM, Sisyphuss wrote:
> We use `Int8(x)` to construct an `Int8`,
> but use `float(x)` to convert to a floating point.
Float is not a type. FWIW, `AbstractFloat(1)` works.
>
> We defines `Symbol` as an object,
> but use `symbol()` to construct symbols.
`Symbol("a")` w
We use `Int8(x)` to construct an `Int8`,
but use `float(x)` to convert to a floating point.
We defines `Symbol` as an object,
but use `symbol()` to construct symbols.
I am so confusing.
11 matches
Mail list logo