Idea: Improve typeof

[jasonkuhrt]

Question:

Why does typeof! [1,2,3] return 'Number'?

Idea:

Can we interchange typeof and typeof! so that the operator we know and hate can become the operator we know and love? The lesser of the two should be hidden behind alt syntax.

My only concern is not being able to typeof arrays as questioned above.

[gkz]

Use it as an expression

r = typeof! [1,2,3] #=> ["Number","Number","Number"]

[jasonkuhrt]

Better?:

• drop the confusing/inconsistent ! for a readable s
• fix typeof

o = {a:1  b:2  c:\b  d:[\nested  \array]}
a = [1  2  \a  \b  [\sub  \tree]  o]



typeof  o   #=> \Object
typesof o   #=> {a:\Number  b:\Number  c:\String  d:\Array}

typeof  a   #=> \Array
typesof a   #=> [\Number  \Number  \String  \String  \Array]



a-numbers = a |> filter (-> typeof it is \number)
a-numbers = typesof a |> filter (-> it is \number)

#=> [1, 2]
#=> {a:1  b:2}                (imagine o-numbers)



a-arrays  = a |> filter (-> typeof it is \Array)
a-arrays  = typesof a |> filter (-> it is \Array)

#=> [[\sub, \tree]]
#=> {d:[\nested  \array]}     (imagine o-numbers)

[satyr]

My only concern is not being able to typeof arrays as questioned above.

drop the confusing/inconsistent ! for a readable s

Note that typeof! and Unary Spread are separate features.

$ livescript -pe 'typeof!([1 2 3])'
Array

$ livescript -pe '^^[1 2 3]'
[ {}, {}, {} ]

[jasonkuhrt]

@satyr I'm mystified. Why do these produce different values?

typeof!([1,2]) #=> 'Array'
typeof! [1,2]  #=> ['Number', 'Number']

More importantly, can we improve the native typeof as exemplified above (namely 'Array' identification)? The plural form is sugar, not as important.

[vendethiel]

Because it triggers the unary spread.
+foo<[bar baz]> gives you [+foo['bar'], +foo['baz']]

[gkz]

Perhaps unary spread is no longer needed in LiveScript, and could be removed in order to have fewer special cases, as we can simply use operators as functions.

map (typeof!), [1, 2] #=> ["Number","Number"]

A bit longer yes, but I think worth it in reducing the amount of special cases a programmer needs to keep in mind.

[vendethiel]

I just think typeof! Shouldn't be unary spreaded. (I don't see why you'd use typeof! [...] anyway but ...)

[jasonkuhrt]

@gkz +1 reduce special cases (where the payoff is low).

And what about simply fixing the standard typeof?

map (typeof), [[1], [2]] #=> ["Array","Array"]

[michaelficarra]

@gkz: +1 get rid of unary spread. It's a neat feature, but leads to some confusing/unintuitive behaviours, and it's unnecessary as you say.

[vendethiel]

Like I said - Unary spread is really cool, removing typeof from unary spreading wouldn't be better ?
(and why would you write "typeof []" or "typeof [a, b, c]" in the first place ?)

[jasonkuhrt]

LiveScript typeof, in the future?

typeof some-array-value         # => 'array'
typeof 'boo'                    # => 'string'
typeof 5                        # => 'number'
...



# JavaScript code:

typeof$(someArrayValue)

function typeof$(value){
  if (Array.isArray(value)){
    return 'array'
  }else{
    return typeof value
  }
}

Simple.

[vendethiel]

(typeof! array)toLowerCase! here you go.

[jasonkuhrt]

@Nami-Doc Two versions of typeof that don't return the same values? This is just needlessly terrible, when you could easily have one that behaves as expected.

[vendethiel]

You may want the native version.

[jasonkuhrt]

@Nami-Doc Keyword maybe. I don't think its worth it. And if it is, use alt-syntax for said 'native'-version, not the fixed version that will be employed 99% (?) of the time. Isn't this practice (moving less-useful js operators to obscure names) livescript's policy for bitwise operations?

[vendethiel]

It's also meant to be compatible with coffeescript. Or just when you're starting LS

[jasonkuhrt]

@Nami-Doc An incompatibility worth making. Type-checking is fundamental. Should we really waste metons working around it. typeof is broken, lets fixed it.

• http://javascript.crockford.com/remedial.html

typeof [] produces 'object' instead of 'array'. That isn't totally wrong since arrays in JavaScript inherit from objects, but it isn't very useful. typeof null produces 'object' instead of 'null'. That is totally wrong.

We can correct this by defining our own typeOf function, which we can use in place of the defective typeof operator.

^ Or we can use a tool like LiveScript to never have to think about this again

Ad infinitum:

• https://github.com/phawk/js-typeOf
• http://www.2ality.com/2011/11/improving-typeof.html
• http://javascriptweblog.wordpress.com/2011/08/08/fixing-the-javascript-typeof-operator/
• http://css.dzone.com/articles/improving-javascript-typeof
• http://blog.alexanderdickson.com/javascript-typeof
• http://wiki.theory.org/YourLanguageSucks ("JavaScript doesn't have real arrays. Instead JavaScript just has objects.")

I would really like to see this real problem solved. Reading through the articles it appears that there's more we may want to do to (regexp detection? fix typeof null?):

[josher19]

typeof! [1,2,3] looks like typeof()([1,2,3]) at first glance, rather than
a LiveScript version of typeof.

