Post #3,154
7/30/01 11:11:10 PM
|
Language with syntax like command(params) ?
In thinking about ways to simplify making my infamous draft L interpreter, I am kicking around the idea of syntax like:
functionName(parmeters......)
For *everything* similar to the way LISP does:
(functionName parameters......)
Does anybody know of an existing language that does such?
If *everything* is a function, then I can greatly simplify the building of my interpreter. I am not saying that such is necessarily the ideal syntax, but it is enough to demonstrate the concept.
________________
oop.ismad.com
|
Post #3,164
7/31/01 2:29:49 AM
|
Most existing languages have that syntax: C, Pascal, Java...
|
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
|
Post #3,173
7/31/01 3:38:18 AM
|
Interesting idea.
I'm sure I remember a language where you can do that... Hmm. *snaps fingers* Ah yes: [link|http://www.cs.arizona.edu/icon|Icon]. Icon has a function called proc() which can return a function pointer to any function and operator - built-in or otherwise. With such a reference, you can call everything with a function call syntax. I imagine you could even do something like this: assign := proc("=", 2);
plus := proc("+", 2);
...
assign(a, plus(i, j));... or something like that. Of course, this isn't how the language usually works. The facility is there because all identifiers of built-in procedures and functions can be re-assigned to custom functions. The proc() function is then capable of retrieving the real ones, when you then need them. The book warns that there are a small number of control structures that look like operators but really are not - they cannot be retrieved using this function (which means things like if-then-else can't be, either). Wade. "All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #3,207
7/31/01 10:12:07 AM
|
TCL?
Their syntax is actually
command param param param ...
but that's the only syntax they have (of course, some params are lists).
|
Post #3,660
8/2/01 8:04:47 PM
|
Name your arguments
Having used Smalltalk/ObjC syntax, I now find other syntaxes impenetrable.
dict.put(a,b) leaves me wondering which is the key and which is the value.
dict setObject: a forKey: b
Leaves no doubt what a and b are used for. Plus, you can speak the program aloud and it makes sense.
I'm doing java development right now and its just awful in so many ways - this is one of them
|
Post #3,746
8/3/01 1:04:03 PM
|
not sure I fully agree
>> dict.put(a,b) leaves me wondering which is the key and which is the value.
dict setObject: a forKey: b
Leaves no doubt what a and b are used for. Plus, you can speak the program aloud and it makes sense.<<
I am not sure I completely agree. It depends on the frequency of usage, perhaps. The position is usually easily figured out by the context. Thus, if it is used several times in a given routine/method, you only are confused the first time, not the next 20. "setObject" and "forKey" then just become clutter that interferes with reading what is different. The frequent occurance of "setObject" and "forKey" is then a candidate for factoring out.
But, what bothers person A may not bother person B.
(BTW, I would try to use a table protocol instead of a dictionary protocol if it is data being stored. Dictionaries don't scale very well in complexity. A single key {index} is an arbitrary limit, so is two columns {key,value}. I don't like arbitrary limits. They create Meyerian Continuity problems.)
________________
oop.ismad.com
|
Post #3,777
8/3/01 4:38:55 PM
|
Limitation is in your head
table rowsMatchingKeys: (dictionary dictionaryWithObjectsAndKeys: value1, key1, value2, key2, value3, key3, nil, nil)
If you like this sort of thing - look at TOM [link|http://www.gerbil.org|http://www.gerbil.org]. The language supports tuples directly as a data type.
|
Post #3,790
8/3/01 8:46:43 PM
|
Software engineering is all about our heads
>> table rowsMatchingKeys: (dictionary dictionaryWithObjectsAndKeys: value1, key1, value2, key2, value3, key3, nil, nil) <<
If I am reading this correctly, then it is NOT a dictionary: it is a nascent database creater/manager.
I suppose next you will brag about how it can store objects, "not just data". To which I reply, "whoopty doo". And then point out how that makes it hard to share with other languages and paradigms, among other gripes.
Smalltalk fans are especially likely to brag about how ST "replaces or hides databases".
________________
oop.ismad.com
|
Post #3,963
8/6/01 1:43:43 PM
|
No
<quote>
If I am reading this correctly, then it is NOT a dictionary: it is a nascent database creater/manager.
</quote>
What do you think a tuple/row is? Its an ordered list of values. Combine a tuple with a schema (meta data about what is in each location) and its a set of key-value pairs. Which is the same as a dictionary - a set of key value pairs.
Is that a database? Sure. What is the underlying implementation of this database? I don't know or care - could be an interface that interacts with a SQL database table or view, or it could be an in memory data structure like an array of dictionaries.
The dictionary in this instance is being used as the match qualifier ('where' statement). Again, a dictionary is just a convenient programming construct for set of key-value pairs.
I think you have a lot of conceptual issues around programming for databases.
|
Post #3,969
8/6/01 4:06:03 PM
|
not necessarily "ordered"
>> What do you think a tuple/row is? Its an ordered list of values. <<
You could say that a "row" is a dictionary, but NOT necessarily "ordered". Some RDBMS provide a default ordering, but I consider these convenience attributes, and not a prerequisite.
________________
oop.ismad.com
|
