Why my new JS-based language doesn't have a numerical tower and what I'm doing about it

[Manuel Simoni]

One word: interop.

I've previously had a great experience with Danny Yoo's js-numbers [1] in a Lisp->JS transpiler [2]. It's basically a plug-and-play Scheme numerical tower.

But in my new PL [3], I'm going directly with JS numbers. Why? It's just too painful to have to remember to call to-JS and from-JS conversion functions everytime I call a JS library or DOM function. (If anyone has a good solution for that I'm all ears!)

In addition to JS numbers I will add a separate big-integer (maybe big-decimal) class. Maybe it won't even be integrated with the JS numbers (similar to Java's BigInteger), and just be used for counting things without fear of overflow.

Whaddayasay?

Manuel

[1] https://github.com/dyoo/js-numbers
[2] https://github.com/manuel/edgelisp

[3] https://github.com/manuel/virtua

[Michael J. Forster]

On Fri, Mar 16, 2012 at 1:53 PM, Manuel Simoni <msi...@gmail.com> wrote:
> One word: interop.
>
> I've previously had a great experience with Danny Yoo's js-numbers [1] in a
> Lisp->JS transpiler [2]. It's basically a plug-and-play Scheme numerical
> tower.
>
> But in my new PL [3], I'm going directly with JS numbers. Why? It's just too
> painful to have to remember to call to-JS and from-JS conversion functions
> everytime I call a JS library or DOM function. (If anyone has a good
> solution for that I'm all ears!)
>

[...]
>
> Whaddayasay?

I, for one, say that I'll bear the pain for the sake of doing it
right. The bigger pains I've experienced over the last 25 years were
born of such compromises.

Cheers,

Mike

[Patrick Logan]

On Fri, Mar 16, 2012 at 11:53 AM, Manuel Simoni <msi...@gmail.com> wrote:
>
> Whaddayasay?

I think it matters what the language is intended for.

On a side note, I believe 64-bit integers are on the table for the
next ecmascript. Strangely, richer number types seem to be introduced
in order to support binary streams ("web sockets"), rather than for
better numerical programming, per se.

Apparently the browser eventually will become a reasonable environment
for programming applications even if it has to get there kicking and
screaming!

As far as a solution to the data type compatibility / conversion
problem, one semi-convenient approach for language developers might be
to use (portions of) GWT's java-to-javascript compiler. Another
advantage there might be the ability to use GWT's "dev mode" runtime
for debugging and running tests, which is a JVM.

-Patrick

[David Nolen]

On Fri, Mar 16, 2012 at 2:53 PM, Manuel Simoni <msi...@gmail.com> wrote:

One word: interop.

Performance too ;)

In addition to JS numbers I will add a separate big-integer (maybe big-decimal) class. Maybe it won't even be integrated with the JS numbers (similar to Java's BigInteger), and just be used for counting things without fear of overflow.

Any reason you can't support both? Default to JS numbers and provide a numeric tower via a library which provides the usual looking operators for the people that want / need them.

Another option would be a compiler flag to delimit where JS native math should occur.

A comment on js-numbers - I guess implementing valueOf didn't solve the interop problem for you?

David 

[Manuel Simoni]

On Saturday, March 17, 2012 9:14:54 PM UTC+1, David Nolen wrote:

A comment on js-numbers - I guess implementing valueOf didn't solve the interop problem for you?

Making simple functions like say DOM's getAttribute and setAttribute work transparently is easy.

Where it gets difficult is one you start passing around structured objects. E.g. if you pass a hashtable to a JS library function, do you want the language to go through all elements in the table, calling your to-JS transformation function? Recursively?

Manuel