Re: My scripting language - any suggestions?

On Sun, 31 Aug 2008 10:05:00 -0700 (PDT), lican wrote:


> Yeah, I thought about it. You're right. ToFloat is not scalable. Maybe
> something like: To(Float), To(Type)? It's something between
> my .ToType() and the 'to' operator proposed Johannes. Every solution
> is better than the ugly (SomeClass)var).SomeMethod() ;)


Well, C/C++ has problems it created all by itself. If you want to have the
type name involved, you do not need to twist the language. Make it
straight:


      Method (Float (var))


or/and an equivalent postfix sugar


      var.Float.Method


You could put "to" around (Float) (or in postfix sugar: Float.to), all this
semantically changes absolutely nothing. The problem of conversions is of
semantic nature.


> The preference is to use as few (key)word operators as possible.


The conversion operation is an operation as any other. It does not require
any special syntax and keywords. BUT this normality implies double
dispatch, unless conversions have to be explicitly defined by the user. The
latter is a lot easier.


> I'm also thinking
> about changing new Class to Class.New() or Class.Create();


The type of the object should be specified in its declaration. Otherwise a
necessity to specify the type indicates immaturity of the language (when
statically typed). It must be clear from the context, what of the type it
is.


> It would
> create a rather consistent interface with methods like object.Clone()
> and maybe object.Destroy(). Also the general idea is that all objects
> inherit some general methods from the base object called
> 'Object' (like Java and C#). The methods can be overridden depending
> on the type:
>
> - bool Is( Type )
> - bool Instance( Type ) or Of( Type ) or InstanceOf( Type )


When type is a first-class object then you can get it from an object and
then define necessary membership tests on the type's type. Note that in
this case the model of common base shall somewhere break.


Anyway for type comparisons, equality is not enough (Is is an equality).
Types form a tree or maybe a more general graph. You need operations
between types and sets of (classes). For example, in order to test if an
object X has a type A, such that A is a descendant of B.


> - Object To( Type )


This is equivalent to double dispatch. It is hard to bite...


> - String Serialize();
> - bool Unserialize();


The reverse to Serialize is an abstract factory.


> - Object Clone();


Not this. An object can be non-copyable, a clock, a hardware port for
instance.


> - void Destroy();


This is a difficult issue. Destructor (and constructors) is not a method.
It must be prevented from being called explicitly.


> As for the int and float representation... the Value class takes care
> of that stuff. It's written in C++ and goes something like this:
>
[...]
>
> It's rather simple, but it works. Most scripting VM work that way.


This is a representation sharing (which is in your case a union). This is
IMO a bad idea, because it is inefficient (distributed overhead). Further
it makes it impossible to control the representation when it is necessary
to do (low-level I/O, hardware support, communication protocol
implementation etc).


> As for the Serialize and To(String) methods, I find them distinct.
> I.e. someone wants to display a float to the user, they do
> var.To(Float) and get '1234.0987'. But if someone wants to write the
> data to a file Serialize would return 'f:1234.0987' or 'float:
> 1234.0987'. The thing is I think the type:value can be parsed more
> easily than just value.


This is why it need to be doubly dispatching. The dispatch goes along two
axes: the source types hierarchy and the hierarchy of the types of the
medium. If the target is Human_Readable_Left_To_Right_String, then
Serialize spits 1234.0987 or maybe, "about thousand" (:-)). When the target
is GTK_Cell_Renderer, then it does way different stuff.


BTW, putting the type into the output is another issue. I don't go into it,
because this is already too close to off-topic.


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Return to the comp.compilers page.
Search the comp.compilers archives again.