Re: [MSEide-MSEgui-talk] MSElang Objects

2017-05-11 Thread Edson H 
Hi Martin,


I'm currently developing a Pascal Compiler and I have analyzed (although not 
implemented) the best notation on managing objects and I would say, the way you 
have defined the syntax for MSELAng is exactly the way I thought it must be. 
Using clases like a dereference.


In order to avoid confusion I would suggest to use some standard or 
recommendation on names, something like "All class names must be preceded by 
the letter C"


Sometime I think all the names of identifiers must be clear indicative of their 
type and even of the scope. Something, like PHP do with variables, but it would 
be another language.


I see MSELang like a new proposal for a modern language. I'm including some 
changes too, to the Pascal language in my compiler. There are people who thinks 
Pascal is perfect like it is, but I see, fortunately, you are not that kind of 
people, like I'm not.


I believe, I will be glad on using MSElang. I don't like you are using LLVM, 
but anyway you are doing a great work.


Congratulations.




De: Martin Schreiber 
Enviado: martes, 09 de mayo de 2017 01:52 p.m.
Para: mseide-msegui-talk@lists.sourceforge.net
Asunto: Re: [MSEide-MSEgui-talk] MSElang Objects

On Tuesday 09 May 2017 15:26:24 Marcos Douglas B. Santos wrote:
>
> It is not about if these languages are better, but if they are easy to
> do the work.
>
Thats the reason why I proposed the additional and possibly redundant "class".
You are against the "class" which eliminates the explicit "^" dereference and
you are against the "^" which eliminates the uncertainty of value/reference
object item access with the same notation. :-)

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mseide-msegui-talk Info Page - 
SourceForge
lists.sourceforge.net
mseide-msegui-talk -- General list for MSEide+MSEgui About mseide-msegui-talk


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

2017-05-11 Thread Martin Schreiber 
On Friday 12 May 2017 00:07:09 Fred van Stappen wrote:
> > It is logical that the libraries are bigger because the libraries contain
> > all named code
>
> Huh, :
>
>
> program prognude ;
> begin
> end.
> => 26.9 k
>
> library libnude ;
> begin
> end.
> => 196.3 k

Have you checked with objdump what is in libnude?

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

2017-05-11 Thread Martin Schreiber 
On Friday 12 May 2017 03:44:30 Edson H wrote:
>
> In order to avoid confusion I would suggest to use some standard or
> recommendation on names, something like "All class names must be preceded
> by the letter C"
>
In MSEgui I use "T" as prefix for class types. All other custom types have no 
prefix but "ty" postfix. There is also the {"P"} prefix for pointer 
types. "T" could be replaced by "C" which looks more correct.
>
> Sometime I think all the names of identifiers must be clear indicative of
> their type and even of the scope. Something, like PHP do with variables,
> but it would be another language.
>
I strongly am against the hungarian notation and generally use prefixes with 
caution. I think the start of a designator should contain the most important 
part in order to speed up vertical or block source scanning. For variables 
the most important part is the name IMO.
>
> I see MSELang like a new proposal for a modern language. I'm including some
> changes too, to the Pascal language in my compiler. There are people who
> thinks Pascal is perfect like it is, but I see, fortunately, you are not
> that kind of people, like I'm not.
>
Yup!
>
> I believe, I will be glad on using MSElang. I don't like you are using
> LLVM, but anyway you are doing a great work.
>
Why, what would be the alternatives?

MSElang produces an intermediate code representation
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/opglob.pas
which can be interpreted directly (mostly for testing purpose)
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/stackops.pas
or converted to LLVM bitcode
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/llvmops.pas
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/llvmbcwriter.pas

If you like to write your own optimizer and code generator you can use the 
intermediate code. The quality of LLVM produced binaries is impressive, see 
for example
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_benchmarks
>
> Congratulations.
>
Thanks!

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

2017-05-11 Thread Martin Schreiber 
On Thursday 11 May 2017 14:27:51 Fred van Stappen wrote:
> Hello Martin
>
> >> It is sad that still a fpc library with same code is 5 times bigger than
> >> a fpc executable ( and montain times bigger than same C code compiled
> >> with gcc or clang).
> >
> > Do you know why?
>
> Huh, the answers in fpc forum are nebulous:
>
> - One said it is because  parameter -fPIC is added automatic even when not
> entered by code. It seems that fpc has problems if -fPIC is not used.
>
> - Other said it is because dynamic runtime packages are not supported yet:
>   
> http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library
>-td5718200.html
>
> - There was other answers too but I do not find it back.
>
You compare a smartlinked executable (-XX -CX) with the size of the 
correspondent libraries. It is logical that the libraries are bigger because 
the libraries contain all named code, the smartlinked executable contains the 
actually used code only.

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

2017-05-11 Thread Fred van Stappen 
Hello Martin


>> It is sad that still a fpc library with same code is 5 times bigger than a
>> fpc executable ( and montain times bigger than same C code compiled with
>> gcc or clang).

> Do you know why?

Huh, the answers in fpc forum are nebulous:

- One said it is because  parameter -fPIC is added automatic even when not 
entered by code.
  It seems that fpc has problems if -fPIC is not used.

- Other said it is because dynamic runtime packages are not supported yet:
   
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-td5718200.html

- There was other answers too but I do not find it back.

Fre:D
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSElang Objects

2017-05-11 Thread Fred van Stappen 
> It is logical that the libraries are bigger because the libraries contain all 
> named code


Huh, :


program prognude ;
begin
end.
=> 26.9 k

library libnude ;
begin
end.
=> 196.3 k
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk