Post #3,351
8/1/01 2:40:24 AM
|
I think you are missing my point
>> Most existing languages have that syntax: C, Pascal, Java... << I am thinking about EVERYTHING using that syntax, not JUST functions. Something like: sub(mysub params(param1) let(a, 3) // same as: "a := 3" if (cmp(a,">",10) print("it is greater") foo(a, param1) ) ) mysub("blah") etc....
IOW, very LISP-like, but move the operation name outside the parenths. (I think I need to read the FAQ to get the double-spacing out of PRE. There is a FAQ, I assume.)
________________ oop.ismad.com
|
Post #3,363
8/1/01 5:27:44 AM
|
Haven't seen one but ...
Note that since you aren't using them as syntax you could name your operations with traditional operator characters
if (cmp(a,">",10)
becomes
if (>(a, 10)
Or you could use > as a constant and have
if (cmp(a, >, 10)
Also, I assume from your example you are treating linefeeds as commas in a parameter list (with trailing linefeeds in a parameter list being ignored)? Or would it be more consistent to separate the statements with commas and ignore linefeeds?
And how would you do a if/else? Require a 'block' function in your if function?
if(>(a, 10), block( ... code here ... ), block( ... code here ... )),
Or did I just reinvent lambda?
PS: Turn // comment into rem("comment") and you could have some kind of runtime comment processing
I should really go to sleep now.
-- Chris Altmann
|
Post #3,443
8/1/01 1:04:57 PM
|
good suggestions, but.....
>> if (cmp(a,">",10) becomes if (>(a, 10) <<
I think I am too used to thinking infix. Besides I might later "evolve" it to a more conventional approach, and don't want to shuffle the ordering as much.
I am not trying to fully optimize the syntax here (just yet), only make the langage simple to compile/parse. Those issues don't really affect the key elements of what I am trying to demo.
>> Also, I assume from your example you are treating linefeeds as commas in a parameter list <<
No, parameters would be based on spaces. If there are embedded spaces, then quotes are required. It would roughly follow LISP conventions.
>> And how would you do a if/else? Require a 'block' function in your if function? if(>(a, 10), block( ... code here ... ), block( ... code here ... )), <<
I am working on that issue. I have a different approach in mind, but have to check it more carefully. It sort of merges IF's and CASE statements.
>> PS: Turn // comment into rem("comment") <<
Too much typing. I will just let a preprocessor remove/ignore anything after //.
________________ oop.ismad.com
|
Post #3,478
8/1/01 4:00:39 PM
|
Haskell
In Haskell, any function can be prefixed or infixed. This is a nice feature when you start doing folds and generators. The syntax goes along the lines of:
mod 14 3
is the same as:
14 `mod` 3
The backquotes are used for the purpose of infixing a function.
|
Post #3,365
8/1/01 7:01:41 AM
|
Isn't it obvious that that's fscking styoopid?!?
|
Post #3,441
8/1/01 12:53:06 PM
|
CRC: Not Delphi == Stupid
If you are not going to post anything beyond name calling, then why post at all?????
What is calling something stupid without any textual backing going to achieve? I cannot figure out your motivation other than Yosemite Sam-like adrenaline.
________________ oop.ismad.com
|
Post #3,457
8/1/01 2:02:48 PM
|
It appears to be a different way to do things
I am not saying it is stupid, just different. We would have to see how the cmp() function is written, it obviously takes a parameter to use to compare two values. I assume it returns the boolean value of True or False, or 0 or 1 or some other way you keep track of True/False conditions.
It would then be a matter of how the cmp() function handles the parameters and parses out the logic statements. That is if cmp() is a user defined function and not an external one written in another language and linked up at runtime, or imbedded machine code.
But let us just say that it is a user defined function. Excuse my Visual BASIC syntax:
Function cmp(value1 as Integer, opcode as String, value2 as Integer) as Boolean Dim result as Boolean
result = false ' Just in case the function fouls up
Select Case opcode Case ">" If value1 > value2 Then result = True Else result = False End If Case "<" If value1 < value2 Then result = True Else result = False End If Case "=" If value1 = value2 Then result = True Else result = False End If Case Else result = False End Select
cmp = result ' Set the function to the desired result
End Function
In this case, based on what is passed to the function, can return a true or false value. In this way VB can be changed to examine two Intergers via cmp(1,">",2) which would return a Boolean False and cmp(1,"<",2) which would return a Boolean True. Using an OOP design, you could build this function into a class, and overload it so that it can handle Real, Long Integer, and other values by using Overloading. Of course you would have to understand how OOP works to do this, but then cmp(1.1, ">", 1.2) would be valid as much as cmp(1292921, ">", 93919987), but either one would fail on the cmp() function that is written only for Integers and does not handle any sort of OOP design. You would be forced to create multiple copies of this function and name them cmpint(), cmpreal(), complong(), etc.
"I can see if I want anything done right around here, I'll have to do it myself!" Moe Howard
|
Post #3,580
8/2/01 1:51:18 AM
|
are you being a meanee?
>> Of course you would have to understand how OOP works to do this <<
This sounds like a dig. I know perfectly well the stereotypic type-based polymorphic dispatching of operand "types". BTW, L has only one type. Thus, there is no "type" to dispatch on.
Anyhow, I am thinking of making the world's first table-based interpreter. No RAM shct like linked lists or RAM hashes. All tables all the time. It makes it a snap to inspect the guts of runs.
________________ oop.ismad.com
|
Post #3,391
8/1/01 9:38:03 AM
|
Syntax is syntax.
What's the point? It seems unnecessarily complex.
However, there are truly functional languages out there, like Haskell, ML, Caml, Miranda, and Scheme. Functional programming has the benefit of being both more concise and provable (in the mathematical sense).
What you're asking about, however, doesn't really serve any purpose that I can see.
Regards,
-scott anderson
|
Post #3,620
8/2/01 1:13:36 PM
|
complex?
>> What's the point? It seems unnecessarily complex. <<
Complex? It is simpler than most language approaches.
________________ oop.ismad.com
|
Post #3,638
8/2/01 3:23:56 PM
|
Simple.
"Everything should be made as simple as possible, but not simpler." -Albert Einstein.
Alex
Only two things are certain: the universe and human stupidity; and I'm not certain about the universe. -- Albert Einstein (1879-1955)
|
Post #3,426
8/1/01 11:29:48 AM
|
Why?
IOW, very LISP-like, but move the operation name outside the parenths. Everything in Lisp is a List or an operation on a list. This flexibility means that the distinction between functions and data is very gray, providing a maximally extensive language. From the standpoint of what you are proposing, I don't see the advantage yet. All I see is a rearrangement of syntactical structure. What does the rearrangement buy me in terms of flexibility or extendibility?
|
Post #3,439
8/1/01 12:39:34 PM
|
not the full story
>> From the standpoint of what you are proposing, I don't see the advantage yet. All I see is a rearrangement of syntactical structure [from LISP]. <<
I prefer the name on the outside. It is more natural IMO.
Besides, there are other features of the language that are not in LISP (such as named-parameters and dot-based dictionary arrays) or are in LISP but not needed because they are done a different way.
________________ oop.ismad.com
|
Post #3,477
8/1/01 3:54:11 PM
|
Not a contest with Lisp
It's best to remember that Lisp is over 40 years old and is still a language that can do things that surpass any modern language. The syntax may not be to your liking, but there are reasons for that syntax that make the language capable of being used for practically any programming paradigm ever invented.
As I said, Lisp uses the idea of Lists and Operations on Lists, as well as the idea of Lists of Operations on Lists. It has an internal consistency that pays dividends in terms of flexibility.
Again, the question is not a matter of tastes - it's a question of why? Why are you proposing the layout that you are proposing? What does it buy me in terms of flexibility/extendibility?
I'm not saying that it might not be nice. I am just asking you to explain the reason you consider it to be important.
|
Post #3,641
8/2/01 3:48:52 PM
|
Guessing but...
I'm not saying that it might not be nice. I am just asking you to explain the reason you consider it to be importantI suspect he thinks it will be easier to write a language parser that follows one basic syntactical idiom. If you can phrase x < 2 as cmp (x, "<", 2) than everything can be parsed as function (arguments) in a rather iterative fashion
Jay O'Connor
"Going places unmapped to do things unplanned to people unsuspecting"
|
Post #3,649
8/2/01 6:09:41 PM
|
I doubt it...
I suspect he thinks it will be easier to write a language parser that follows one basic syntactical idiom. I doubt that for two reasons. First, Bryce has been vocal in his opposition to any language feature that is done for the purpose of making parsing easier. Second, I have my doubts about whether Bryce ever intends to write a parser, so I wouldn't think he's too concerned with parsing issues. I guess while we're on the subject, I might as well ask how the syntax lays out when the number of parameters is not 2. What does the syntax do when there is only a single parameter? What does the syntax do when there are three or more parameters? Haskell gets away with it by stipulating that all functions take only a single parameter. Additional parameters are Curried in functions that also take a single argument. Python, OTOH, always takes a single parameter, but the parameter may be a tuple which allows multiple parameter to be group together as a single parameter.
|
Post #3,689
8/3/01 1:40:15 AM
|
not true
>> First, Bryce has been vocal in his opposition to any language feature that is done for the purpose of making parsing easier. <<
Like I said before, this is only a proof of concept, and NOT a final version by any long-shot.
>> Second, I have my doubts about whether Bryce ever intends to write a parser, so I wouldn't think he's too concerned with parsing issues. <<
That is what you guys said about a runnable SCGUI browser, and I made one. Anybody is welcome to try it. ( [link|http://www.geocities.com/tablizer/scgui.htm|http://www.geocitie...er/scgui.htm] )
>> I guess while we're on the subject, I might as well ask how the syntax lays out when the number of parameters is not 2. <<
I don't see why that would be a problem.
x()
x(p1)
x(p1 p2 p3)
(I wont go into named parameters here)
________________ oop.ismad.com
|
Post #3,692
8/3/01 2:32:03 AM
|
Yes, he's been vocal - but then, he wasn't writing a parser!
|
Post #3,739
8/3/01 12:54:34 PM
|
A "walk a mile in another's compiler" argument?
I still say that being programmer-friendly is more important than being compiler-friendly.
However, a hobby test project does not have that luxury, and may have to bend toward keeping the compiler/interpreter simple at the expense of some syntactical niceties.
IOW, you are comparing the standards for apples to the standards for orangees.
If the early draft for PHB had dollar signs, that would not bother me because I would not use it at that stage. But BY NOW those fricken dollars should be long gone (except for embedding variables in strings, where they make sense).
________________ oop.ismad.com
|
Post #3,771
8/3/01 3:42:31 PM
|
(addendum)
BTW, I plan to *incrementally* extend the syntax to make it friendlier. The "base" may be purely function-based, but extended from there.
One approach is to simply gradually add more complex syntax to the parser. Another is to have a pre-compiler convert the "friendly" version into the function-only version. I have not decided that yet which path to follow.
________________ oop.ismad.com
|
Post #3,621
8/2/01 1:17:50 PM
|
(minor correction)
This:
if(cmp(a,">",10) ....
could be
if (cmp(a ">" 10) ....
because commas are optional. BTW, I am considering the suggestion to make ">" a reserved word to avoid need for quotes.
________________ oop.ismad.com
|