Smalltalk › Amber Smalltalk

Parser improvements

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Nicolas Petton

Parser improvements

Hi!

I pushed some parser improvements, for selectors and symbols:

- #'hello world' is now valid
- #hello:world: is valid too

- selectors can begin with an uppercase letter, so "myObject Hello" is
now valid.

Note that the last fix makes it easier to use some JS libraries that use
capitalized JS constructor functions. For examples, if you have in
JavaScript something like:

new myLib.Hello()

Until now you had to write in Amber:

(myLib at: #Hello) new

Now you can write:

myLib Hello new

That works because BlockClosure in Amber has the #new method.

Have a nice sunday evening!
Nico

JohnnyT

Re: Parser improvements

That's great!

The uppercase selector will be super handy to have.

Thanks!

JohnnyT

On Jan 22, 2012, at 10:04 AM, Nicolas Petton wrote:

> Hi!
>
> I pushed some parser improvements, for selectors and symbols:
>
> - #'hello world' is now valid
> - #hello:world: is valid too
>
> - selectors can begin with an uppercase letter, so "myObject Hello" is
> now valid.
>
> Note that the last fix makes it easier to use some JS libraries that use
> capitalized JS constructor functions. For examples, if you have in
> JavaScript something like:
>
> new myLib.Hello()
>
> Until now you had to write in Amber:
>
> (myLib at: #Hello) new
>
> Now you can write:
>
> myLib Hello new
>
>
> That works because BlockClosure in Amber has the #new method.
>
> Have a nice sunday evening!
> Nico
>

jim kuo

Re: Parser improvements

In reply to this post by Nicolas Petton

Happy to see amber making progress all the time, as to parsing limitations I would mention limitations on Unicode and I searched the source code to find out where the specific code lines are.

*Please consider allowing Unicode characters used as variable and function names* the way JavaScript does and see if it will cause any problem.

Although people may have good reasons for sticking to English programming, I believe native language programming has to be an allowed practice.

I'm not skillful enough in JavaScript to touch the code myself :)

Best Regards,

Jim G

btw:

Thank you a lot for your excellent creation! I've been having fun with making and playing with light weighted js objects and wish Amber was a Self not Smalltalk. Klasses seems to be logical and philological illness in OO evolution. There is no class at all however human mind tends to classify objects. Objects don't need classes to make a live.

leonsmith

Re: Parser improvements

But JG, Smalltalk was invented to teach children programming. As
children and adults we tend to think of the world around us in terms
of objects (chairs, clouds, etc.). Classifying them is also human
nature (a Car show, a Dog show, etc.). You make a good point though
and many have argued about the merits of multiple inheritance so maybe
the way we classify could be improved. I like Classes myself much more
than prototypes.

On Jan 24, 11:59 pm, JG <[hidden email]> wrote:

> Happy to see amber making progress all the time, as to parsing limitations
> I would mention limitations on Unicode and I searched the source code to
> find out where the specific code lines are.
>
> *Please consider allowing Unicode characters used as variable and function
> names* the way JavaScript does and see if it will cause any problem.
> Although people may have good reasons for sticking to English programming,
> I believe native language programming has to be an allowed practice.
> I'm not skillful enough in JavaScript to touch the code myself :)
>
> Best Regards,
> Jim G
>
> btw:
> Thank you a lot for your excellent creation! I've been having fun with
> making and playing with light weighted js objects and wish Amber was a Self
> not Smalltalk. Klasses seems to be logical and philological illness in OO
> evolution. There is no class at all however human mind tends to classify
> objects. Objects don't need classes to make a live.

jim kuo

Re: Parser improvements

Well I agree with you on the behavior of human mind, however, to model this nature, a system that supports classes when needed, (for example one object may be classified to different classes but the object never gets broken in real world), but not class dominated would be fit to the nature a bit better. And prototypes could be thought as genes.

The class oriented world can be broken easy, there's no reason for living things all of a sudden to change behavior just because some was delighted and changed the definition of their classes. Since classes are conceptual beings not realistic ones and objects live their own lives they way we can classify later from different view point bases. Wrong classification will not do harm to objects. Sadly in programming this is not that case when object are plotted by classes.

And in a language is object generated it could be easy to add class support treating a class just as an object as normal, though, a class dominated language will have to make some efforts to pretend that they can do without making classes first to bring things to live. And objects have no individual rights.