Welcome to SmallJS Discussions!

[FunctionPoint]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[FunctionPoint]

Hi all, any general discussions about SmallJS can take place here,
like design goals and suitability for types of apps.
.
If some part of SmalJS is not working for you, please open a regular issue.

[gavr123456789]

Have you ever thought about adding a type system, for example a granular one like in Python\Ruby?

[gavr123456789]

watching ur presentation right now, I see u already mentioned these topic

https://youtu.be/FOswdxQMyOI?list=PLjt1Fa4aHu60I6SjzQDKkgzrFiuH8RRZ7&t=1420

[FunctionPoint]

Yes I have, and you found it :-)
I think optional typing would be the single most (only) important extenstion to the Smalltalk language.
There has been at least one attempt before: Strongtalk ( https://www.strongtalk.org/index.html )

But I haven't spent much tought on it yet, and there does not seem an immediate 'easy' way to do it.
You have to consider (argument) variables that can contain multiple (union) types,
and arrays (collections) that can hold templated types e.g.: Array.
And classes in ST are also just objects, with a lot of flexibility you have to capture.
It can become complex quicky, but TypeScript shows it can be done.

So input is welcome, but for now I'll concentrate on bringing original Smalltalk "back" first. :-)

[FunctionPoint]

PS I did look at your Niva project a little bit recently, that indeed has types.

[gavr123456789]

Yes, I've always dreamed of a typed Smalltalk, and I decided that I'd just make my own based on the JVM (and Kotlin). I am currently in the process of switching to self hosting (niva implemented in niva). Thats a fun project, not a serious lang.

I've been thinking for a long time about how to transfer the Smalltalk syntax to a text format. I really like your idea with exclamation marks and top-level declarations of methods.
I chose a different approach, just repeating the recipient type when declaring each method. If method has only one expression then it implicitly returns it and u dont need to wrap it in []

Int inc =this+1Int dec = [
^this-1
]

Next problem was non local return, and how to implement it zero costly.
I like how it was the first question in my head, and it was immediately asked https://youtu.be/FOswdxQMyOI?si=qnom39Pc5G4YApjZ&t=6093. Now Im interested how PharoJS does it :)
I just use inlining, and plan to do it in js backend too.
So when u have something like

...
x ifTrue: [ ^42]

The body of ifTrue: inlines in place where it was called, so u can return do non local returning from any lang without additional cost, it is basically hygienic macros, since u need to mangle all the variable names so they do not clash with the outside scope.

[gavr123456789]

P.S. non related to Smalltalk lang - Pipefish has a very similar approach to syntax. https://github.com/tim-hardcastle/Pipefish/wiki/Functions-and-commands
It using blocks of kinds of declarations - consts, types, definitions, variables, just like your CLASSMETHODSMETHODS etc

[gavr123456789]

I have similar way for creating bindings with @emit pragma is just like urs INLINE https://gavr123456789.github.io/niva-site/binding.html#emit

[FunctionPoint]

SmallJS has the requirement that every class has its own file, do you don't have to repeat the class name for methods. I'm quite content with this choice as it forses the user to keep things orderly ;).
As you seen in the presentation, non local return are implemend in SmallJS now via exceptions, that keeps the compiler simple. But optimising for the must frequent use case ifTrue: / ifFalse would be an idea.
Pipefish is function oriented, not object oriented, so when implementing methods that belong together,
i.e. operate on the same object (struct), you have to repeat the 'self' object often as the first argument:
https://github.com/tim-hardcastle/Pipefish/blob/main/examples/money.pf

[gavr123456789]

In #57 u said "Using files enables use of standard IDEs (VSCode) and source control tools (Git)."
Did u know about\or tried the Pharo plugin for VSC, it transfers suggestions from Pharo to VSC via LSP protocol. Its really cool.

https://marketplace.visualstudio.com/items?itemName=badetitou.pharo-language-server

[FunctionPoint]

Yeah, I heared about it, and would like this better than using the the Pharo System Browser.

Pharo, and other Smalltalks are only for back-end and desktop apps.
Web front-ends, the most common use-case nowadays, are generated from the native Smalltalk,
with "bridged" support from the back-end, translating back and forth.
This leaves you with 2 worlds on the back-end: 'native Smalltalk' and 'JavaScript', also in your IDE.
(The Pharo IDE 'critique' checker complains a lot if you have the PharoJS bridge installed)

In SmallJS you can fully work in the front-end separately and also step-debug there.
And when working in a back-end project, the core language and libraries are exactly the same,