Lava Feed Back / Mailing List Beiträge
 
StartSeite | LavaFeedBack/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Die Lava-Mailing-Liste ist derzeit noch schwach frequentiert, deswegen platziere ich mal hier den einen oder anderen Beitrag. -- hl


Aleksa Todorovic, 28.12.2001

I've been trying for almost month to send this to Dr. Guenther without success, so I send this mail to public list, hoping it will be read by Dr. Guenther.

I saw your post to comp.lang.misc about Lava, so I took a look, and, ugh!, I really disappointed - somebody have already stolen my idea :) Why? Well, I'm undergraduated student of computer science, and I'm very interested in programming languages and tools, so one of my ideas in last few months has been to create programming "language" and environment just like LavaPE?. Now, I do not need to "invent hot water" - the great, revolutionary, ultimate solution is already here!

Seriously, I'm very impressed with Lava, and it's features: VTs - the most powerfull typing system ever presented to programmers (genericity of code, easy choice of different implementation of some interface, ...), non-linear structure of programs, three different kinds of attributes, very simplified, but yet still far more than just enough, support for concurrent programming, ... (I could write whole mail just counting all these features, but let's get to point).

I'm writing to you as programmer from the point of needs that I have when writing programs, so, here are some of these points (I separated them in few groups).

General

Language

program development, but it is needed quite often, so I thing there is need of solving this problem; one thing which could be done is to add "parametrized blocks" - blocks of code which have name and arguments, and can be recursive called, and are executed in the place where they exist, so they are not local functions; this way, you get few things: here's example as I see it (of course, you would judge about final look):

 
set max <-
» block FindMaximal
inputs: Integer i, Integer current_max
outputs: Integer max
 max is local to FindMaximal, has no connection with above one
from
 i <- 2, current_max <- a[1]
 Starting conditions, arguments names could be ommited
do
 if
   i > n
 then
   set max <- current_max
 elsif
   a[i] > current_max
 then
   set max <- FindMaximal(i + 1,a[i])
 else
   set max <- FindMaximal(i + 1,current_max)
 #if
#block

Declarations edit

Functions edit

 Fibonacci(n <- n - 1) + Fibonacci(n - 2 -> n)

As it is obvious, "->" has its functionality even here. Surely, this feature is not so useful for some functions like Fibonacci, max/min, sin, cos, ..., so a button which relugates this feature downto level of argument would be useful; applying this feature to some complex construction would work as "->" - applying it to every single argument in that construction; this should, also apply to output parameters, something like:

 call ... -> (var1 <- out_param_name1,var2 <- output_param_name2)

enabled here I think Lava is great programming tool, and it will be interesting for any serious programmer. I hope you'll keep your good work on it.

Best wishes
Alexa

Aleksa Todorovic
undergraduated student of Computer Science
Institute of Mathematics
University of Novi Sad
Yugoslavia


Hier meine Antwort: --kg

Hello, Alexa,

many thanks four your kind wishes for the New Year 2002. My wife and me are glad to read your positive opinion on Lava, and we wish you a happy New Year, too.

Aleksa Todorovic wrote:

 > I've been trying for almost month to send this to Dr. Guenther without 
 > success, so I send this mail to public list, hoping it will be read by 
 > Dr. Guenther.

I don't knwow why you had troubles to reach me by e-mail since nobody else had such difficulties so far.

 > I saw your post to comp.lang.misc about Lava, so I took a look, and, 
 > ugh!, I really disappointed - somebody have already stolen my idea :) 
 > Why? Well, I'm undergraduated student of computer science, and I'm very 
 > interested in programming languages and tools, so one of my ideas in 
 > last few months has been to create programming "language" and 
 > environment just like LavaPE?. Now, I do not need to "invent hot
water" -
 > the great, revolutionary, ultimate solution is already here!

LavaPE? certainly is by no means an ultimate solution, of course, as your own suggestions for improving LavaPE? show.

 > Seriously, I'm very impressed with Lava, and it's features: VTs - the 
 > most powerfull typing system ever presented to programmers (genericity 
 > of code, easy choice of different implementation of some interface, 
 > ...), non-linear structure of programs, three different kinds of 
 > attributes, very simplified, but yet still far more than just enough, 
 > support for concurrent programming, ... (I could write whole mail just 
 > counting all these features, but let's get to point).

> I'm writing to you as programmer from the point of needs that I have > when writing programs, so, here are some of these points (I separated > them in few groups). > > General > > - storing window state of LavaPE? would be very usefull, especially > during development

OK, I agree.

 > - more keyboard shortcuts - I like very much keyboard traversing through 
 > the program, because I have full feel of internal program structure - 
 > and it would be very nice if there are more, possibly customizable, 
 > shortcuts, especially when editing functions - it would make development 
 > of Lava programs, not fast, but amazingly ultra-fast :)

OK, I agree.

 >
 > Language
 > 
 > - ability that identifiers has spaces in names - I don't see any 
 > problems for this, and it could make programs even more readable
 > 

I don't agree: I think that the following declaration of a local variable "is.rather confusing.isnt.it" (note: one variable, not two!) using a type identifier "This type declaration" would not only be rather confusing but worse: it would be ambiguous:

    This type declaration is.rather confusing.isnt.it

