Re: [Prothon-dev] Avoiding the limitations of other languages

We need to move this to prothon-user since we've decided hypothetical discussions belong there.

> I am really impressed by what I see so far.

That is very much appreciated.

> avoided other blotches like I see in Ruby

Have you found the stuff stolen from Ruby yet?

I like the idea of a reserved syntax extension modifier.  Anything can be changed for now since I'm not planning on freezing the syntax for months.  I've been using &var-name and @var-name for accessing syntactical and dynamic local variable access, something I haven't documented yet.  I'd like to keep those for that purpose if possible.  How about reserving %xxx for a reserved syntax element.  Does that meet your needs?

> Now if only we had an automatic translator to migrate all the good libraries from Python to Prothon

That would be awesome, but probably impossible.  The two big problems are reference counting and general object structure.  Matching these up would force Prothon to use Python's internals and one of our design goals was a new generation of improved internals.


----- Original Message ----- 
  From: David MacQuigg 
  To: [email protected] 
  Sent: Friday, March 26, 2004 1:21 PM
  Subject: [Prothon-dev] Avoiding the limitations of other languages


  I am really impressed by what I see so far.  Looks like you have addressed all the issues I have found troublesome with Python, avoided other blotches like I see in Ruby, and added cool stuff I've never even thought of ( prototype objects instead of classes !! ).  It looks so simple, I almost can't believe it will really work.  No static methods?   Surely something must be wrong. :>)

  One thing I have noticed about Python, and this is probably true of any language, is that no matter how clean the initial design, inevitably you have to add some cruft.  There is always something missing.  I can't see what it is with Prothon, but you can be sure that in a few years, you will have a dozen or so odd extensions that have sprouted from the basic language, some of them quite complex.  I would like to suggest a way to plan ahead for this, long before it is actually needed.

  Recently on the Python mailing list, I have been pushing the idea that we need a special symbol ( @  $ or whatever ) as a general-purpose "extension syntax".  Instead of "print >> ..." or " lambda x,y : " or " def f(x,y) [staticmethod]:", why not use a special, otherwise unused symbol for any syntax that is considered beyond the basic syntax of the language.  In all the examples I can think of, these are situations where we have a good pattern already ( simple functions ), but we need to add something. 

  The special "extension syntax" symbol has several benefits:
  1) It can be added to any existing statement without changing the form of the statement or the symbol.  In Python for example, we are adding "decorators" to the function definition statement using [ ... ] or possibly some new keywords ( 'with', 'has', etc.).  This syntax won't work for the print statement, because [ ... ] looks like a list to be printed, and the keywords look like normal variables in this context.
  2) It clearly separates what the language designers consider "basic" and should be learned by every user, from what can be learned later if needed.  This "encapsulation" of syntactic complexity is vital for new users or part-time users.
  3) In many cases a statement can be understood by a new user, even without understanding the extensions.  A user need not know what an @(generator) extension does, if all he needs to do is use the basic function as if the extension were not there.

  So my recommendation is to set aside one symbol that can fulfill this role.  You probably won't need to use it in the early design of the language, since everything now is part of a simple, clean concept.  If the language becomes popular, however, you will eventually have enormous pressure to add features while not breaking existing code.

  I'm using Python now to develop a circuit-design platform that I hope will eventually change the way electrical engineers design circuits.  These are some of the smartest people in the world, but they shy away from computer languages.  We are using a subset of Python (without classes) as the user-level scripting language for the platform.  Maybe one day we will migrate our tools to Prothon.

  Now if only we had an automatic translator to migrate all the good libraries from Python to Prothon ... :>)

  -- Dave



  *************************************************************     *
  * David MacQuigg, PhD              * email:  [email protected]      *  *
  * IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
  * Analog Design Methodologies                                  *  *  *
  *                                  * 9320 East Mikelyn Lane     * * *
  * VRS Consulting, P.C.             * Tucson, Arizona 85710        *
  *************************************************************     *




------------------------------------------------------------------------------


  _______________________________________________
  Prothon-dev mailing list
  [email protected]
  http://lists.prothon.org/mailman/listinfo/prothon-dev

_______________________________________________
Prothon-user mailing list
[email protected]
http://lists.prothon.org/mailman/listinfo/prothon-user