I'd recommend type-of or is-a or is-type instead of changing typeof
(which could break existing LiveScript code) or using typeof!

Note that it's sometimes tricky to use duck-typing or to fix typeof across
Frames.
jashkenas/underscore#12 (comment)

->> Josh <<-

[jasonkuhrt]

@josher19 +1 that the bang in typeof! is terrible. I don't know about is-a though. In practice it is not ideal and is-a is less descriptive than typeof.

if is-a var is \array then ...

Just throwing this out there type-of:

if type-of var is \array then ...

Possible improvements could include:

- fix typeof null           #=> 'null'   ?
- better typeof []          #=> 'array'
- better typeof /boo/       #=> 'regex'
- better typeof NaN         #=> 'NaN'

@gkz @Nami-Doc thoughts?

[goto-bus-stop]

I think @josher19 means variable is-a \string or perhaps variable is-a string -> typeof$(variable) is \string

[jasonkuhrt]

@renekooi Then is-a takes two arguments making it an infix function:

x is-a \string    # => true || false

is-a x \string    # => true || false

# What If we need to store the type for some other task?
# change is-a behaviour when given only 1 argument (return type)
# Confusing to read, unnecessary magic under-the-hood:

type = x is-a              #=> \string

type = is-a x              #=> \string

VS

type-of x is \string    # => true || false

# What If we need to store the type for some other task? 
# Clean, no-brainer:

type = type-of x        #=> \string

To my intuition it is obvious which one is better. The operator name, typeof, is a good one. It combined beautifully with is. LiveScript doesn't need is-a.

[vendethiel]

(You can already infix with the backticks, but I agree with type-of)

[goto-bus-stop]

@jasonkuhrt I know, I didn't mean a function, but is-a as an operator (that's how I interpreted @josher19's suggestion)

[josher19]

type-of is better than typeof! because ! already has too many meanings:

• not : !true # => false
• no return value for functions : noreturn = !-> 1 # => function (){ 1; }
• function call without arguments: {}.toString! # => [object Object]

One advantage of current typeof operator vs. a type-of function is when dealing with things that have not been defined:

typeof nothing  # => "undefined"
type-of nothing # => Error: nothing is not defined

is-a is probably too close to is but it would be nice if there was an improved instance-of operator that works across Frames and iFrames. If iArray is defined in an iFrame, this fails in the parent frame:

iArray instanceof Array  # => false
iArray instanceof Object # => false

instance-of(obj,klass) = obj instanceof klass or type-of(obj) ~= (klass.name or klass)

iArray `instance-of` Array # => true
iArray `instance-of` Object # => false

[] instanceof Array # => true
[] instanceof Object # => true

See also:

• https://gist.github.com/3861950
• https://github.com/josher19/underscore.grep/blob/master/test/is.js

@gkz, +1 get rid of unary spread.

[jasonkuhrt]

@josher19 make an issue about instance-of for cross-frame support? Sounds interesting.

Also @josher19 couldn't we compile down to a try ... catch ...? Look:

# Attempting to create an ideal typeof
# *Note: Pretend this function is an operator.
type-of = ->
  | it is null           => 'null'
  | Array.isArray it     => 'array'
  | it instanceof RegExp => 'regexp'
  | NaN === it           => 'NaN'
  | otherwise            => typeof it


# when we use type-of
# (I am consciously omitting parens, if you want this code to work in current livescript, wrap a with () )
if type-of a is 'array' then return \boom

# ...it should compile down into a try-catch expression
# This ensures type-of something-undefined doesn't throw a reference error
if (try type-of a catch 'undefined') is 'array' then return \boom

@Nami-Doc @gkz Where are opinions at now?

[vendethiel]

Whoops ;).

[jasonkuhrt]

Is there any consensus here? If not we should just close the issue for real. It wouldn't be a huge deal to just create a type-of function, so the real question is, is this issue worth solving at the core-level for the whole community (that uses livescript)?

[vendethiel]

Unary spread is now better documented (t = typeof! [\b 5 {}] #=> ["String", "Number", "Object"]) as of 535f737.
Do you still want to get rid of them ?
Or change the syntax to a more obvious one (like <<[] or something - can't remember in languages that has that).

@jasonkuhrt I'd be okay with type-of, looks more like a keyword than typeof! (but ! is already used for compat. Bang meaning LS version: require, typeof. Bang meaning js version: delete).
I don't think it matters much. (and typeof!([1, 2]) is just typeof! ([1, 2]). Since types aren't backtraced ...)

[jasonkuhrt]

@Nami-Doc Overloadding the ! character with multitude of concepts just for the sake of compat is a shame? Degrading language design and consistency might fail just as many people as the compat aspect wins.

But, if ! variant ops are here to stay, then just close this issue. I have a gripe with ! ops but at least it is a consistent gripe.

[robotlolita]

I think getting rid of unary spread would make everything so much simpler, so that's a win. You can compose things easily because you can section operators into first-class functions, thus:

types-of = map (typeof)

I also vote for renaming typeof! to class-of, which would avoid the confusion between a value's type and it's internal [[Class]]. However, since LiveScript also provides a class syntax, I'm not sure how constructor functions generated by the class declaration should be handled.

[vendethiel]

I'll go ahead and reopen this one (from #523). I think with the (+) syntax, we don't really need it anymore. ("let's use functions instead of core constructs")

[rhendric]

After (the still undocumented, alas) #863, it doesn't seem like there are any outstanding needs here, so I'll reclose.

[determin1st]

it's not well documented what typeof! returns