> - loop problem - recursion is nice solution, it can, also, be unrolled, > so there are no recursive calls in final program, combined with

"single
 > assignment rule" it gives very high power in program development, but
it
 > is needed quite often, so I thing there is need of solving this problem; 
 > one thing which could be done is to add "parametrized blocks" -
blocks
 > of code which have name and arguments, and can be recursive called, and 
 > are executed in the place where they exist, so they are not local 
 > functions; this way, you get few things:
 > 
 >  - keep "single assignment rule" looking at this block as
separate function
 > 
 >  - make your program more readable - since every loop has its name, 
 > program becomes even more self-explanatory
 > 
 >  - one more construction to add to language
 > 
 > here's example as I see it (of course, you would judge about final look):
 >  
 >  
 > 
 > set max <-
 > 
 > » block FindMaximal?
 > 
 > inputs: Integer i, Integer current_max
 > 
 > outputs: Integer max
 > 
 >  max is local to FindMaximal?, has no connection with above one
 > 
 > from
 > 
 >  i <- 2, current_max <- a[1]
 > 
 >  Starting conditions, arguments names could be ommited
 > 
 > do
 > 
 >  if
 > 
 >    i > n
 > 
 >  then
 > 
 >    set max <- current_max
 > 
 >  elsif
 > 
 >    a[i] > current_max
 > 
 >  then
 > 
 >    set max <- FindMaximal?(i + 1,a[i])
 > 
 >  else
 > 
 >    set max <- FindMaximal?(i + 1,current_max)
 > 
 >  #if
 > 
 > #block 

I think that it would indeed be useful to have a simple way to introduce such typical "one-shot" functions as those used as a substitute for traditional loops.

 > Declarations edit
 > 
 > - it would be usefull to have button for semi-expanding of tree  (downto  
 > level of list of VT's, Declarations and Features, not opening their 
 > structure)

You are right, we'd also like to have a lot of such additional "convenience functions". More urgent ones would be to step through all references to some Lava entity, or to draw a class inheritance tree. Many other such functions are still missing.

 > - ability that overridables are shown imediatly on click on interface 
 > (with no need to click every time on "Show overridables")

That is worth consideration, thank you for this hint. So far we have hesitated to do that, since many people aren't pleased with to much automation of this type.

 > - hideable/undockable list of used files

The include and override views can be hidden easily by shifting their right (left) border to the left (right). If they were undockable then it would be difficult to find out to which tree view they belong.

 > - some kind of INCLUDEPATH for used files (just that Lava files could 
 > easely be sent to some other computer, and they work there, too)

This is planned (see the section on TOC files etc) but not yet implemented.

 > Functions edit
 > 
 > - automatic error report in toolbar when cursor is moved to invalid 
 > construct (TopSpeed? Modula 2 had this feature) - probably should be optional

This is a bit problematic since more than one error may be associated with one Lava construct. But we could, perhaps, set the default height of our present error window to 1 line to achieve a similar effect.

 > - automatic enter of ~/= when "new" is used depending on type of 
 > destination (if both sides must be of the same kind in this sense?)

OK, I'll put that on our TODO list.

 > - default number of arguments in function calls should be zero, not one, 
 > which sometimes confuses

OK, I'll think about that.

 > - also, very useful feature would be to have somewhat different
"sintax"
 > of function call - that for each argument, it's name is written with 
 > "<-"; something like:
 > 
 >  
 > 
 >  Fibonacci(n <- n - 1) + Fibonacci(n - 2 -> n)
 > 
 >  
 > 
 > As it is obvious, "->" has its functionality even here.
Surely, this
 > feature is not so useful for some functions like Fibonacci, max/min, 
 > sin, cos, ..., so a button which relugates this feature downto level of 
 > argument would be useful; applying this feature to some complex 
 > construction would work as "->" - applying it to every single argument 
 > in that construction; this should, also apply to output parameters, 
 > something like:
 > 
 >  
 > 
 >  call ... -> (var1 <- out_param_name1,var2 <- output_param_name2)

I'm a bit afraid that this explicit repetition of the formal parameter name in the context of an actual parameter would blow up the entire function call in a way which woud rather impede readability. An alternative would be to provide a context menu (right mouse button) on executable constructs (and perhaps also on declaration tree nodes) which could, for instance, contain an item "go to formal parameter" if you have selected an actual parameter.

 > - it is sometimes annoying that for every constant I need to click on 
 > "Edit selected item" - this could be done with second click (not 
 > double-click, but like rename); also, Esc key should be enabled here

Thank you, worth consideration. (Did you already note that the "cursor down" / "cursor up" keys open and close the little edit window on constants and variable names?)

 > - "Copy as text" of constructs

OK, but would require to replace the graphic symbols (WingDing font) for the assignment arrows with <- and -> (not so nice).

 > I think Lava is great programming tool, and it will be interesting for 
 > any serious programmer. I hope you'll keep your good work on it.

Our central problem is that we are only two: my wife and me.

So if you are highly motivated and have good ideas for the improvement of Lava, why don't you join us, beginning with such useful little enhancements like those that you have proposed above? (Provided you have MS Visual Studio or we can find a substitute for it.)

Best regards,

Klaus.


StartSeite | LavaFeedBack/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 23. Juni 2002 14:45 (diff))
Suchbegriff: gesucht wird
im Titel
im Text